Handling the great code forge fragmentation • Hacker News Board

Re: Handling the great code forge fragmentation

#31

Post by account42 » Thu, May 21, 2026, 11:59 AM UTC

ChickeNES wrote: post #16

embedding-shape wrote: post #6

Earlier quoted context omitted.

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…

> this place accepts patches via email, this one wants a URL to a pastebin containing the patch I for one would never contribute to a project that requires one of the above. I know some will shoot back with "but Linux!", but that's the exception that proves the rule.

And maybe those projects don't want your spend time on your contributions if sending an email is already too much effort for you.

Re: Handling the great code forge fragmentation

#32

Post by spankalee » Thu, May 21, 2026, 4:27 PM UTC

account42 wrote: post #30

spankalee wrote: post #18

Earlier quoted context omitted.

atproto apparently has some real advantages over ActivityPub in terms of data portability. Similar to Bluesky vs Mastodon, with Mastodon you're fairly strongly coupled to your server, you' can't just move your data and retain all your connections. atproto makes that possible, and that could be really important if you want to say move from a shared forge to a self-hosted one or vice versa. atproto apps also tend to se…

atproto as it is today is effectively centralized.

That really isn't true. I know people who run their own PDSes, and who've moved their accounts from Bluesky's to their own and back. You can't do that kind of thing with Mastodon. Blacksky also runs their own PDS, relay, and app view.

And that's just the Bluesky-like apps. Other non-microblog atproto apps use their own PDS, or store data on yours.

Re: Handling the great code forge fragmentation

#33

Post by riedel » Sat, May 23, 2026, 7:25 AM UTC

woodrowbarlow wrote: post #7

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.

it is good if people actually develop good workflows. Actually in applied research/public gov tech we are seeing tons of different gitlab instances.

One project we are contributingto the Fraunhofer team developing it has had an internal gitlab with CI/CD and mirrors at three different sites: gitlab.com, opencode.de and code.europa.eu . Now they are slowly trying to move to gitlab.com for the main repo as they cannot open their own repo enough for security/legal reasons. However, the CI/CD stuff still only runs on their gitlab.

Now we have our own gitlab instance we, were we are doing some small frontend work as part of a funded project on national level and have a mirror on GitHub for visibility reasons. Now we have another EU funded project that has its CI/CD on another gitlab instance at a partner. All come with their own onboarding and federated IDM quirks.

It is a total mess. While git is certainly distributed, the workflow is a mess. You end up cherrypicking CI/CD configs and divergent features all over the place.

I wonder: Is there a l'meta-forge' that just would handle rebasing?

I actually understand people using bare git workflow with mailing lists. However, even for me the learning curve and necessary attention span/social contracts is too much a challenge.

Re: Handling the great code forge fragmentation

#34

Post by woodrowbarlow » Tue, May 26, 2026, 12:12 PM UTC

selfhoster1312 wrote: post #13

woodrowbarlow wrote: post #7

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.

I upvoted because i agree with the message. Although, it would be much better if we could just have a single identity over those providers, just like we had with mailing lists.

i mean, in git (on its own) you can use your email + GPG key across every repo as a universal ID. it's just that forges add an identity layer on top, too.