The Platform Wars: One Company, All the Code

The Monday Morning Exodus

This is episode thirty-eight of Git Good.

On a Monday morning in June two thousand eighteen, thirteen thousand projects moved from GitHub to GitLab in a single hour. The reason was three words long. Microsoft acquires GitHub. Seven and a half billion dollars in Microsoft stock for the platform that hosted the majority of the world's open source code. And the developer community, or at least a very loud fraction of it, panicked.

GitLab imported over one hundred thousand repositories in the first twenty-four hours. They saw a seven times increase in orders. Bitbucket, Atlassian's hosting service, had its biggest sign-up day in history. Developers were fleeing, or at least threatening to flee, from the company that now owned the place where their code lived.

Microsoft's CEO Satya Nadella tried to calm the storm with a statement that sounded carefully rehearsed.

GitHub will remain an open platform. Developers will continue to be able to use the programming languages, tools and operating systems of their choice.

He was right, as it turned out. GitHub did remain open. Microsoft did not burn it down. In fact, it invested heavily. Free private repositories. Better performance. New features. The developers who left mostly came back. The ones who stayed never noticed a difference. Within a year, the panic looked like overreaction.

But the panic revealed something that the calm afterwards did not erase. Over one hundred million developers had their code, their issues, their pull requests, their continuous integration pipelines, their professional identities, all sitting on a single platform owned by a single corporation. And when that corporation changed hands, the only thing those developers could do was copy their repositories somewhere else and hope. The code was portable. Everything else was not.

That gap between what you can take with you and what you cannot is the story of the platform wars. And seven years later, it is wider than ever.

The Gravitational Pull

To understand the platform wars, you have to understand the numbers. And the numbers are staggering.

As of two thousand twenty-three, GitHub reported one hundred million developers. Four hundred and twenty million repositories. Twenty-eight million of those public. In two thousand twenty-four alone, developers made five billion contributions to more than five hundred million open source projects on the platform. Thirty-six million new developers joined in two thousand twenty-five. Not thirty-six million people who tried it. Thirty-six million new accounts that stayed.

GitLab, the largest alternative, is a distant second. Bitbucket is smaller still. SourceHut, Codeberg, Gitea, Forgejo, all of the independent and self-hosted alternatives combined, are a rounding error next to GitHub's numbers. Not because they are bad. Some of them are better at specific things than GitHub will ever be. But GitHub got there first, grew fastest, and built the network effect that makes leaving feel like moving to a country where nobody speaks your language.

The network effect works like gravity. The more developers who are on GitHub, the more projects that live there. The more projects that live there, the more developers need to be there. Every open source library you depend on. Every project you want to contribute to. Every employer who asks for your GitHub profile. Every tutorial that starts with "clone this repository from GitHub." The gravity pulls everything toward one center. And the center has a name and a corporate owner.

In the previous episode, we saw how the fork button became the most powerful governance tool in open source. Someone forks a project, the community follows, the original steward loses control. That mechanism works because Git makes code portable. You clone, you push, you are somewhere else. The code follows you.

But here is what the fork stories did not tell you. When io.js forked Node, when LibreOffice forked OpenOffice, when MariaDB forked MySQL, the code moved cleanly. The issues did not. The pull request discussions did not. The continuous integration pipelines did not. The contributor graphs, the project wikis, the release automation, the security scanning, the package publishing, none of it moved. All of that infrastructure is platform-specific. And for the vast majority of open source, that platform is GitHub.

Your Git repository is yours. It is a complete history, distributed, portable, the exact thing Linus Torvalds designed it to be. Everything you have built around that repository belongs to the platform.

The Enterprise Alternative

There is exactly one company that has built a credible business being the place you go when you do not want to be on GitHub. That company is GitLab.

The GitLab story starts in two thousand eleven, when a Ukrainian developer named Dmitriy Zaporozhets started building a self-hosted Git management tool. He was joined by Sid Sijbrandij, a Dutch entrepreneur who saw an opportunity in the gap between GitHub's cloud-only model and what enterprises actually needed. The pitch was simple. Your code, on your servers, under your control. No dependency on anyone else's platform.

Sijbrandij's vision went further than just hosting repositories. GitLab would be a complete development platform. Not just where your code lives, but where it gets tested, reviewed, deployed, monitored. Everything from the first commit to the running production system, in one tool. And the core of it would be open source. Anyone could download GitLab Community Edition, install it on their own server, and run it for free. If you wanted the enterprise features, you paid for GitLab Enterprise Edition. Open core, they called it. The community builds the foundation. The company sells the penthouse.

The model worked. GitLab grew. It became the standard alternative, the thing companies adopted when they did not want their source code on someone else's cloud, or when their compliance requirements demanded self-hosting, or when they simply did not trust that GitHub's owner would not change the rules. When the Microsoft acquisition sent developers scrambling, GitLab was the obvious destination.

On October fourteenth, two thousand twenty-one, GitLab went public on the Nasdaq. The shares were priced at seventy-seven dollars. They opened at ninety-four and closed above one hundred and three. The company was valued at nearly fifteen billion dollars on its first day of trading. Sid Sijbrandij, the Dutch entrepreneur who had seen the opportunity a decade earlier, was now a billionaire.

But being the alternative to a monopoly is a strange business to be in. You grow when the monopoly makes mistakes and shrink when it behaves well. Microsoft, to the frustration of everyone who predicted catastrophe, turned out to be a competent steward of GitHub. The anticipated exodus never materialized at scale. GitLab found its niche in enterprises that needed self-hosting and DevOps integration, but it never seriously threatened GitHub's hold on open source.

Then Sijbrandij got sick. In November two thousand twenty-two, he was diagnosed with osteosarcoma, a rare bone cancer. A six-centimeter tumor growing from a vertebra in his upper spine. He continued as CEO for two years while undergoing treatment, but in December two thousand twenty-four, he stepped down.

I want more time to focus on my cancer treatment and health. My treatments are going well, my cancer has not metastasized, and I am working towards making a full recovery.

Bill Staples, previously the CEO of New Relic, took over. GitLab's stock, which had touched highs after the IPO, sat around thirty-seven dollars. A company that had been valued at nearly fifteen billion was now worth a fraction of that. Not because the product was bad. GitLab remains a serious, capable platform. But the market had decided that being the alternative to GitHub was worth less than everyone had hoped.

GitLab's story is a lesson in what it takes to compete with a platform that has gravitational pull. You can build a better product. You can offer self-hosting. You can go public and raise hundreds of millions. And you can still end up as the second choice, the thing people reach for only when the first choice is not an option. Not because you lost, but because the network effect decided the game before you started playing.

The Radical Minimalist

If GitLab represents the enterprise alternative, Drew DeVault represents something else entirely. The philosophical alternative. The person who looks at GitHub and GitLab and every other web-based forge and says that the entire concept is wrong.

DeVault is a programmer, the creator of the Hare programming language and the Sway window manager, and the founder of SourceHut, which he calls "the hacker's forge." SourceHut looks like nothing else in modern software. No JavaScript. Minimal styling. Mostly shades of gray. When you visit a repository on SourceHut, nearly the entire page is dedicated to the source code. There is no giant sign-up banner, no colorful sidebar of activity graphs, no gamified contribution streaks.

It is an engineering tool first and foremost. It is important to bring the information you are there for to the forefront, and minimize distractions.

The minimalism is not aesthetic. It is political. DeVault's argument is that platforms like GitHub have turned software development into a social media experience. The green contribution squares. The follower counts. The star ratings. All of it designed to keep developers on the platform, engaged, performing productivity for an audience, rather than writing software. SourceHut strips all of that away. No tracking. No advertising. A subscription model, where users pay directly for the service. The business model is the product, not the users' attention.

But the most radical thing about SourceHut is not how it looks. It is how code review works. SourceHut uses email. Not a pull request interface. Not a merge request page. Email. You generate a patch with git send-email, you send it to a mailing list, reviewers reply with comments, and when the patch is ready, it gets applied. This is the workflow that built the Linux kernel, PostgreSQL, and the BSDs. DeVault argues it is not just viable but superior.

ActivityPub would build a second, incompatible federation of projects, while ignoring the already productive federation which powers many of our most important open source projects.

His claim is simple. Git is already federated. Email is the federation protocol. It has been since Linus Torvalds built git send-email into the tool in two thousand five. Every SMTP server in the world is already part of the network. You do not need ActivityPub. You do not need a new protocol. You need people to use the one that already exists.

The argument is elegant. It is also losing. SourceHut has a devoted user base, but it remains tiny compared to even the smaller alternatives. The email workflow, for all its technical merits, asks developers to learn a process that most of them have never encountered. The same wall that keeps beginners out of Git itself keeps them out of SourceHut. DeVault knows this. He has written openly about burnout, about the difficulty of building something that most people do not want. But he keeps building, because his argument is not about market share. It is about principle. Software development happened on email for decades before GitHub existed. It can happen on email again. Whether it will is a question that the market has been answering, quietly and consistently, in the other direction.

The Federation Dream

In the previous episode, we met Forgejo, the community fork of Gitea that declared independence when its project's domains were transferred to a company without the community's knowledge. Forgejo lives on Codeberg, a German non-profit, and it is building something that neither GitHub nor GitLab nor SourceHut has attempted. Federation.

The idea is borrowed from email, or from Mastodon, or from the way the internet was supposed to work before platforms swallowed it. Imagine you run a Forgejo instance on your own server. Someone else runs a Forgejo instance on theirs. With federation, you could star their repository from your instance. Open an issue on their project without creating an account on their server. Submit a pull request across the network. Follow a developer on a different forge the way you follow someone on Mastodon from your own Mastodon server. A network of small, independent forges instead of one enormous platform.

The protocol is called ForgeFed, and it extends ActivityPub, the same standard that powers Mastodon, PeerTube, and the rest of the fediverse. In two thousand twenty-four, Forgejo shipped its first federation feature. Federated repository stars. You can star a repository on another Forgejo instance and the star shows up on both sides. It sounds small. It is small. But it is the first brick in a wall that could, theoretically, break GitHub's gravitational hold.

The federation effort has backing from NLnet, a European foundation that funds open internet projects. The Friendly Forge Format, a data portability standard that lets you mirror projects between forges, published its first stable version in June two thousand twenty-four. The pieces are being assembled. Slowly.

But "slowly" is the word that matters. Federation is still experimental. Moderation tools have not been built. Access control across instances is unsolved. The Forgejo project explicitly warns that breaking changes can happen without notice, that a domain used for federation today might become permanently unusable if the protocol changes. These are not signs of failure. They are signs of something genuinely early, something being built in public with honesty about how far it has to go.

Drew DeVault would say they are solving the wrong problem. Email already federates. Forgejo would say email excludes most developers. Both are right. And neither has the numbers to challenge GitHub.

The real question about federation is not whether it can work technically. ActivityPub works. Email works. The question is whether federation can overcome the network effect. Whether a constellation of small forges, each running their own instance, each federated with the others, can provide the same frictionless experience as typing github.com into a browser. History suggests it cannot. Email is federated, and Gmail still has nearly two billion users. The web is decentralized, and most of it runs through Cloudflare. Mastodon is federated, and most people still use centralized social media. The pattern is consistent. Decentralized protocols create centralized outcomes, because convenience always wins.

But the people building federation are not trying to replace GitHub tomorrow. They are trying to ensure that an alternative exists. That when GitHub changes its terms of service, or raises its prices, or makes a decision that its users disagree with, there is somewhere to go that is not just another company's platform. The exit may never be used by millions. But its existence, like the fork button, keeps the powerful honest.

The Switching Cost Trap

There is a reason the Monday morning exodus of two thousand eighteen fizzled. Not because developers decided they trusted Microsoft after all. Because they discovered how much of their work was not in Git.

Your Git repository is portable. You clone it, push it somewhere else, done. Everything that Linus designed, the full history, every branch, every tag, every commit, travels with you. That part works exactly as advertised.

But a modern software project on GitHub is far more than a Git repository. Your continuous integration pipelines are written in GitHub Actions workflow files, a format that only works on GitHub. Your secrets, API keys and deploy tokens, are stored in GitHub's vault. Your issue tracker, every bug report, every feature request, every discussion, lives in GitHub's database. Your pull requests, with all their review comments and approval chains, are GitHub objects with no standard export format. Your release automation, your package publishing, your security scanning, your dependency graphs, all of it is GitHub-specific.

Moving your code takes minutes. Rebuilding everything around it takes months. And every year, the platform adds more features that make the code less important relative to the infrastructure surrounding it. GitHub Actions was launched in two thousand nineteen. GitHub Copilot in two thousand twenty-two. GitHub Advanced Security. GitHub Codespaces. Each feature makes the platform more useful and the cost of leaving higher.

This is not an accident. It is a business model. Microsoft does not charge most developers to use GitHub. The free tier is generous. The trap is not the price. The trap is the dependency. By the time an organization realizes it is locked in, it has years of workflow configuration, team processes, and institutional knowledge embedded in GitHub's proprietary features. The code is free to leave. The organization is not.

We wanted to move after the acquisition. We started evaluating alternatives. Then we looked at our GitHub Actions workflows, our branch protection rules, our security scanning, our CODEOWNERS files. We estimated six months of engineering work just to migrate the CI pipelines. We stayed.

That story repeats across the industry. The platform has become more important than the protocol. Git gives you freedom. GitHub takes it back, one convenience at a time.

The AI Moat

And then came the feature that changed the calculus entirely.

In June two thousand twenty-two, GitHub launched Copilot, an AI coding assistant trained on every public repository on the platform. The training data question, whether open source licenses grant the right to train an AI, is a story for the next episode. But the competitive implications are immediate.

GitHub Copilot reached twenty million users by mid two thousand twenty-five. Four point seven million paid subscribers by early two thousand twenty-six. Ninety percent of Fortune one hundred companies use it. It holds roughly forty-two percent of the AI coding assistant market. And it is deeply, deliberately integrated with the GitHub platform.

This is the lock-in that none of the alternatives can replicate. GitLab can match GitHub's CI features. Forgejo can build federation. SourceHut can offer a purer workflow. But none of them have the training data. None of them have one hundred million developers' worth of code patterns, review comments, issue resolutions, and workflow signals to train an AI on. Copilot is not just a feature. It is the product of a monopoly's data advantage, turned into a tool that makes the monopoly harder to leave.

GitHub will remain an open platform.

Nat Friedman said that in two thousand eighteen, when he became GitHub's CEO after the Microsoft acquisition. He was talking about openness. But the AI moat creates a different kind of closure. Not the closure of restricting access to the platform. The closure of making the platform so much more capable than the alternatives that leaving becomes irrational. Why would you move your code to a forge that does not have Copilot, that cannot autocomplete your functions, that cannot summarize your pull requests, that cannot find security vulnerabilities using patterns learned from billions of lines of code?

The answer, for most developers, is that they would not. And that answer gets more definitive every month as AI features improve. The platform wars may have already been decided. Not by Microsoft buying GitHub. Not by the network effect that GitHub built over a decade. But by the AI advantage that only a platform with one hundred million developers' data can build.

Drew DeVault would say this proves his point. That centralizing code on a corporate platform created exactly the power asymmetry he warned about. The Forgejo community would say this is why federation matters more than ever, why data should not live on a single company's servers. GitLab would say their own AI features, trained on their own data, can compete. They are all making arguments, and while they argue, GitHub is shipping features.

The Map of the War

Step back far enough and you can see the whole battlefield.

At the center is GitHub. One hundred million developers. Backed by Microsoft's resources. Copilot as the AI moat. GitHub Actions as the workflow lock-in. The gravitational pull of a decade of network effects. Most open source lives here. Most developers work here. Most of the industry has decided this is good enough.

At the first ring out is GitLab. The enterprise alternative. Self-hosting as the differentiator. A public company with real revenue, real customers, and a real product. But a company that lost its founder to illness, saw its stock decline from IPO highs, and exists in the permanent shadow of a competitor with ten times its user base.

At the second ring is the self-hosting movement. Gitea, the lightweight Go forge. Forgejo, its community fork, building federation on Codeberg's infrastructure. These serve the developers and organizations who have decided, on principle or for compliance, that their code should not live on someone else's cloud. The communities are small but committed. The tools are capable but lack the polish and integration of the major platforms.

And at the outer edge is SourceHut. Drew DeVault's radical experiment. Email-based code review. No JavaScript. No gamification. A subscription model instead of venture capital. The philosophical purist's answer to a question most developers are not asking. SourceHut exists to prove that software development does not need platforms at all. That Git itself, with email as the transport layer, is enough.

Each ring outward trades convenience for principle. GitHub is the most convenient and the least free. SourceHut is the least convenient and the most free. Every developer, every project, every organization sits somewhere on that spectrum, and most of them are closer to the center than they would like to admit.

The platform wars are not really wars at all. Wars imply that the outcome is uncertain. This is a monopoly and its discontents. GitHub won. The question is whether the alternatives can survive long enough to matter when, not if, GitHub makes a decision that makes survival necessary. When the terms of service change. When the pricing shifts. When the AI features come with strings attached. When the platform that promised to remain open decides that open is no longer profitable.

The fork button, the one we talked about in the last episode, gives communities power over their code. But it gives them no power over their platform. You can fork a repository in seconds. You cannot fork GitHub.

That is the real platform war. Not a war between companies. A war between the portability that Git promises and the lock-in that platforms deliver. Git was designed to be free. The platforms were designed to be profitable. Those two goals coexist peacefully right up until the moment they do not. And when that moment comes, the developers who prepared, the ones who kept their workflows portable, who tested their backups, who knew how to run their own forge, will be the ones who survive it.

Everyone else will be looking for the next Monday morning exodus. And hoping this time they actually leave. That was episode thirty-eight.

Git remote set-url origin is the command that moves your repository from one platform to another. It changes where git push sends your code. The syntax is git remote set-url origin followed by the new URL. Your full history, every branch, every tag, every commit follows you. The command takes less than a second. It is the easiest part of leaving a platform, and it is the only part that Git can help you with. Your issues, your pull requests, your CI pipelines, your secrets, your review comments, your automation, none of that comes along. Git remote set-url origin moves the code. Everything else, you rebuild by hand.