Open source survives because it can fork

An aggressively pruned tree: the big limbs were cut back, and it answered with hundreds of small shoots — each one a fork — that keep it alive. Pruning is natural, sometimes even necessary; surviving it is only possible because the thing can re-fork. The owner can cut; the fork is what lives. Image: Acabashi, CC BY 4.0.

Open-source projects do not die the way companies die. A company dies when it runs out of money; an open-source project dies when it runs out of people willing to carry it — and the thing that decides whether someone can carry it, once the original owner loses interest or turns hostile, is one property: the right to fork. Strip everything else away and that is what keeps open source alive. A project survives not because its sponsor stays benevolent, but because if the sponsor stops — or sells, or relicenses — someone else can pick up the code and keep going. The fork is the community's veto, and it is the load-bearing beam under every other thing people credit for survival.

Survival means the code, not the company

MySQL the company no longer exists. MySQL AB was bought by Sun for a billion dollars in 2008; Sun was swallowed by Oracle for $7.4 billion in 2010. By the usual logic of acquisitions that should have ended MySQL as a community project — its new owner sold a competing database and had every reason to let it drift. Instead Monty Widenius, one of the original authors, forked it into MariaDB in 2009, before the Oracle deal even closed, precisely so a free, community-owned version would exist no matter what Oracle decided to do. Both are still here. That is what "survival" means in open source: not the company — the code and the people — and the fork is how the code outlives whoever owned it. Draw it and the shape is almost comical:

flowchart TD
    AB["MySQL AB"] --> SUN["Sun Microsystems"]
    SUN --> ORACLE["Oracle"]
    AB --> MARIADB["MariaDB"]
    ORACLE --> MYSQL["MySQL"]
    MARIADB --> LIVE["Both still maintained"]
    MYSQL --> LIVE

    classDef plain stroke:#7b88a1,stroke-width:2.5px
    classDef key stroke:#a3be8c,stroke-width:2.5px
    class MARIADB key
    class AB,SUN,ORACLE,MYSQL,LIVE plain

The company changed hands twice (MySQL AB → Sun → Oracle); the code forked once (MariaDB) and never had to ask permission. Both branches are alive today.

The right to fork is the design, not a loophole

It is worth being precise about where that right comes from, because it is not an accident. Free software was defined, decades ago, by four freedoms: the freedom to run the program for any purpose, to study and modify its source, to redistribute copies, and to redistribute your modified copies. The last two — share it, and share your changed version — are the right to fork, written straight into the definition. A license that genuinely qualifies as open source guarantees forkability by construction. You cannot grant the four freedoms and withhold the fork; they are the same thing.

flowchart TD
    LIC["Open-source license"] --> F0["Freedom 0: run"]
    LIC --> F1["Freedom 1: study + modify"]
    LIC --> F2["Freedom 2: redistribute"]
    LIC --> F3["Freedom 3: redistribute modified"]
    F1 --> FORK["The right to fork"]
    F3 --> FORK

    classDef plain stroke:#7b88a1,stroke-width:2.5px
    classDef key stroke:#a3be8c,stroke-width:2.5px
    class FORK key
    class LIC,F0,F1,F2,F3 plain

Freedoms 1 and 3 — modify, and share what you modified — combine into the right to fork. It is written into the definition, not bolted on.

The names around this are a thicket worth clearing. Free software is the Free Software Foundation's term — freedom-first and ethical, the source of those four freedoms, where "free" means libre (free as in freedom), not gratis (free as in price). Open source (OSS) is the Open Source Initiative's term for largely the same licenses with a pragmatic, business-friendly emphasis on the development model rather than the ethics. FOSS (free and open-source software) and FLOSS (free/libre and open-source software) are the umbrella terms that span both camps — the "libre" in FLOSS exists specifically to kill the free-as-in-beer confusion. The two camps differ on philosophy, not much on which licenses qualify; and both draw the line in the same place — a source-available license that revokes the freedoms is neither.

Which is exactly what the source-available relicenses try to do. SSPL and BSL keep the source visible but restrict how you may use and redistribute it — they revoke the freedoms that make a fork legal. That is why neither the Free Software Foundation nor the Open Source Initiative counts them as open source, and why the forks that follow are not theft but preservation: the community reclaiming the freedoms the relicense tried to take back. A fork is the four freedoms refusing to be revoked.

The ways projects actually die

It helps to know what kills projects in the first place. The research is unromantic: studies of failed open-source projects find the top causes are being usurped by a competitor, becoming functionally obsolete on outdated technology, and — over and over — the main contributor running out of time or interest. Two of the three are about people, not code. A project with one maintainer is one bad year away from death. Which is exactly the part nobody wants to pay for.

The funding problem (the part everyone forgets)

Open source's founding myth is that it runs on volunteer passion. It does — right up until the passion is load-bearing for the entire internet. In 2014, Heartbleed, a catastrophic bug in OpenSSL — the library securing roughly two-thirds of the web's servers — traced back to a project living on about $2,000 a year in donations and a tiny knot of mostly-volunteer maintainers. Ten years later, the xz Utils backdoor told the same story from the other side: a critical compression library maintained by one burnt-out volunteer, socially engineered into handing commit access to an attacker who had spent two years building trust.

Nadia Eghbal's Working in Public put the pattern in numbers — a handful of unpaid maintainers carry the dependencies sitting under most of modern software. Heartbleed at least produced a response: the Core Infrastructure Initiative, where the big vendors pooled money to actually fund maintainers. The lesson is blunt. A project with funded maintainers, and more than one of them, survives. A project resting on one unpaid person is a countdown — no matter how good the code is.

Governance that outlives the founder

Even funded, a project dies if one party can capture it. The durable ones put governance somewhere no single company controls. PostgreSQL has run for thirty years on a community model with no owning vendor — which is exactly why it has never been relicensed, never been acquired, and quietly became the default database of the 2020s. The counter-example: Node.js spent its early years under Joyent, the company that employed its lead, and in 2014 a group of core contributors forked it into io.js over precisely that — they wanted a technical committee, not a corporate parent. The split only healed when Node moved to an independent foundation.

The pattern across Linux, Kubernetes, and the rest is the same: the projects that survive leadership changes are the ones where leadership was never one person's or one company's to lose. A benevolent dictator is a single point of failure with good PR.

The modern killer: the license rug-pull

The newest way to kill a project is to stop it being open source at all — and it has become a genre with a script. A company open-sources its product under a permissive license; it gets popular; a cloud provider starts selling it as a managed service and captures much of the revenue; the company responds by relicensing to a "source-available" license — SSPL, BSL — that the Open Source Initiative does not recognize as open source. MongoDB did it in 2018, Elastic in 2021, HashiCorp with Terraform in 2023, Redis in 2024. Every time, the relicense rescues the company's revenue and forfeits the community's trust. And every time, the community forks.

flowchart TD
    OSS["Permissive open source"] --> ADOPT["Mass adoption"]
    ADOPT --> CLOUD["Cloud sells it as a managed service"]
    CLOUD --> RELICENSE["Vendor relicenses to source-available"]
    RELICENSE --> FORK["Community forks under a foundation"]
    FORK --> COMMUNITY["Fork inherits the community"]

    classDef plain stroke:#7b88a1,stroke-width:2.5px
    classDef key stroke:#a3be8c,stroke-width:2.5px
    class FORK key
    class OSS,ADOPT,CLOUD,RELICENSE,COMMUNITY plain

The relicensing script, 2018–2024. The relicense is rational for the company and fatal to the project as a commons — so the fork is the turn that keeps the project alive.

The tell is that the relicense often gets reversed, too late to matter. Elastic went back to an open license (AGPL) in 2024; Redis added AGPL back in 2025 after its original author rejoined the company. By then the forks had the momentum. AWS, Google, Oracle, and others stood up Valkey under the Linux Foundation within days of Redis's relicense, and the major Linux distributions now ship Valkey by default. The company kept its product; the ecosystem kept the project, under a new name.

The fork is the backstop

Line up the history and the thesis writes itself.

Every row is the same move: an owner — through acquisition, ego, or economics — tries to close a door, and the community walks through a fork instead. The fork is not a failure state; it is the mechanism. It is what makes every other survival factor enforceable. Funding, neutral governance, an open license — a sponsor can promise all three and renege on all three, and the only reason those promises mean anything is that if they break them, the code leaves with the people. The mere threat of a fork disciplines sponsors who never actually get forked. Open source is the only software model where the users can fire the owner.

If you are building or betting on one

So if you are choosing what to build on, the durable bets are the forkable ones: a real open-source license, governance that no single vendor controls, and more than one company paying maintainers. A single-vendor "open source" product on a source-available license is a rental with extra steps — sometimes worth it, but price in the rug-pull.

And if you are building one, the survival moves are the unglamorous ones: solve a real problem, fund the maintainers, put the project somewhere neutral, and pick a license you will not need to betray later. The same property shows up one level up, too — the table-format war went to Iceberg, and the streaming-storage fight will resolve the same way, because the least-owned option is the one nobody is afraid to adopt. Least-owned wins, and least-owned survives. It is one property seen from two angles.

Stacked up, the whole argument is one picture:

flowchart TD
    PROJECT["Open-source project"] --> PROBLEM["Solves a real problem"]
    PROJECT --> FUNDING["Funded maintainers"]
    PROJECT --> GOV["Neutral governance"]
    PROJECT --> LICENSE["Open license"]
    PROBLEM --> SURVIVE["Survives"]
    FUNDING --> SURVIVE
    GOV --> SURVIVE
    LICENSE --> SURVIVE
    FORK["Right to fork"] -. enforces .-> SURVIVE

    classDef plain stroke:#7b88a1,stroke-width:2.5px
    classDef key stroke:#a3be8c,stroke-width:2.5px
    class FORK key
    class PROJECT,PROBLEM,FUNDING,GOV,LICENSE,SURVIVE plain

Four forces keep a project alive — but each is only a promise a sponsor can break. The right to fork is what makes them enforceable: renege on any one, and the code leaves with the people.

A short close

The paradox at the center of all this is that you keep an open-source project alive by giving up the power to kill it. The license that lets anyone fork you is the same license that means you can never be the single point of failure. The projects that try to make themselves unforkable — a captive license, a controlled foundation, a one-company committee — are the ones that, sooner or later, get forked. Open source does not survive in spite of being impossible to own. It survives because of it.