Handling the great code forge fragmentation

> 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.

Yep, been through a somewhat pointless GitHub to GitLab migration because, at the time, GitLab was cheaper. Now GitHub is cheaper again and the migration was a big annoying and expensive project.

I’m prob not the “average” user in this context (meaning that I am not a SWE or professional developer, but rather a code-curious sysadmin and consultant with too many hobbies), and I consistently use GitHub Copilot to write and push code to a self-hosted Forgejo…unless it’s a productive fork for contributing, or simply something I don’t want to take up space on my own server, anyway. I agree it’s likely to be a slow decay. GitHub is problematic, but it doesn’t summon the sort of white-hot resentment that pushed people to abandon other platforms en masse.

I am concerned that it will be much more difficult to discover FOSS projects with whatever the new regimes are, similar to how Discord has walled off a great deal of the discussion forums and collaborative groups.

> It'll be a very slow decay

Two ways. Gradually and then suddenly.

> 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.

Anecdotal, but we've had success with gitea and having agents use "tea" (gh cli alternative) as a skill. If the cli tool you're asking it to use is similar enough it will use it instead of gh without any (major) issues.

I think this is true of github as a forge but it faces the threat of unbundling. Off the top of my head

- Code repository

- Project wiki

- Project roadmap/planning

- Static site hosting

- Issue tracking

- Internal and external contributions (PRs)

- Code review

- Cross platform CI pipelines/runners

- Release hosting

Of these key things, what is Github good at and how much can you improve by providing an alternative that's faster/cheaper/more robust?

Of these I think the only thing Github stays competitive at is "code repository." Everything else kinda sucks and/or is expensive and flaky.

Just as an example, there's that hilarious "just give me an EXE" Reddit post from a few years back. It's fun to laugh it given the state/purpose of Github but you can also look at that as a lost market for Github. Why can't you provide a nice landing page with downloads/installers in a very clean landing page for your project on GitHub? It could even be a premium feature if it means paying for storage/bandwidth.

And don't get me started on actions. Absolute trash tier product that they should be ashamed at the state of.

Yeah, it's like lamenting the great food supply fragmentation.

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.

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.

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 think it's great people are working on it, but why reinvent the wheel? Radicle and Forgejo/Forgefed were already under way before starting Tangled. What would be a selling point that would justify breaking compat with existing solutions ? (to be fair, forgefed is largely unimplemented so far)

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.

> The thing thay is not defined is why I should do it.

Most of the reasons seem to boil down to "X bad", where X is some combination of Github, Microsoft, America, and AI

I have found Forgejo’s actions to be functional for my own purposes, although rather incomplete compared with GitHub. That said, porting an action from GitHub to Forgejo was fairly easy the one time I was forced to do so.