Andreas Kling posted yesterday about a pattern everyone in open source recognizes but nobody names politely:

He's right about the pattern. But the full picture is more interesting than "angry forks fail." Some do fail. Some succeed spectacularly. And the difference between the two has almost nothing to do with how justified the anger was.

I went through every notable open source fork I could find. Here's the scorecard:

The stories behind the numbers are where it gets interesting.

The ones that died

Ayo.js (forked from Node.js, 2017) — Four Node.js TSC members resigned over a failed vote to remove a controversial committee member. They forked Node as "Ayo" (Yoruba for "joy"), framing it as a governance reset. The underlying dispute in Node.js was resolved through normal processes within weeks. Ayo's GitHub repo was archived a year later with no meaningful development. The name was a callback to io.js — which had actually succeeded — but the circumstances were completely different.

Glimpse (forked from GIMP, 2019) — A group forked GIMP because they considered the name offensive and a barrier to workplace adoption. The announcement generated enormous attention. Then the project discovered that rebranding a massive codebase is grinding, thankless work with no technical payoff. Contributors dwindled. By 2021, Glimpse was officially abandoned. GIMP never changed its name.

Plan Vert (proposed fork of Rails, 2025) — An open letter called for a hard fork of Ruby on Rails to remove DHH's influence, citing blog posts the signatories described as expressing racist and transphobic views. ~300 signatures. The GitHub repo's last commit was September 2025. No fork was ever created. The entire Rails core team was selected by DHH, which made the "we'll just fork it" plan structurally impossible without replacing every maintainer simultaneously.

Drizzle (forked from MySQL 6.0, 2008) — A vision for "smaller, slimmer, faster MySQL," forked by Brian Aker from a defunct development branch. Despite backing from Google, Sun, Rackspace, Intel, Percona, HP, and Red Hat, the project was eventually discontinued. Never gained meaningful adoption. Having a patron list is not the same as having contributors.

Navy Linux (forked from CentOS, 2021) — When Red Hat killed CentOS as a stable RHEL clone, several forks appeared. Rocky Linux and AlmaLinux survived. Navy Linux shipped a couple of releases, then went dormant. Maintaining an enterprise Linux distribution turns out to be a lot of work.

Pale Moon (forked from Firefox, 2009) — Forked to preserve Firefox's pre-Australis UI and XUL extension support. The lead developer was emphatic about rejecting Mozilla's direction. Pale Moon achieved a small following, then fell increasingly behind on security patches. The codebase diverged so far from Firefox that backporting fixes became impractical. In 2023, a disgruntled contributor reportedly compromised the archive server. The browser still exists but is widely considered a security risk. A cautionary tale about forking something with the maintenance burden of a web browser.

The ones that survived

The successful forks don't look like the failures at all. They share a structure that the dead ones lack.

LibreOffice (forked from OpenOffice.org, 2010) — Oracle acquired Sun Microsystems and treated the OpenOffice community with hostility. The actual developers left and created LibreOffice under the Document Foundation. Within a year, every major Linux distribution switched. Oracle gave up and donated OpenOffice to Apache, where it still technically exists but receives negligible development. The community didn't just declare a fork — they moved.

Jenkins (forked from Hudson, 2011) — Oracle again. A trademark dispute over the Hudson name led the developer community to fork as Jenkins. Nearly every contributor and plugin developer followed. Oracle continued Hudson briefly, then donated it to Eclipse, where it died. The fork succeeded because the people who built the thing walked out together.

Nextcloud (forked from ownCloud, 2016) — Frank Karlitschek, the original creator of ownCloud, resigned from his own company over disagreements about the business model's relationship to the community. He forked within two weeks and took most of the core developers with him. Within 12 hours of the Nextcloud announcement, ownCloud's US offices shut down due to investor withdrawal. The ownCloud US entity collapsed almost immediately; the German company limped on until it was acquired in 2023. The creator leaving and taking the talent was decisive.

Prism Launcher (forked from PolyMC, 2022) — PolyMC was itself a fork of MultiMC (a Minecraft launcher), created over redistribution disagreements. Then in October 2022, PolyMC's lead maintainer removed all other contributors, deleted the Code of Conduct with a commit message titled "reclaim polymc from the leftoids," and claimed contributors were promoting ideology. The entire remaining contributor base forked as Prism Launcher within 48 hours. PolyMC was immediately dead. Prism Launcher now has more contributors and users than PolyMC ever did.

io.js (forked from Node.js, 2014) — Frustration with Joyent's corporate control and slow governance. The fork achieved record contributor numbers and faster release cycles. But here's the thing: io.js succeeded by making itself unnecessary. It forced the creation of the Node.js Foundation with open governance, then merged back into Node.js v4.0. The goal was never to replace Node — it was to fix the governance. It worked.

Forgejo (forked from Gitea, 2022) — Gitea's domains and trademarks were transferred to a for-profit company without community knowledge. An open letter asking for community control was rejected. Forgejo was created as a community-governed alternative. Codeberg, with 300,000+ repos, migrated to Forgejo. It became a hard fork in 2024, adding features impossible under Gitea's architecture. The fork chain here is notable: Gogs → Gitea → Forgejo, each fork triggered by the same governance failure pattern repeating itself.

X.org (forked from XFree86, 2004) — XFree86 added a BSD-style credit clause to its license, making it GPL-incompatible. Every major Linux distribution and OpenBSD switched to X.org. XFree86's last code commit was 2009. A licensing decision killed the project and handed victory to the fork.

The license-change forks

Starting around 2021, a new pattern emerged: companies switching established open source projects from permissive licenses to restrictive ones (BSL, SSPL), followed by rapid community forks under the Linux Foundation or CNCF. These forks succeed at a much higher rate than personality-driven ones.

Valkey (forked from Redis, 2024) — Redis Labs switched Redis from BSD to dual SSPL/RSAL. The Linux Foundation announced Valkey within days, backed by AWS, Google, Oracle, and Snap. AWS migrated ElastiCache. Madelyn Olson, a top Redis contributor who had been denied maintainer access by Redis Labs, became a Valkey lead. By early 2025, Valkey reported 37% higher throughput than Redis. The talent drain was symbolized by a single person, but the corporate alignment made the fork unstoppable.

OpenTofu (forked from Terraform, 2023) — HashiCorp switched Terraform from MPL to BSL. A manifesto signed by dozens of companies. The Linux Foundation adopted the fork as OpenTofu. Tripled contributors to 160+. Joined CNCF. Added features like state encryption that HashiCorp hadn't prioritized. IBM's subsequent acquisition of HashiCorp added further uncertainty about Terraform's direction.

OpenSearch (forked from Elasticsearch, 2021) — Elastic switched from Apache 2.0 to SSPL. AWS forked as OpenSearch. The fork was so successful that in 2024, Elastic reversed course and re-released Elasticsearch under AGPLv3. OpenSearch is now under the Linux Foundation as a vendor-neutral project. A fork that forced the original to change its license back.

OpenBao (forked from HashiCorp Vault, 2023) — Same BSL switch as Terraform. 100+ contributors. Released v2.0 in 2025. GitLab is integrating OpenBao. Already includes features that were Vault Enterprise-only.

What separates survival from death

Forks that survive have the developers. Not supporters, not signatories, not users filing issues — the people who actually write the code. When the LibreOffice developers left OpenOffice, the project was over regardless of what Oracle did. When Prism Launcher's contributors left PolyMC, the fork was alive before the GitHub repo was even set up.

Forks that die have the grievance. A legitimate grievance, often. But no sustained development talent willing to do the unglamorous work of maintaining a project for years. Ayo.js had resigned TSC members. Glimpse had people who genuinely found the name GIMP harmful. In most of these cases, the anger was real but the sustained development wasn't there.

The license-change forks are different because they have something neither personality forks nor grievance forks have: corporate sponsors who need the permissively-licensed version to exist for their own business reasons. AWS needs Valkey because AWS runs a Redis-compatible service. That alignment between corporate self-interest and community governance is what funds full-time maintainers, which is what keeps a fork alive past the initial excitement.

There's also a subtler pattern. The forks that succeed tend to frame themselves as continuations, not rebellions. LibreOffice positioned itself as "the community continues." Jenkins was "same project, new name." Valkey was "the open source Redis." The ones that frame themselves as righteous alternatives to a corrupt original — the "we will continue in the right direction" framing that Kling is mocking — tend to be the ones that die. The framing reveals the motivation. Continuations are motivated by wanting to build. Rebellions are motivated by wanting to punish.

LibreSSL is the interesting exception. It was explicitly a rebellion — OpenBSD developers deleted 90,000 lines of OpenSSL code in the first week and were loudly contemptuous of the original codebase. But they had the development talent to back it up, and they succeeded in a way nobody expected: not by replacing OpenSSL, but by shaming it into improving. LibreSSL forced OpenSSL to restructure, get proper funding, and fix its code quality. The fork won by making itself less necessary.

The one Kling didn't mention

There's one fork pattern that doesn't fit either category: the "rewrite it in Rust" fork.

Frank Hale replied to Kling's post: "The 'Butthurt Fork' is almost always a 'Rewrite it in Rust' fork." This is mostly meme — most RIIR efforts are clean-room reimplementations rather than forks of existing codebases. But the energy is the same. Someone looks at a C or Python project, declares it irredeemably flawed, starts a Rust rewrite, gets 30% of the way through the easy parts, hits the gnarly edge cases that the original spent a decade handling, and quietly abandons the repo.

The successful Rust replacements (ripgrep, fd, bat, eza) aren't forks at all. They're new projects that happen to solve the same problem better. That's the difference between building something and reacting to something.

Commits or logos

Most angry forks die. But it's worth being precise about why. It's not that the anger is wrong. The PolyMC maintainer really did delete his entire contributor team. Redis Labs really did rug-pull the license. Oracle really was hostile to the OpenOffice community. The anger was justified in every case.

The difference is what happens after the anger. If the fork exists to channel anger into a logo and a manifesto, it dies. If the fork exists because the people who do the work need somewhere to do it, it lives.

Check back in a month. If they have commits, they have a chance. If they have a logo, they have a logo.