Evaluating new software forges

I would call expecting any developer to do it differently quite an entitled opinion. And DeVault has a way better track record on successful projects (some of which continue being successful after he moved on with the help of the communities he fostered) than any of us really.

Experience shows that it's very difficult to make a business work on top of open source software and he is doing it as we speak. Your complaint smells like a petty grudge in the face of all the other things that could be said about his projects.

I would agree... in its GitHub incarnation.

> You have the repo on your machine, and you have a public upstream. You don't need an third copy on your own server, too—you just need a place to publish what you actually changed.

Which is... where? The PR+fork model is what that implements: fork for the always-on storage so that upstream can fetch from it, PR for upstream to be notified about, discuss around, follow subsequent updates of, and track integration of the changeset.

The problem in the GitHub model is that it's all happening on a single centralised platform, removing the distributed benefits of Git at great benefit to GitHub through network effects, stifling competition.

What I propose is that the always-on storage need not be at GitHub, and there'd be a notification system towards GitHub to point to that always-on storage. Could be a bare GitHub repo with GitWeb (which is something one has to set up) + a curl to an upstream API endpoint, but sooner or later people are going to want to have a bit more than that, so having a forge do that (either a self-hosted one like Gitea/Forgejo or any hosted one like SourceHut/Codeberg/GitLab/Bitbucket) is practical.

This essentially makes forges interoperable, restoring the distributed nature of git development that GitHub killed by centralising git hosting.

(Of course you can s/GitHub/whatever-derivative/g above, I just focused on GitHub for the sake of simplicity because it's the monopolistic elephant in the room)

We agree that GitHub's fork+PR workflow gives you the functional equivalent. But it is sufficient, not necessary.

If you're working on a 600 MB repo and want to submit changes comprising 100 lines of additions and deletions as a first-time (and possibly one-time) contributor, forcing you to coordinate an additional always-on third copy of that repo is, as I said, total overkill for your ~5KB of changes—and that's before we even address that this is something that's required from every contributor.

> I would agree... in its GitHub incarnation

No, you're missing the point. Git wasn't even designed for Github-style pull requests (no matter where they're hosted). That's why Git doesn't actually have them. Only GitHub does (and everyone who decided to copy them).

It's not just the fact that everyone centralizes around a single site that's the problem. It's that fork+PR for every single change from every single contributor is fundamentally the wrong model to begin with. "Pull requests" are for frequent collaborators, like the core development team on a given project: they all have each other's repos in their remotes for pushing and pulling to/from whomever they're working with on a given thing when they're working together. Non-core contributors shouldn't even be worrying about the question of "where" to host things—they don't need to host things—who'd want to pull from them, and why? (And why burden them with provisioning hundreds of megabytes—or, in aggregate, gigabytes—of always-on online storage? Again: complete overkill.)