The thing we actually need to get off github is not for more people to tell people to get off github, its for some of you with the technical expertise and tech company salary to pay for or volunteer to do the work to finish forgejo's federation so it's actually possible to compete with the kind of network and reputation effects needed to remain employed that are the actual thing github provides.
Post
Replies:
19
Boosts:
19
@jonny federation roadmap for anyone else looking at this thread who wants to consider jumping in: https://codeberg.org/forgejo-contrib/federation/src/branch/main/FederationRoadmap.md
@jonny the way gh works as a "LinkedIn for programmers" means yeah, it would be huge if federation was finally rolled out!
@jonny also there's Codeberg.
@happyborg and we love them, but just piling everyone onto another poorly funded volunteer run server is not the answer either
@jonny neither is a realistic solution on its own. We need options, and as you rightly say federation of those options.
@happyborg (codeberg is just forgejo, if we improve federation for forgejo, that's the same thing as improving codeberg)
@jonny @happyborg Also to test and refine the federation forges there should be several instances and, even better, different implementation
@jonny A week ago an old acquaintance I hadn't talked to in a while contacted me about self hosting Forgejo because GitHub has become so unreliable. I think GitHub collapsing on its own is going to be the biggest motivation for people to leave.
@OmegaPolice @be @jonny certainly not. I find it quite cool that the kid that managed to centralize most of open source development for profit will finally collapse thanks to devs going back to self hosted forgejo instances. Thanks forgejo.
@f4grx @be @jonny TBH, I don't see that happening. So far, there's no tangible benefit to leaving GitHub. It's a bet.
Plus, non-paying devs/org leaving won't hurt them, not in the short term. High-paying companies will have an even harder time leaving. What a shame, too, after "we" struggled for years to make deciders embrace SaaS in general and GitHub in particular ... 😪
@OmegaPolice @be @jonny things like nixos/nixpkgs are pretty irredeemably tied to it, sadly :(
@srtcd424 @be @jonny I don't have any reason to think they couldn't migrate off of GitHub.
First, mirror elsewhere. Then, move (reading) clients to the mirror. Then, move (writing) operations & communication over to the new system; GitHub becomes a mirror. Then, deprecate GitHub; make old clients emit a warning if you can (probably not). Finally, turn off GitHub.
Possible, but this takes a _lot_ of time if you want it to be graceful, never breaking clients. In fact, each step will take months: planning, execution, communication, bugfixes & refinements. The whole thing will take years.
Absolute mayhem if you're forced to move or, even worse, restore elsewhere without warning.
@OmegaPolice @be @jonny nixpkgs has a lot of CI, CD, and other automation that's heavily tied to github, and also needs a lot of compute. It would be a pretty big project :(
It's my understanding that Gitea/Codeberg have a mostly compatible CI/CD system. GitLab would be harder.
Integrations with APIs would be rougher.
But yeah, rebuilding all the stuff coupled to GitHub is a lot of work. Still dwarved by "let's give users N months to migrate now that we have it working", by my guess, though. 😉
@OmegaPolice @srtcd424 @be @jonny yes ci works in codeberg. but the way github holds devs by the balls is by providing ci machines for free so you can rebuild your entire project for every pull request and more. but thats a distortion of reality. there is no such thing as free compute, and devs will have to learn how to deal with that. there are probably ways to adapt.
@f4grx @OmegaPolice @srtcd424 @be i've been hosting forgejo runners on independent instances and also on codeberg and actually think this is a underrated opening, not a liability.
the first time i deployed a github-pages-like thing and could get walltime latency from the time i pushed to the time a page was deployed below a single second because i had full control of the environment & therefore could do what is treated as dev-only incremental builds without needing to spin up a fresh runner from the ether i was floored. the difference between even ~5 seconds and <1 second is a huge deal when thinking about it at a workflow level.
even when we have had expensive builds, it's clear how cheap the thing microsoft is offering per person. like each runner is effectively a raspi 5, so if you have any more competent hardware than that then self hosting a runner is a win when the platform doesn't try to limit that as a control vector. It's actually a really great shift to think of the git remote as just being a collaboration and relay platform where you put the CI runner in play as a point of optimization.
hijacking the github actions syntax into a runner is a really smart move so migration is straightforward, the biggest change has been putting more meaning into the "runs-on" param. forgejo runners are now just docker-in-docker images and are easy to run. there are some ux problem still - like i had to patch a config issue on codeberg that made external runners unusable last year, which signals that they are not widely adopted, but the potential is real.
@jonny @f4grx @OmegaPolice @srtcd424 @be
> so if you have any more competent hardware than that then self hosting a runner is a win
Only if you assume that my time to set up and continually maintain a piece of internet connected infrastructure is free.
The hardware cost is the **least interesting** part of the expenses saved by using GH runners.
