The Fork Wars: When Open Source Projects Split in Two

The Nuclear Option

This is episode fifteen of Git Good, Season Two. In Season One, we talked about the moment GitHub added a button labeled Fork to the top of every repository. One click, and you had your own copy. The designers thought of it as a collaboration tool, a way to propose changes back to the original. What they did not design it for was governance. They did not imagine it as a weapon. These five stories show exactly what happens when people use it that way. If you did not like how a project was governed, how its leaders made decisions, who controlled its future, you no longer had to argue about it. You could just leave. And take the code with you.

This episode tells five stories about what happens when people press that button and mean it. Not to submit a pull request. Not to experiment. To walk away and build something new. Five forks, five dramas, five different answers to the same question. Who owns an open source project?

The stories span fifteen years, from two thousand nine to two thousand twenty-four. They involve billion-dollar acquisitions, licensing revolts, midnight domain transfers, and a Finnish programmer who named two databases after his daughters. Each fork started with the same fear. Someone, usually a corporation, had gained control of something the community built, and the community wanted it back.

But here is the thing about forking. It sounds clean. Democratic, even. The code is open, anyone can copy it, the best version wins. In practice, a fork is a war. It splits communities. It divides contributors. It forces every user and every company to pick a side. And the outcome is never guaranteed. Some forks die quietly. Some replace the original entirely. And one of them, the strangest one on this list, achieved its goal by merging back into the project it had abandoned, as if the whole rebellion had been a negotiating tactic. Which, honestly, is exactly what it was.

The Leveraged Fork

In two thousand fourteen, Node.js was the hottest runtime in web development, and it was stuck. The project lived under Joyent, the cloud company that employed Node's creator Ryan Dahl and had sponsored its early development. Joyent held the trademark, controlled the repository, and made the calls about what got merged and when. And by late two thousand fourteen, those calls had slowed to a crawl. Contributions were at a five-year low. Releases were rare. The V8 JavaScript engine underneath Node was falling behind Google's latest versions. Developers who wanted to use modern JavaScript features were told to wait.

The frustration was not about code quality. It was about process. Joyent's gatekeeping meant that even experienced contributors could not get their work merged without approval from a small group of Joyent employees. The project that had been built by a global community was being run like a department inside a medium-sized company. Pull requests sat unreviewed for weeks. Discussions about the project's direction happened behind closed doors. And the people who had written significant chunks of Node's codebase had no formal say in where it was going.

In December two thousand fourteen, a developer named Fedor Indutny pressed the fork button. He called the new project io.js, a nod to the input-output operations that are the heart of what Node does. Within days, some of the most prolific Node contributors followed him. Trevor Norris. Isaac Z. Schlueter, the creator of npm. Ben Noordhuis. Bert Belder. Mikeal Rogers, the organizer of NodeConf and one of the most visible figures in the Node community. These were not disgruntled outsiders. They were the people who had been building Node.

The io.js project did something unusual with its governance. It created a Technical Committee of six to twelve people, with a rule that no more than one-third of the committee could work for the same employer. The releases were transparent. The decision-making was public. And the results were immediate. In the first few months of io.js, contributions surged back to an all-time high. Rogers saw this as vindication.

The io.js project will gain more contributions and more active contributors than Node.js. That is what happens when a project is owned by a transparent Technical Committee, rather than being owned by a single company.

He was right. The io.js release cadence was aggressive. New versions shipped regularly. V8 updates that had been stalled for months under Joyent landed within weeks. The contrast between the stagnant original and the thriving fork was impossible to ignore.

Later, after the merger, Rogers would put it more diplomatically.

The goals of Node.js and io.js have never differed. We just had different ideas about how to achieve those goals, and we have been able to reconcile those ideas into a much stronger merged project now.

The message was clear. The fork was not about the code. It was about the governance model. And now the community had proof that an open governance model produced better results, faster releases, and more contributions than corporate stewardship.

Joyent got the message. In February two thousand fifteen, just two months after io.js launched, the Node.js Foundation was announced. A neutral organization, not owned by Joyent, that would govern the project going forward. The io.js governance model, the Technical Committee, the employer diversity rule, the transparent process, became the foundation's governance model. In September two thousand fifteen, Node.js version zero point twelve and io.js version three point three merged into Node version four point zero. The fork was over. It had lasted less than a year.

The io.js fork is the happiest story on this list. The project came back together. The governance improved. Everybody won. But it is also the rarest kind of fork. A fork used as leverage, a credible threat that forced the original steward to negotiate. It worked because the forkers did not actually want to leave. They wanted to change the terms. And they had enough talent and credibility that Joyent could not afford to let them go.

Most forks do not end this way. Most of the time, when the community walks out, they do not come back.

The Fork That Won

Six months before Fedor Indutny forked Node.js, another community had already made its move. And they had done it for a reason that would echo through every fork story that followed. Oracle.

In January two thousand ten, Oracle completed its acquisition of Sun Microsystems. Sun had been the steward of many open source projects, Java, OpenSolaris, and OpenOffice.org among them. OpenOffice was a full office suite, a free alternative to Microsoft Office, and it had a passionate global community of contributors, translators, and advocates. Many of them were volunteers. Some were employed by companies like Novell, Red Hat, and SUSE. All of them had a sinking feeling when they heard the word Oracle.

The concerns were not abstract. Oracle's track record with open source acquisitions was not encouraging. Within months of the acquisition, Oracle reduced the number of paid developers working on OpenOffice. Communication with the volunteer community slowed. Decisions that had been made collaboratively were now made inside Oracle, if they were made at all. The volunteers who had spent years building translations, writing documentation, and contributing code found themselves cut off from the decision-making process that shaped the project they had helped create.

The initiative for the fork came from an unlikely place. Not Silicon Valley. Not a corporate boardroom. The French and German language communities, the volunteer translators and local user groups who had been some of OpenOffice's most passionate advocates, began planning in early two thousand ten. They were joined by independent developers and engineers from SUSE, and together they quietly built the infrastructure for a breakaway.

On September twenty-eighth, two thousand ten, they went public. A new organization called The Document Foundation, and a fork of OpenOffice.org under a new name. LibreOffice. The "libre," free, was a deliberate statement. This office suite would not be controlled by any corporation. Major companies immediately backed the new project. Novell, Red Hat, Canonical, and Google all shifted their support from OpenOffice to LibreOffice.

The founders did something interesting. They invited Oracle to participate. They asked Oracle to donate the OpenOffice.org trademark to the new foundation, to join as a member, to be part of the community rather than above it. Oracle said no.

We wanted them at the table. We asked. They chose not to come.

With Oracle refusing to participate, the fork became permanent. The LibreOffice name stuck. And then something remarkable happened. The code did not just survive. It thrived. Major Linux distributions switched from OpenOffice to LibreOffice. Governments adopted it. The translation community, dozens of languages worth of volunteers, moved almost entirely to the new project. LibreOffice was not a backup copy. It became the real thing.

Oracle, meanwhile, seemed to lose interest in the project it had refused to share. In April two thousand eleven, Oracle announced it would discontinue commercial development of OpenOffice.org. Two months later, Oracle donated the entire codebase and the OpenOffice.org trademark to the Apache Software Foundation. The donation was widely seen as Oracle dumping a project it no longer wanted, handing the remains to Apache as a face-saving gesture rather than admitting the fork had won.

Apache OpenOffice still exists. Technically. It receives infrequent updates. Its community is tiny. Meanwhile, LibreOffice is one of the most successful open source projects in the world, installed on millions of machines, backed by a foundation with real funding and governance.

The LibreOffice fork is the template for what a successful permanent fork looks like. The community took the code, took the contributors, took the users, and left the corporation holding an empty trademark. Oracle donated that trademark to Apache, where it sits like a museum exhibit. A reminder that owning the name means nothing if you have lost the people.

The Man Who Forked His Own Creation

The LibreOffice story has Oracle as the villain. But the MariaDB story has something even more dramatic. The same villain, Oracle, and a protagonist who had already sold his creation once and was watching it be taken away from him a second time.

Michael Widenius, known to everyone as Monty, is a Finnish-Swedish programmer who co-created MySQL in nineteen ninety-five. He named it after his eldest daughter, My. The database became one of the most widely used pieces of software in history, the M in the famous LAMP stack that powered the early web. In two thousand eight, Sun Microsystems bought MySQL AB, the company behind MySQL, for one billion dollars. Widenius stayed on. He was critical of Sun's development process, citing rushed releases and poor quality control, but he stayed.

Then Oracle announced it was buying Sun. And everything MySQL came with it.

Widenius had already been unhappy under Sun. He felt the releases were rushed, the quality control was slipping. But Sun was at least committed to open source. Oracle was something else entirely. Oracle sold proprietary databases for enormous licensing fees. MySQL, the free alternative that had been eating into Oracle's market share for a decade, was now owned by the company it competed against. Widenius saw the trap clearly.

The only way you can kill an open source project is if you lose the people who are developing it.

He was not going to let that happen. Widenius had an advantage that the OpenOffice community did not. He was the creator. He knew the code better than anyone alive. And he had a daughter whose name he had not used yet.

I want to ensure that the MySQL code base, under the name of MariaDB, will survive as open source, in spite of what Oracle may do.

MariaDB. Named after his youngest daughter, Maria. The symmetry is almost too perfect. My and Maria. Two daughters, two databases. One sold to a corporation, one forked to keep it free.

On December twelfth, two thousand nine, while the Oracle acquisition of Sun was still being reviewed by the European Commission, Widenius launched a campaign called Save MySQL. He asked MySQL users to petition the European Commission to block or condition the deal. The petition gathered nearly seventeen thousand signatures. Widenius submitted an initial batch of fourteen thousand one hundred and seventy-four signatures to the regulators in Brussels.

The European Commission approved the deal anyway. And Widenius, through his company Monty Program Ab, poured everything into MariaDB. The cost was staggering. One hundred thousand euros per month just to keep development going, with no guarantee the money would ever come back. He described the situation bluntly. You cannot kill an open source project by buying it. But you can kill it by losing the people who build it. Widenius was determined not to lose them.

The gamble worked, slowly and then all at once. Linux distributions, which had bundled MySQL for years, began switching. Fedora. Debian. Red Hat Enterprise Linux. CentOS. openSUSE. SUSE Linux Enterprise Server. Arch Linux. Slackware. One by one, the major distributions replaced MySQL with MariaDB as their default database. In two thousand thirteen, Wikipedia made the switch, the highest-profile endorsement MariaDB could have received.

MySQL did not die. Oracle continues to develop it. There are still plenty of MySQL installations in the world, particularly in large enterprises that have Oracle support contracts. But the open source world, the world of Linux servers and community-driven infrastructure, largely moved to MariaDB. Two databases, forked from the same code, running in parallel like alternate timelines. In one timeline, Oracle owns the name. In the other, the creator kept the soul.

As recently as September two thousand twenty-five, when Oracle laid off MySQL engineers, Widenius described himself as heartbroken. Fifteen years after the fork, he still cares about the project he sold. He just does not trust the company that bought it.

The Revolt of the Maintainers

The first three fork stories share a common shape. A corporation acquires or controls an open source project. The community fears for the project's future. The community forks. The details differ, the outcomes differ, but the trigger is the same. Corporate ownership versus community governance.

The Redis story is different. It is not about a corporation buying an open source project. It is about the company behind the project changing the rules.

On March twentieth, two thousand twenty-four, Redis CEO Rowan Trollope announced that Redis would change its license. For its entire history, Redis had been available under the BSD three-clause license, one of the most permissive open source licenses in existence. Anyone could use it, modify it, sell it, embed it, run it as a service. That permissiveness had made Redis one of the most widely deployed pieces of infrastructure software in the world. It had also made it enormously profitable for cloud providers. Amazon Web Services, Google Cloud, and Microsoft Azure all offered managed Redis services. They charged their customers for it. And Redis, the company, saw very little of that money.

Trollope's announcement changed the license to a dual model. The Redis Source Available License version two, combined with the Server Side Public License. The practical effect was that cloud providers could no longer offer Redis as a managed service without negotiating a commercial agreement with Redis. The code was still readable. You could still run it yourself. But the era of cloud providers building billion-dollar businesses on top of free Redis was over.

We need fair licensing agreements with the cloud providers. The current situation is not sustainable.

The cloud providers disagreed, and they moved faster than anyone expected, including Redis.

Within days of the announcement, engineers at Amazon Web Services, Google Cloud, and Oracle were coordinating. By March twenty-eighth, the Linux Foundation announced a new project called Valkey. The name is a portmanteau of "value" and "key," a nod to Redis's core function as a key-value data store. Valkey would be a fork of Redis seven point two point four, the last version released under the BSD license, and it would remain BSD-licensed. Open. Free. No restrictions.

But the most interesting part of the Valkey story is not the corporate maneuvering. It is the people. Madelyn Olson had worked on open source Redis for six years. Four of those years she spent as one of the core team members driving Redis development. She shipped Redis through version seven point two. And when the license changed, she found herself on the outside.

I was kind of pissed off and mad and angry when Redis decided to kick me out and change the license.

Olson described the governance problems that had been building long before the license change. Redis had two tiers of maintainers. The ones appointed by Redis, the company, had special permissions, access to internal discussions, and influence over the project's direction. External maintainers like Olson were, in her words, basically just normal members. The license change was the final break, but the fractures had been forming for years.

Olson described it as a kind of two-class system. The people who worked for Redis, the company, had access to roadmap discussions, internal Slack channels, and the ability to merge their own code. The people who contributed from outside, people like Olson who had been shipping Redis releases for years, were treated as guests in their own project.

The biggest issues emerged from governance that slowly centralized control inside Redis. Redis-appointed maintainers had special permissions. External maintainers like me were basically just normal members.

Olson joined Valkey. So did many other former Redis contributors. Within a year, Valkey had nearly fifty contributing companies and close to twenty thousand stars on GitHub. Fedora forty-one replaced Redis with Valkey in its repositories. Alpine Linux and AlmaLinux followed. AWS offered Valkey in its ElastiCache service with a twenty percent cost reduction compared to Redis.

Meanwhile, a developer named Drew DeVault created a separate fork called Redict, licensed under the LGPL, explicitly designed to operate outside of proprietary infrastructure. No GitHub. No Slack. DeVault wanted to prove that open source could function without corporate platforms at all. Redict is smaller than Valkey, but it represents a different philosophical strand in the fork wars. Valkey is the mainstream rebellion, backed by the Linux Foundation and major cloud providers. Redict is the purist rebellion, backed by ideology alone.

The Redis fork raises a question that the earlier forks did not have to ask. The Node.js, OpenOffice, and MySQL forks were about governance. Who makes the decisions? The Redis fork is about economics. Who gets paid? When open source infrastructure becomes the foundation of cloud computing, and cloud computing becomes a trillion-dollar industry, is the permissive license that made that possible still the right answer? Redis said no. The community said it was not Redis's question to answer alone.

The Midnight Transfer

The last fork on this list is the smallest. It involves no billion-dollar acquisitions, no licensing earthquakes, no EU petitions. But it may be the most relevant to this series, because it happened to a tool that exists specifically to host Git repositories.

Gitea is a lightweight, self-hosted Git forge. Think of it as a simpler alternative to GitLab, something you can run on your own server to manage repositories, issues, and pull requests without needing corporate infrastructure. It started as a fork of another project called Gogs in two thousand sixteen, which makes this story deliciously recursive. A fork that itself got forked. Gitea grew a devoted community of contributors and users who valued its simplicity and community governance. It was, by design, everything GitHub was not. Small. Independent. Owned by nobody.

In October two thousand twenty-two, the Gitea community woke up to discover that the project's domains and trademark had been transferred to a newly created for-profit company called Gitea Limited. The transfer had happened without community discussion, without a vote, without even an announcement. Contributors who had been building Gitea as a community project found out after the fact that their project now belonged to a company.

The community wrote an open letter. They asked for transparency, for a return to community governance, for assurances about the project's direction. The response confirmed their fears. Gitea Limited was here to stay. The project was now a commercial venture.

We wanted a forge built by and for the community. Instead we got a company that took our work and put its name on the door.

On December fifteenth, two thousand twenty-two, a group of contributors announced Forgejo. The name comes from Esperanto, where it means "forge." The new project would live under the umbrella of Codeberg, a German non-profit organization. No corporate owner. No surprise transfers. The domains would be held by the non-profit, and the governance would be defined collectively by the contributors.

For the first year or so, Forgejo tracked Gitea's code closely, merging upstream changes. But in early two thousand twenty-four, the project declared itself a hard fork. The codebases began to diverge. And Forgejo started building something Gitea had no interest in. Federation.

If you have been following the series, you have heard about forge federation, the idea that different Git hosting instances could talk to each other the way email servers do. You could open an issue on someone's Forgejo instance from your own Forgejo instance, without creating an account on theirs. Pull requests across servers. Notifications across servers. A network of small, independent forges instead of one giant platform.

Gitea is not working on federation. Forgejo is. That single difference tells you everything about what the fork was really about. It was not just governance. It was vision. Gitea became a company selling a product. Forgejo became a community building a protocol. And the irony is thick. A tool built to give people independence from GitHub got taken over by a company, and the community that cared about independence the most had to fork their own independence tool to keep it independent.

There is another layer to this story that makes it relevant beyond the Git world. Forgejo lives on Codeberg, not on GitHub. It uses Codeberg's infrastructure, Codeberg's issue tracker, Codeberg's code review tools. The project that forked over governance is also walking away from the dominant platform. If the other forks on this list are about who owns the code, Forgejo is about who owns the infrastructure the code lives on. It is the most radical fork here, even though it is the smallest.

Which raises a question we will sit with in the next episode. A fork is only as free as the platform that hosts it. The platforms themselves have their own rules, their own business models, their own moment when the terms might change.

What the Five Wars Tell Us

Five forks. Five dramas. And if you step back far enough, one story.

Every fork on this list started the same way. A community of people built something together, using open source licenses that guaranteed the code would remain free. Then a corporation, or a corporate interest, gained control of the project. Joyent held Node.js. Oracle acquired OpenOffice and MySQL. Redis changed its own license. Gitea's founders transferred the project to a company. In every case, the community's response was the same. They copied the code and walked away.

But the outcomes are wildly different, and the differences matter.

The io.js fork was leverage. It lasted less than a year, achieved its goal, and merged back. This only works when the forkers do not actually want to leave and when the original steward has enough to lose that they will negotiate. Joyent needed the Node.js community more than the community needed Joyent.

The LibreOffice fork was a replacement. The original project, under Oracle and then Apache, withered. The fork absorbed the community, the users, and the momentum. The original survives in name only. This happens when the corporate steward has no real commitment to the project and the community is strong enough to sustain itself independently.

The MariaDB fork created a parallel universe. Both projects survived. Both have users. But the open source world chose the fork while the enterprise world, bound by support contracts and institutional inertia, often stayed with the original. This is the most common long-term outcome when both the corporation and the community have real resources.

The Valkey fork is the newest kind. Not about governance but about economics. It asks whether the companies making billions from open source infrastructure owe anything to the projects they depend on. Redis said yes and changed the license. The community said the license was not the right mechanism and forked. This fight is far from over.

And the Forgejo fork is about vision. The smallest fork, but the one most clearly driven by an idea about what the future should look like. Not just who controls the project, but what the project should become. Federation versus product. Protocol versus platform.

The same dynamics are already playing out in a domain that did not exist when most of these forks happened. When Meta releases AI model weights publicly, the community forks them within days. Fine-tuned variants, quantized versions, merged hybrids that combine the soul of one model with the weights of another. The governance debates are the same as in the early two thousands, just running faster. Who controls the direction? What happens when the company decides to change the license, or stop releasing weights at all? The fork as a tool of dissent works the same way whether the artifact is database code or a language model. The community learned that lesson with MySQL. They are applying it now.

There is a temptation to tell these stories as morality tales. Corporation bad, community good. But the truth is messier. Redis had a legitimate grievance. Cloud providers were making enormous profits from software they did not build or fund. Trollope was not wrong when he said the situation was not sustainable. And the cloud providers' response, forking the code rather than negotiating a revenue share, arguably proved his point. They would rather fund an entire parallel project than pay for the one they were already using.

Joyent was not trying to destroy Node.js. It was trying to maintain quality control, and doing it badly. Even Oracle, the closest thing to a villain in open source history, had a legal right to do what it did with the projects it acquired. The question was never whether corporations could control open source projects. Legally, they can. The question was whether communities would let them. The fork button made the answer simple, and the answer was no.

But pressing that button has costs. Forks split communities. They divide contributors between two codebases. They confuse users who do not follow governance debates. They create parallel ecosystems that duplicate effort. Monty Widenius spent a hundred thousand euros a month keeping MariaDB alive in its early years, with no certainty it would survive. The Document Foundation had to build an entire organization from scratch. The Valkey maintainers had to convince every Linux distribution to change their package repositories. Forking is free in the sense that the code is free. Everything else is expensive.

And yet, taken together, these five stories tell you something profound about how open source actually works. The license gives you the code. The fork gives you the exit. And the exit is what keeps the stewards honest. Joyent reformed because io.js proved the community could leave. Oracle lost OpenOffice because it refused to share power. Widenius has been spending his own money for fifteen years because he believed the soul of his creation was worth more than the name Oracle bought. Redis is learning, right now, in real time, what happens when you change the deal after the code is written. And somewhere on a server run by a German non-profit, a small community is building federation into a Git forge, proving that a fork can be more than a rebellion. It can be a vision for what comes next.

I want to ensure that the MySQL code base will survive as open source, in spite of what Oracle may do.

That sentence, written by Monty Widenius in two thousand nine, could have been written by any of them. By Mikeal Rogers about Node.js. By The Document Foundation about OpenOffice. By Madelyn Olson about Redis. By the Forgejo contributors about Gitea. The words change. The fear is the same. And the response, every time, is a fork.

The fork button was designed as a collaboration tool. It became the most powerful check on corporate power in the history of software. Not because forking is easy. Because it is possible. That was episode fifteen.

To fork a repository on GitHub, you click the Fork button in the top right corner of any repository page. GitHub creates a complete copy under your account, including the full history, all branches, and all tags. You own this copy. You can rename it, change its license, take it in a completely different direction. The original repository has no control over your fork. If you want to propose changes back to the original, you open a pull request. But you are never obligated to. Your fork is yours. To fork from the command line without GitHub, you clone the repository with git clone, change the remote with git remote set-url origin followed by your new repository URL, and push. The fork is just a clone with a different destination.