Beyond GitHub

What If GitHub Disappeared Tomorrow

Imagine GitHub goes offline. Not for an hour, not for a maintenance window. Gone. Servers wiped. Domain dead. What happens?

The code survives. Every developer who ever cloned a repository has a complete copy of it, every commit, every branch, every tag, sitting on their laptop. That is the whole point of distributed version control. Linus built Git so that no single machine mattered. And in that narrow sense, the design works perfectly.

But here is the part nobody talks about. The code is the easy part. What about the two hundred million pull requests? The billion issues? The CI pipelines that build and test every change? The package registries that npm, RubyGems, Docker images, all hosted on GitHub? The contributor discussions, the code review comments, the project wikis? None of that lives in your Git clone. None of it is distributed. All of it sits on servers owned by Microsoft, in data centers you will never visit, governed by terms of service you did not read.

Git decentralized the code. GitHub re-centralized everything else. And over the last seventeen years, "everything else" grew to be more important than the code itself. A pull request is not just a diff. It is a conversation, a review, a CI run, a deployment trigger, a record of why a decision was made. Lose the pull request and you lose the context. The code tells you what changed. The pull request tells you why.

So the question is not hypothetical. It is architectural. If one company controls the collaboration layer for most of the world's software, what are the alternatives? And can anyone build something that is both decentralized and usable enough for people to actually switch?

A few groups have been trying. Their approaches could not be more different.

GitLab and the Self-Hosted Alternative

In October two thousand eleven, a software developer named Dmitriy Zaporozhets was working at a consulting firm in Kharkiv, Ukraine. He used version control every day and found the available tools lacking. There was no modern, open source platform you could install on your own server that gave you the full experience: code hosting, issue tracking, merge requests, all in one package.

So he started building one as a hobby project, together with a colleague named Valery Sizov. They discussed the vision over coffee, sketching out what a complete development platform should look like. The result was GitLab, and the first commit landed in October two thousand eleven, just six years after Linus created Git itself.

I was working as a software developer. I worked with version control every day. There was no modern open source software to run on your server, and I saw an opportunity to make something useful as a hobby project.

Zaporozhets later wrote those words in a farewell post. GitLab grew an open source community in that first year, but the moment that changed its trajectory came in two thousand twelve. A Dutch entrepreneur named Sid Sijbrandij discovered the project and thought it was natural that a collaboration tool for programmers should itself be open source, so that everyone could contribute to it. He posted on Hacker News asking if people would be interested in a hosted version at GitLab dot com. Hundreds signed up for the beta.

Sijbrandij sent Zaporozhets an email that was remarkably direct. Hey, I am going to start a company around GitLab. A year later, Zaporozhets quit his job in Ukraine and joined full-time. They were accepted into Y Combinator in two thousand fifteen, and the company grew from there. By October two thousand twenty-one, GitLab went public on Nasdaq.

What made GitLab different from GitHub was not any single feature. It was a philosophy. GitLab called its approach "open core." The community edition was fully open source, free to download, free to install on your own server. The enterprise edition added features like advanced security scanning and compliance tools on top of that open core. But the crucial part was this: you could always run GitLab yourself. Your code, your server, your data, your rules.

This mattered enormously to companies in regulated industries, to governments, to organizations that could not send their source code to someone else's cloud. A bank in Frankfurt, a defense contractor in Virginia, a hospital system bound by data residency laws, they could run GitLab behind their own firewall and still get the full modern development experience. GitHub offered something similar later with GitHub Enterprise Server, but GitLab was built self-hosted first.

GitLab also pushed the concept of a single application for the entire development lifecycle. Not just code hosting and merge requests, but CI pipelines, container registries, security scanning, deployment automation, monitoring, all in one platform. Their pitch was blunt: stop stitching together fifteen different tools. Use one.

When Microsoft announced the GitHub acquisition in June two thousand eighteen, GitLab had its biggest day ever. Developers who did not trust Microsoft flooded to GitLab, importing their repositories by the thousands. GitLab reported that imports spiked to ten times normal volume. The migration was real, even if most developers eventually stayed on GitHub out of inertia.

But GitLab is still a company. A publicly traded company, answerable to shareholders, driven by revenue targets. The open core model means the free version is genuinely useful, but the most powerful features live behind a paywall. And while self-hosting gives you control over your data, you are still dependent on one company's roadmap, one company's decisions about what stays free and what gets locked behind enterprise pricing.

GitLab proved that GitHub could be challenged. But it did not solve the centralization problem. It just offered a different center.

Drew DeVault's Minimalist Rebellion

In November two thousand eighteen, a developer named Drew DeVault launched an alpha of something called SourceHut. If GitLab was the answer to "what if GitHub but you can self-host it," SourceHut was the answer to a much more radical question: what if we went back to how things worked before GitHub existed?

DeVault is not subtle about his opinions. He has written extensively about what he sees as the damage GitHub has done to software development. His argument goes roughly like this: GitHub took a beautifully distributed tool and trapped it inside a centralized, proprietary web application stuffed with features nobody asked for. Stars, followers, contribution graphs, trending repositories, all of it social media machinery designed to keep you on the platform, not to help you write better software.

SourceHut strips all of that away. There are no stars. No follower counts. No contribution graphs. No JavaScript, literally none. The entire web interface works in a plain text browser from the nineteen nineties. Every page loads in milliseconds because there is almost nothing to load.

But the truly radical choice is the workflow. SourceHut uses email for code review. Not a custom web interface with inline comments and approval buttons. Actual email. You write a patch, you send it to a mailing list with git send-email, reviewers reply with comments, you send a revised patch. This is exactly how the Linux kernel has operated since before Git existed, and it is how SourceHut thinks all software should be reviewed.

Git is already federated and decentralized. Email is the standardized, proven federation mechanism that has existed since Git's inception.

DeVault's argument is that email solves the federation problem that newer projects are trying to reinvent. If you use email for patches and code review, any developer with an email address can contribute to any project on any server. There is no walled garden. There is no vendor lock-in. Your patches live in your inbox, not on someone else's platform. If a service disappears, you still have every conversation, every review, every decision, sitting in your own email archive.

The Linux kernel, PostgreSQL, the BSDs, Debian, these are some of the most important software projects in the world, and they all use email-driven workflows. DeVault is not proposing anything experimental. He is arguing that the most battle-tested approach to distributed collaboration already exists, and GitHub convinced everyone to abandon it in favor of something prettier but more fragile.

Of course, there is a reason GitHub won. Email-based workflows have a brutal learning curve. Configuring git send-email correctly requires setting up SMTP credentials, understanding email formatting, and learning a set of conventions that are documented nowhere obvious. For a junior developer accustomed to clicking "Create Pull Request," the email workflow feels like being handed a manual transmission after years of driving automatic.

DeVault acknowledges this. He has written that the tools need to be better, that the onboarding experience is too harsh. But his position is that the solution is to improve the email tooling, not to abandon the architecture. Build better tools on top of email, not a second, incompatible federation protocol on top of web forges.

SourceHut charges money. Two dollars a month for the basic plan, twenty for the full suite. No free tier. No venture capital. No advertising. DeVault runs it as a sustainable small business, which means it will never have GitHub's scale, but it also means it answers to its users and nobody else.

The result is a platform that a certain kind of developer loves fiercely and most developers have never heard of. SourceHut is not trying to replace GitHub for everyone. It is trying to prove that a different model is possible, one built on open standards, minimal dependencies, and the radical idea that the tools developers had in two thousand four were actually pretty good.

The Forgejo Fork and the Federation Dream

In two thousand sixteen, a group of developers created Gitea as a lightweight, self-hosted Git platform written in Go. It was easy to install, easy to maintain, and ran happily on modest hardware. A Raspberry Pi could host a Gitea instance for a small team. Where GitLab aimed to be a complete DevOps platform, Gitea aimed to be simple and fast. It attracted a devoted community of self-hosters and small organizations.

Then, in October two thousand twenty-two, something happened that sent shockwaves through that community. The domains and trademark of the Gitea project were transferred to a newly created for-profit company, without the knowledge or approval of the community that had built it. An open letter from contributors demanded transparency. The response confirmed their fears: Gitea was now controlled by a commercial entity.

The pattern was grimly familiar. A community builds something together. A small group captures the trademark and domain. The community's work gets funneled into a corporate vehicle they do not control. It is the same dynamic that played out with OpenOffice and LibreOffice, with MySQL and MariaDB, with Redis and Valkey. The names change. The story repeats.

Within weeks, a group of contributors forked Gitea and created Forgejo. The name comes from "forĝejo," the Esperanto word for forge. They placed it under the umbrella of Codeberg e.V., a non-profit registered association based in Berlin, Germany, that had been founded in September two thousand eighteen specifically to provide free code hosting without corporate control.

Codeberg itself runs on Forgejo and offers free hosting to anyone who wants it. No paid tiers. No venture capital. Funded by donations and membership fees of the non-profit association, with members voting on the budget once a year. The choice to base the organization in the European Union was deliberate. Members were concerned that a repository hosted in the United States could be removed through bad faith copyright claims under the Digital Millennium Copyright Act, a risk that had already materialized for other projects.

For its first year and a half, Forgejo operated as a "soft fork" of Gitea, meaning it tracked Gitea's codebase and applied its own patches on top. But the governance and development goals kept diverging. Gitea moved toward commercial features. Forgejo moved toward community ones. In early two thousand twenty-four, Forgejo made a decisive break: it became a hard fork. No more tracking Gitea's changes. From that point forward, Forgejo was its own project with its own direction.

And that direction includes something genuinely ambitious: federation via ActivityPub.

ActivityPub is the protocol that powers Mastodon, the decentralized social network. It allows users on one server to follow and interact with users on a completely different server, with no central authority coordinating the exchange. What if Git forges could work the same way? A developer on one Forgejo instance could open an issue on a project hosted on a different Forgejo instance. A contributor on Codeberg could submit a pull request to a project on a company's private Forgejo server. Stars, follows, notifications, all flowing between independent servers the way email flows between providers.

The project calls this ForgeFed, and it builds on ActivityPub with extensions specific to software development. It is still under active development, not production-ready, and the technical challenges are substantial. How do you handle permissions across servers? How do you prevent spam pull requests? How do you maintain code review context when participants are on different instances? These are hard problems, and the Mastodon experience has shown that federation introduces friction that centralized platforms avoid.

But the vision is powerful. A world where Git hosting works like email: you pick your provider, or run your own server, and you can collaborate with anyone regardless of where their code lives. No single company controls the network. No acquisition can capture the collaboration layer. The infrastructure is as distributed as Git itself.

Drew DeVault disagrees with this approach. He has argued that building ActivityPub federation for forges creates a second, incompatible federation mechanism when email already provides exactly this capability. Why reinvent what already works? The Forgejo community's counter-argument is pragmatic: email-based workflows, however technically sound, have failed to gain adoption outside a small circle of experienced developers. If the goal is to give ordinary developers an alternative to GitHub, that alternative needs to feel familiar, and pull requests in a web browser feel familiar. Federation just needs to make those pull requests work across server boundaries.

The Cycle Repeats

Pull back far enough and a pattern emerges.

In the beginning, software lived on one machine. A mainframe. A single point of truth, and a single point of failure. Version control was a filing cabinet with a sign-out sheet.

Then came the client-server era. CVS and Subversion gave teams a central server, and developers checked code in and out over a network. Better than the filing cabinet, but still centralized. If the server died, work stopped.

Git distributed the code. Every clone a complete repository. No central server required. Linus built it that way because the Linux kernel could not depend on any single machine, or any single company's good will, as the BitKeeper crisis had proven.

Then GitHub re-centralized the social layer. The code was distributed, sure, but the pull requests, the issues, the CI, the package registries, the profiles, the network effects, all of that lived on one platform owned by one company. And it worked so well that almost everyone went along with it. Convenience is a powerful force. When the thing that is easy to use is also the thing everyone else uses, the network effects compound until switching costs become enormous.

Now a new generation is trying to decentralize again. GitLab offers self-hosting. SourceHut offers email-native workflows built on open standards. Forgejo offers federation. Codeberg offers non-profit stewardship. Each addresses a different part of the problem, and none has cracked the fundamental tension: centralized platforms are more convenient, and convenience wins.

The Git commands for escaping monoculture are simple. You type git remote add, then a name, then a URL. Suddenly your repository pushes to two places instead of one. You type git push followed by dash-dash-all, and every branch goes everywhere. Your code is no longer dependent on a single service. Technically, working with multiple remotes is trivial. Git was designed for exactly this. The hard part is never the commands. It is convincing a community that already lives on GitHub to also check somewhere else.

This is the tension the series has been tracking since the beginning. Speed shapes behavior, and GitHub is fast. Distributed versus centralized, and people choose centralized every time it is slightly more convenient. Tools shape culture, and GitHub shaped a generation of developers who think of version control as a website, not a protocol. Corporate capture, and the question of who owns the collaboration layer remains unanswered.

The optimistic version of this story is that every generation of centralization produces a generation of decentralizers who learn from the last cycle. Email proved that federated systems can scale to billions of users. The web proved that open protocols can support an entire economy. Maybe forge federation will prove that software collaboration does not require a single platform.

The pessimistic version is that convenience always wins and the cycle always ends with a new monopoly. CVS gave way to Subversion gave way to Git, but the social layer consolidated from SourceForge to Google Code to GitHub, each time fewer platforms, each time more concentrated.

The realistic version is probably somewhere in between. GitHub is not going to disappear. Most developers will keep using it because it works and because everyone else does. But the alternatives exist now in a way they did not a decade ago. A small team can spin up a Forgejo instance in an afternoon. A solo developer can host their projects on Codeberg for free. An organization that cares about sovereignty can run GitLab on its own metal. A hacker who believes in the Unix philosophy can use SourceHut and git send-email.

The code was always distributed. Linus made sure of that twenty years ago. The question for the next twenty years is whether the collaboration layer catches up, or whether we keep building cathedrals on top of a tool that was designed for the bazaar.

Git remote add is the escape hatch from monoculture. One command, one URL, and suddenly your code lives in two places instead of one. Push to GitHub and GitLab. Mirror to a self-hosted Forgejo. Back up to a server in your closet. Git was built for exactly this, a tool that does not care where the remotes point, only that they exist. The irony is that the most powerful decentralization feature in Git is the one almost nobody uses.