It's a huge miss for this article to not talk about atproto, Tangled, and how protocols can solve the fragmentation issues - both between different services and by allowing projects to run their own host while being connected to the network.
With the atproto approach you don't have to worry about reserving usernames specifically for one forge or another - usernames are atproto handles, your Bluesky handle, custom domain, etc.
I'm not sure if Tangled itself is the right incarnation of these ideas, but a protocol for PRs, issues, forks, and activity is the right direction for the industry.
It doesn't even seem to mention federation over/with git and/or ForgeFed (https://forgefed.org/), both efforts predate both atproto and Tangled, and seems like a bigger miss considering the article is literally about git forges.
I don't think we're anywhere close to the downfall of GitHub. It'll be a very slow decay.
The fact is, lots of people are very happy using AI tools, and most of those hook straight into GitHub. If AI is driving all this new code, it's only going to make moving away from GitHub more painful.
Businesses I've spoken to hate the idea of moving their code forge. Migrations like that suck and they're expensive. There isn't a meaningful differentiator between the other managed options, so the goal would just be to stand still. Unless GitHub's stability spirals fast I don't see a big wave of businesses leaving.
I say all this as someone who's been moving their code over to their own Forgejo instance. I'm all for more competition and fragmentation in this area, I just don't think it's happening soon.
forge "fragmentation" is a good thing. git was meant to be decentralized from the start. re-centralizing on a single provider would just repeat the github saga all over again.
That looks like a whole load of work. The thing thay is not defined is why I should do it.
Also forge are already fragmented. I use OpenBSD and the software in ports comes from all over the web. You got the forges, web links,… As far as collaboration go, you can always send an email to the person. Up to them to accept it. If I care that much, I will publish a blog post or share it via the community’s channel.
Those articles look like linkedin-style post to work on your brand or for some internet points.
I think these articles are meant for people who entered the developer ecosystem after GitHub became ubiquitous, because those developers basically only ever known GitHub, and some even see GitHub and Git as synonyms.
The rest of us who started developing before GitHub, or been around communities that self-host their infrastructure, we're already used with everything being spread all over the place, this place accepts patches via email, this one wants a URL to a pastebin containing the patch, others use GitLab, some the public service, others self-hosted, and so on.
I don't think this sort of article is for us, but for the former mentioned usergroup.
It's a huge miss for this article to not talk about atproto, Tangled, and how protocols can solve the fragmentation issues - both between different services and by allowing projects to run their own host while being connected to the network.
https://tangled.org/
With the atproto approach you don't have to worry about reserving usernames specifically for one forge or another - usernames are atproto handles, your Bluesky handle, custom domain, etc.
I'm not sure if Tangled itself is the right incarnation of these ideas, but a protocol for PRs, issues, forks, and activity is the right direction for the industry.
It doesn't even seem to mention federation over/with git and/or ForgeFed (https://forgefed.org/), both efforts predate both atproto and Tangled, and seems like a bigger miss considering the article is literally about git forges.
I don't think we're anywhere close to the downfall of GitHub. It'll be a very slow decay.
The fact is, lots of people are very happy using AI tools, and most of those hook straight into GitHub. If AI is driving all this new code, it's only going to make moving away from GitHub more painful.
Businesses I've spoken to hate the idea of moving their code forge. Migrations like that suck and they're expensive. There isn't a meaningful differentiator between the other managed options, so the goal would just be to stand still. Unless GitHub's stability spirals fast I don't see a big wave of businesses leaving.
I say all this as someone who's been moving their code over to their own Forgejo instance. I'm all for more competition and fragmentation in this area, I just don't think it's happening soon.
forge "fragmentation" is a good thing. git was meant to be decentralized from the start. re-centralizing on a single provider would just repeat the github saga all over again.
Yeah, it's like lamenting the great food supply fragmentation.
That looks like a whole load of work. The thing thay is not defined is why I should do it.
Also forge are already fragmented. I use OpenBSD and the software in ports comes from all over the web. You got the forges, web links,… As far as collaboration go, you can always send an email to the person. Up to them to accept it. If I care that much, I will publish a blog post or share it via the community’s channel.
Those articles look like linkedin-style post to work on your brand or for some internet points.
I think these articles are meant for people who entered the developer ecosystem after GitHub became ubiquitous, because those developers basically only ever known GitHub, and some even see GitHub and Git as synonyms.
The rest of us who started developing before GitHub, or been around communities that self-host their infrastructure, we're already used with everything being spread all over the place, this place accepts patches via email, this one wants a URL to a pastebin containing the patch, others use GitLab, some the public service, others self-hosted, and so on.
I don't think this sort of article is for us, but for the former mentioned usergroup.