Yup. At KDE we never seriously considered GitHub. We always built our own git infra, and eventually landed on GitLab, after banding together with Gnome and a (generous and forthcoming) GitLab to convince them to move everything we needed from the Enterprise Edition to the free software Community edition.
I think we've had exactly one multi-hour git outage in 16 years.
...until it comes to bikeshedding new standards
I remember that the first instance of their CI solution was a separate server/service that coordinated CI jobs on runners. That was a bit cumbersome. But then they integrated the CI coordination into the main server and you only needed to figure out the CI runner part.
Today I would likely have gone for Forgejo with runners for such a small company if I were to self-host. Less moving parts and smaller footprint.
What I ended up with is a version of a static forge - Charm's soft-serve to host the repos and a forked version of the pico.sh pgit static site generator. I added git-bug integration to track issues in the repo and an alternative CLI to git-bug that works better when collaborating with agents.
A static forge site is very resilient to bot traffic because it only renders a limited number of commits, instead of pathologically allowing a near infinite number of URLs for bots to crawl.
https://kilimanjaro.io if you want to see what it looks like.
We are actually facing 2 distinct problems:
- Github is a centralized, controlled git hosting, identity, collaboration platform.
- Bots are attacking any public facing interface.
So maybe the solution is:
- to keep a Radicle node private/behind fences to lower the maintenance/security burden, with eventually access to selected collaborators.
- publish the repos with a static site generator like pgit
Issues and CI are the only lock-in. The latter is legitimate because you're using someone else's CPU, but every developer has the tooling to "git diff" and write comments if we could just agree on a format.
Sure, a little more complicated than “Create Issue”, but not that much for devs. We could even simplify the workflow with e.g. git-issue or something like that, similar to e.g. git-send-email.
git issue init “There is a problem”
git issue push
git issue get 6 # short for issue@{6}Using a separate Git repo with a defined naming structure I could appreciate.
(e.g. gitrepo.org/project and gitrepo.org/project_issues )
I think that model works well when it comes to code, but I don't think the non-free software movement ever really figured out how to deal with services and data. Even if GitHub was completely 100% GPL Free Software... the user accounts and everyone's comment history and stuff lives on a database somewhere. The servers are running somewhere. That's where the community is.
Even if you could take GitHub and spin up your own fork running the exact same software, the community isn't there. The interactions aren't there, the history isn't. It's like building a clone of your childhood house and wondering why your young parents don't magically appear in it.
The question of how to create free-software-mediated online communities that don't involve storing user identity and data in a company's private database is critical. The user database, and what can be built upon it, is the single biggest reason people do use Github despite its flaws.
It's not unlike the emotional drama I see each time Netflix raises prices (people get really upset about that), or video game discussion (the worst). If it's not worth the the value proposition, move on ... don't hang on / waste emotional cycles on Netflix or something like that ...
Granted I'm not a robot, I get the the emotional connection too, I think back to my early days in computing and I still fondly think of the now defunct manufacturer of my first PC, later the Windows 95 start me up commercials ... it was something magical.
Since we’re getting all philosophical, heartbreak isn’t inherently bad, it means you had the opportunity to love something deeply. Being engaged in the world means taking risks on things that might disappoint you. I do wish more of that love were directed at open source, but it’s not as if open source is without heartbreak and disappointment. Richard Stallman is sort of emblematic of someone who starts out with good intentions, but whose paranoid risk aversion probably put a ceiling on his potential?