> I'm considering working on this full time. If you have some advice or opportunities on how I can support myself doing this, let me know!

Make it easy for non-technical users to also use this software. That will probably get you further along with gaining paid customers, IMO, because that's the hard part with something like this. It's easy for anyone who isn't used to `git` to use GitHub issues or something like Jira or Shortcut, but something tied to `git` or another cli tool is a hard sell for non-programmers, I think.

Make a program users can install on their MacOS/Windows desktop that interacts with a repository, without any need for the user to use `git`, or make a secure/hardened docker image that an org can run in their infra that links to repos and allows interaction via the web.

First of all: Huge respect for getting something out the door, looks really useful.

> I'm considering working on this full time. If you have some advice or opportunities on how I can support myself doing this, let me know!

You could consider an "enterprise" tier with a special subset of features and guaranteed support. But my experience tells me this will be really hard to substantially monetize, as the customer profile for that solution is probably not spending on software until they really need to (the saying goes: selling to developers is impossible, you need to sell to their boss). Maybe a donation model or a creator-centric thing could work out!

> - have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions

Have you looked into ForgeFed? It's a WIP plan for different Forgejo based forges to federate with each other. https://forgefed.org/

There's also this: https://indieauth.net/ though I haven't looked into it. I hope you could integrate one of these into your planned OAuth/account system!

Thank you for working on this, I love the idea. What surprised me was the way user identities is managed, I assumed you’d use whatever git uses. Would you mind elaborating on that?

Stoked to see this.

I've long felt that something like this was the way but have never gotten around to working on it.

Git-bug looks amazing! Author of GitSocial here, would love to hear your opinion:

https://gitsocial.org/

Any thoughts to making this integrate alongside other systems that use git metadata to track changes?

I'm thinking mostly of Gerrit, which keeps the entire code review and change history in git as well.

Being able to keep literally everything in the same git repo seems highly appealing.

For your roadmap, it would help with collaborating and organizing to use the issue queue

Something like "scoped labels" https://youtu.be/7l7tnEva6I8?is=InYAVXHomobvbOjL

:thumbsup

Thanks for posting! I don't see any mention of beads, which can also store the database in Git (via Dolt). How does this compare to it?

It's deeply interesting to me that you decided to override git conflict-resolution (at least in the 90% of cases) in favor of CRDT conflict-resolution. That sort of decision is not uncommon but I was just kinda wondering -- did the CRDT idea come first or did you try a plain-text format for storing the bugs and you ran into certain common workflows where that wasn't ergonomic? (My first guess would maybe just be appending comments to the ticket -- so like if a ticket is a TOML file, you both append a comment at the end, Git immediately screams about what order should those two comments be in -- instead to make that ergonomic within Git's limitations you have to like, represent the comments as a directory tree with no inherent order and UUIDv4 names, and then Git will say "oh you both put blobs in that tree? that's fine. no conflicts," and then you have to order them by (declared-time, UUID) on the client side.)

What's not quite so clear from what I'm skimming is what you did to alleviate Git's postmodernism. What I mean is, Git just holds a bunch of refs like tags and branches and they all deliberately, inherently have equal valence -- this comes from the history of Linux being developed on an email list, there literally is not "one Linux", there is no truth about "what is the Linux v6.18 kernel" but rather there is a big family of v6.18 Linux kernels and anyone who wants to spin up a new one can literally just grab an existing v6.18 kernel and write a patch and bam, you have a new one. It's the blind sages and the elephant, every sage is correct about what the software is, within their limited ability to perceive what the software does. And this like perennially causes problems, right, people use Git for a modernist thing like CI/CD where at most companies "what's running in prod?" is one of those questions that we don't like to say "well it depends on your perspective, there is no one truth..."

Sorry for the long explainer -- I'm just aware that this is a very idiosyncratic way of phrasing the D in DVCS. But it's like, in concrete terms, do you have clients force themselves to declare a certain repo as their origin, and a certain ref on origin is the blessed Git-Bug ref that they have to push from and pull to? And like the add-on that you've crafted just doesn't let you branch the ticket list and all of that? Or -- the opposite -- do you go all-in on the postmodernism and say "no whether some strange-looking functionality is a 'bug', that is a fact that needs to be added to the holistic perspective of the project, and whether that bug is deemed fixed is a similar fact that, like, if you say you fixed the bug in `dev` it might still be not fixed in `uat` or `prod` -- so the bugs need to be stored in the repo that you're versioning anyways. And we use these CRDTs to give you a bird's eye consistent view of a Bunch of repos and all of their current statuses and all that." Or do you take a third direction that's neither purely modernist "this is the truth" nor purely postmodernist "every branch is true".