With SourceHut banning projects that use LLMs[1], I’m looking to migrate this weekend.
While I can host Forgejo just fine[2], doing so means no one will be able to contribute to the projects, since federation isn’t a thing yet. Heck, getting contributions on SourceHut was hard enough, and it doesn’t even require people to register an account.
I might need to bite the bullet and go with GitHub. Regardless of what I think about the company and Microsoft, it’s where the people are.
Oh my. I hadn't noticed this, but I've been kind of expecting it. I've been a big SourceHut user for years now. So I'll be having to decide what to do myself. I absolutely get their stance, but I don't see a world in which I will go back to writing meaningful amounts of code by hand again.
I may try out tangled.sh. It's really nice to have my code stored and backed up somewhere other than infra I control and manage.
It ridiculous, Codeberg did the same. I get why, really, I do, but it's creating a severe damage that will be abused by a third evil actor that will take over the wasteland of GitHub and GitLab by creating a service that will allow anything (until it is enshittified of course)
Outcome? Everyone on their own self-hosted git servers, zero collaboration.
> Outcome? Everyone on their own self-hosted git servers, zero collaboration.
Everyone sticking to Github, then a year or two from now Github resolves their scaling issues and the competitors miss their window of opportunity to disrupt
Not if they keep putting everything behind a paywall. I'm not going to pay 60 (20/user/month) euros per month to be able to restrict pushes to main. It's absurd. Sorry, this specifically gets my blood boiling so I might be a bit more aggressive than needed.
I'm in the middle of a Forgejo migration myself for similar reasons. What finally pushed me over the edge was a hour long Actions outage that prevented me from pushing a hot fix for a bug to my webapp. (I relied on GH Actions to build and push an ARM Docker image.) For work that a business depends on, I can't recommend GitHub Actions. It's not just the outages that personally annoyed me, but the fact that I'm paying for it as well. So far I'm loving Forgejo and have no regrets!
I'm curious what you're replacing Actions with on the Forgejo side, and whether running that infra yourself feels like part of the benefit or another thing you'd rather not own
Forgejo has Runners that you can install on another server and register with Forgejo Actions. There might be 3rd party Runners you can pay to use, I've just run my own on a hardened VM.
What frontier model did GitHub train? All of the frontier labs scraped GitHub like they scraped everything else. While GitHub has certainly tried to profit from AI, directing ire at GitHub for frontier labs training on public code seems misplaced.
I agree with the sentiment of the post, and Github deserves every bit of it. Tried codeberg (which uses forgejo) and I am very happy with it personally.
Btw, did anyone notice they removed access to "who starred the project" recently. You can only check your own repos, not external ones. It was very nice to find related people before.
IME switching git providers is very hard, especially getting off of github. Most companies have insane numbers of integrations, automations, etc on top of GH. So yeah, its on us, but its also pretty simple algebra: does GH's downtime affect us more than the cost of switching? Most companies the answer is no.
When people ask why people aren't switching to Gitlab, ADO, Bitbucket, etc, I believe this is the reason.
This year, the migration projects I have worked on were some of the most fun. Migrations have changed from the death-by-1000-cuts that they were, to the which-AI-method-to-best-ensure-100%-fidelity. So, I don't believe the "very hard" part. Obviously it would involved recreating or reshaping many features that very involved in an integration to have a disruption-free move, but I think the complexity is manageable for most companies if they put in some effort.
This fun was not revenue-generating, I suspect, so it's already a loss. Also it's a long-tail change, which will likely create unexpected situations here and there, and de-value experience and knowledge already available. Cumulatively it can be much more expensive than staying, unless GH will continue to falter, of course.
It really is a testament to the power of mindshare and vendor lock-in. Git is GPL-licensed, the format is a de-facto standard, the commits and tags live in an on-disk format, merging and collaboration doesn't require a server, and yet somehow we still managed to end up with a centralized system with GitHub at the center.
90% uptime is abysmal. That degree of poor performance can easily cost astounding amounts of money and/or cause secondary incidents. It's just harder to quantify than the cost of switching.
I can't imagine anybody switching to ADO from GitHub. Microsoft has made clear that ADO is on life support, and are slowly stripping features out like public repos.
I look forward to when GitHub Actions has feature parity with Azure Pipelines.
I would not call it irresponsible. If you have a big, long running project you're going to want to develop complex pipelines and build processes to help with development and testing. This will save a lot of time and create a more consistent workflow, but switching vendors can require redoing work that was built over years.
> you're going to want to develop complex pipelines and build processes to help with development and testing
Opinion: Complex build processes are great. Complex _pipelines_ are a trap. I'm in a position to see the output of a lot of teams at a very large company. The teams that have complex build processes _that they can run locally_, and then have some trivial CI yaml to run the build, are doing great.
The teams that designed their build around CI are brittle and eventually end up in a state where they can _only_ do some parts of their build on CI.
IME it's worth it to set very hard boundaries shaped like: (1) Everything needs to be able to be run locally (usually in a devcontainer), (2) CI config shall be stupid simple. If you have more than like two lines in a script section, it goes into a Tools/Build script file that must work locally and is just called in a one-line CI script.
#1 guarantees you can operate without CI, and #2 guarantees you can move CI providers trivially.
>develop complex pipelines and build processes to help with development and testing. This will save a lot of time and create a more consistent workflow,
Beware the trap of making the pipeline so complicated it's like code except you can't debug or unit test like regular code, and it takes an hour between attempts to see if a change worked.
If only we had a way to run code in a pre-defined isolated environment that can hide most of the differences of the actual hardware...
Oh, we do have Docker/Podman?
Then why not use _them_ to define your build pipelines? Bonus points: you can run them locally without tearing out your hair. And you can use normal scripting languages and task runners (taskfiles, good old makefiles, Ninja, etc.) for sequencing.
Most companies aren't on GH at all, but are doing some internally hosted forge. Companies who build on GH are very much in the minority in my experience.
I really do wonder if the disruptions caused by the outages are starting to match the disruptions caused by a migration (which at least has a foreseeable end to it, theoretically).
Like even with the "will somebody please think of the operational costs" aspect, I really do wonder if the good old lock-in extortion math actually still holds in GH's favor.
GitHub is going the wrong way, but there really is nothing workable for open-source projects except GitHub. I don’t want to register on all these random GitHub killers just to open an issue or PR in a random project I’ve interacted with.
For personal or team setups, any third-party service will work well.
> GitHub is going the wrong way, but there really is nothing workable for open-source projects except GitHub.
Open source projects existed just fine before GitHub, and they will exist just fine if they choose to move off GitHub as well. It's not a big deal if people won't do drive by contributions any more.
I was about to mention Codeberg but I saw the last two changes to the terms of use and they're basically digging themselves into the ground with so many restrictions
GitLab is also getting worse and worse. They're going full-in on AI and each new release is more cluttered with useless features and requires more and more resources to run smoothly. After six years self-hosting a GitLab instance for a few hundred users (among which a few dozens are quite active), I abandoned this summer and I'm currently migrating the instance to Forgejo.
It's a shame because I like GitLabs UX and runners much more than other forges. I've been considering forking gitlab and removing complexity. GitLab uses multiple GB of memory idle with no users. It's sad.
I agree. GitLab UI was great and the simplicity of its CI/CD is unequaled on other forges. It's sad that Forgejo went with the actions model from GitHub which introduce a lot of useless complexity. But it seems that Woodpecker CI [1] could be a good candidate to replace GitLab CI, as it uses very similar concepts and workflow description files.
I know, GitLab. Gitea. Bitbucket. They have some features, but it’s like suggesting I drive a Nissan Sentra because my BMW breaks down once in a while.
With SourceHut banning projects that use LLMs[1], I’m looking to migrate this weekend.
While I can host Forgejo just fine[2], doing so means no one will be able to contribute to the projects, since federation isn’t a thing yet. Heck, getting contributions on SourceHut was hard enough, and it doesn’t even require people to register an account.
I might need to bite the bullet and go with GitHub. Regardless of what I think about the company and Microsoft, it’s where the people are.
[1]: https://sourcehut.org/blog/2026-08-27-tos-changes-and-llms/
[2]: And already do locally, as a mirror to SourceHut.
Codefloe looks like it could be promising. No real restrictions like other options. Time will tell.
https://codefloe.com/
Oh my. I hadn't noticed this, but I've been kind of expecting it. I've been a big SourceHut user for years now. So I'll be having to decide what to do myself. I absolutely get their stance, but I don't see a world in which I will go back to writing meaningful amounts of code by hand again.
I may try out tangled.sh. It's really nice to have my code stored and backed up somewhere other than infra I control and manage.
Vervis and Radicle both support federation.
https://codeberg.org/ForgeFed/Vervis
https://radicle.dev/
It ridiculous, Codeberg did the same. I get why, really, I do, but it's creating a severe damage that will be abused by a third evil actor that will take over the wasteland of GitHub and GitLab by creating a service that will allow anything (until it is enshittified of course)
Outcome? Everyone on their own self-hosted git servers, zero collaboration.
> Outcome? Everyone on their own self-hosted git servers, zero collaboration.
Everyone sticking to Github, then a year or two from now Github resolves their scaling issues and the competitors miss their window of opportunity to disrupt
Not if they keep putting everything behind a paywall. I'm not going to pay 60 (20/user/month) euros per month to be able to restrict pushes to main. It's absurd. Sorry, this specifically gets my blood boiling so I might be a bit more aggressive than needed.
[dead]
I'm in the middle of a Forgejo migration myself for similar reasons. What finally pushed me over the edge was a hour long Actions outage that prevented me from pushing a hot fix for a bug to my webapp. (I relied on GH Actions to build and push an ARM Docker image.) For work that a business depends on, I can't recommend GitHub Actions. It's not just the outages that personally annoyed me, but the fact that I'm paying for it as well. So far I'm loving Forgejo and have no regrets!
I'm curious what you're replacing Actions with on the Forgejo side, and whether running that infra yourself feels like part of the benefit or another thing you'd rather not own
Forgejo has Runners that you can install on another server and register with Forgejo Actions. There might be 3rd party Runners you can pay to use, I've just run my own on a hardened VM.
My gh actions were straightforward and moved to forgejo runners with zero drama.
What frontier model did GitHub train? All of the frontier labs scraped GitHub like they scraped everything else. While GitHub has certainly tried to profit from AI, directing ire at GitHub for frontier labs training on public code seems misplaced.
Microsoft owns GitHub.
What frontier model did Microsoft train?
https://microsoft.ai/news/building-a-hillclimbing-machine-la...
I agree with the sentiment of the post, and Github deserves every bit of it. Tried codeberg (which uses forgejo) and I am very happy with it personally.
Btw, did anyone notice they removed access to "who starred the project" recently. You can only check your own repos, not external ones. It was very nice to find related people before.
IME switching git providers is very hard, especially getting off of github. Most companies have insane numbers of integrations, automations, etc on top of GH. So yeah, its on us, but its also pretty simple algebra: does GH's downtime affect us more than the cost of switching? Most companies the answer is no.
When people ask why people aren't switching to Gitlab, ADO, Bitbucket, etc, I believe this is the reason.
This year, the migration projects I have worked on were some of the most fun. Migrations have changed from the death-by-1000-cuts that they were, to the which-AI-method-to-best-ensure-100%-fidelity. So, I don't believe the "very hard" part. Obviously it would involved recreating or reshaping many features that very involved in an integration to have a disruption-free move, but I think the complexity is manageable for most companies if they put in some effort.
This fun was not revenue-generating, I suspect, so it's already a loss. Also it's a long-tail change, which will likely create unexpected situations here and there, and de-value experience and knowledge already available. Cumulatively it can be much more expensive than staying, unless GH will continue to falter, of course.
It really is a testament to the power of mindshare and vendor lock-in. Git is GPL-licensed, the format is a de-facto standard, the commits and tags live in an on-disk format, merging and collaboration doesn't require a server, and yet somehow we still managed to end up with a centralized system with GitHub at the center.
90% uptime is abysmal. That degree of poor performance can easily cost astounding amounts of money and/or cause secondary incidents. It's just harder to quantify than the cost of switching.
I can't imagine anybody switching to ADO from GitHub. Microsoft has made clear that ADO is on life support, and are slowly stripping features out like public repos.
I look forward to when GitHub Actions has feature parity with Azure Pipelines.
Maybe for big companies that irresponsibly vendor-locked themselves, but I work at a SMB (~60 employees) and we switched to Forgejo in a couple days
I would not call it irresponsible. If you have a big, long running project you're going to want to develop complex pipelines and build processes to help with development and testing. This will save a lot of time and create a more consistent workflow, but switching vendors can require redoing work that was built over years.
> you're going to want to develop complex pipelines and build processes to help with development and testing
Opinion: Complex build processes are great. Complex _pipelines_ are a trap. I'm in a position to see the output of a lot of teams at a very large company. The teams that have complex build processes _that they can run locally_, and then have some trivial CI yaml to run the build, are doing great.
The teams that designed their build around CI are brittle and eventually end up in a state where they can _only_ do some parts of their build on CI.
IME it's worth it to set very hard boundaries shaped like: (1) Everything needs to be able to be run locally (usually in a devcontainer), (2) CI config shall be stupid simple. If you have more than like two lines in a script section, it goes into a Tools/Build script file that must work locally and is just called in a one-line CI script.
#1 guarantees you can operate without CI, and #2 guarantees you can move CI providers trivially.
>develop complex pipelines and build processes to help with development and testing. This will save a lot of time and create a more consistent workflow,
Beware the trap of making the pipeline so complicated it's like code except you can't debug or unit test like regular code, and it takes an hour between attempts to see if a change worked.
If only we had a way to run code in a pre-defined isolated environment that can hide most of the differences of the actual hardware...
Oh, we do have Docker/Podman?
Then why not use _them_ to define your build pipelines? Bonus points: you can run them locally without tearing out your hair. And you can use normal scripting languages and task runners (taskfiles, good old makefiles, Ninja, etc.) for sequencing.
Most companies aren't on GH at all, but are doing some internally hosted forge. Companies who build on GH are very much in the minority in my experience.
Most companies?
Do you have a source for that claim?
i can be the source for that claim
I really do wonder if the disruptions caused by the outages are starting to match the disruptions caused by a migration (which at least has a foreseeable end to it, theoretically).
Like even with the "will somebody please think of the operational costs" aspect, I really do wonder if the good old lock-in extortion math actually still holds in GH's favor.
I've had exactly zero issues hosting Forgejo. GitHub is only going to get worse.
GitHub is going the wrong way, but there really is nothing workable for open-source projects except GitHub. I don’t want to register on all these random GitHub killers just to open an issue or PR in a random project I’ve interacted with.
For personal or team setups, any third-party service will work well.
> GitHub is going the wrong way, but there really is nothing workable for open-source projects except GitHub.
Open source projects existed just fine before GitHub, and they will exist just fine if they choose to move off GitHub as well. It's not a big deal if people won't do drive by contributions any more.
> I don’t want to register on all these random GitHub killers
You don't have to; all the GitHub killers support GitHub sign on
I was about to mention Codeberg but I saw the last two changes to the terms of use and they're basically digging themselves into the ground with so many restrictions
It’s like the restaurant that is cash only and refuses to accept credit cards. Like bruh, what?
So why no self-hosted GitLab then?
GitLab is also getting worse and worse. They're going full-in on AI and each new release is more cluttered with useless features and requires more and more resources to run smoothly. After six years self-hosting a GitLab instance for a few hundred users (among which a few dozens are quite active), I abandoned this summer and I'm currently migrating the instance to Forgejo.
It's a shame because I like GitLabs UX and runners much more than other forges. I've been considering forking gitlab and removing complexity. GitLab uses multiple GB of memory idle with no users. It's sad.
I agree. GitLab UI was great and the simplicity of its CI/CD is unequaled on other forges. It's sad that Forgejo went with the actions model from GitHub which introduce a lot of useless complexity. But it seems that Woodpecker CI [1] could be a good candidate to replace GitLab CI, as it uses very similar concepts and workflow description files.
[1] https://woodpecker-ci.org/
Gitea installs like a Breeze
A vanilla git server works great too.
stay discoverable with your local git by annoucing it to nostr git servers gittr.space
Welcome, i left 2 years ago, i'm surprised more haven't.
I use https://sharemygit.com to share repos around.
I blame Microslop
[dead]
[dead]
[flagged]
Are you talking about this https://www.theguardian.com/technology/2016/feb/12/women-con...
That was 12 years ago. I think probably those feminists are not the cause of GitHub's recent troubles.
[flagged]
That did not read like an AI post and anyway it contained a lot of information and points a share! That is the point.
Being the “first(!) post” to complain about AI, correctly or not, is the new street cred.
> I mean, come on. We all look like a bunch of wankers. Please, remember the old times, like the 2000s.
I mean this in the least dismissive way possible, cause I quite like it, but this isn't good enough prose for the average LLM.
It's not an AI post, but believe what you want.
The problem is nothing competes with GitHub.
I know, GitLab. Gitea. Bitbucket. They have some features, but it’s like suggesting I drive a Nissan Sentra because my BMW breaks down once in a while.
My dude, that Nissan will get you from point A to point B just as effectively as a BMW will. Your analogy is working against you, not for you.
Yes, but they were looking at it from the perspective of features, not reliability.
It’s only fair when the big guy steals intellectual property from the small guy.