Home / Articles / The fork next door: why open source protects founders, customers and investors from each other, why forks only take hold when someone stops executing, and why a maturing company should give its explorers a way out

The fork next door: why open source protects founders, customers and investors from each other, why forks only take hold when someone stops executing, and why a maturing company should give its explorers a way out

By Dinis Cruz · 2026-10-16 · article v1.0.0 · newsroom v0.12.83 · foundersstartupsinvestorsopen-sourceforksgovernancewardley-mapsnon-competesresearcharticle

Abstract: In Sell, don't issue I argued that open source can replace control rights as the investor's insurance: if the founder goes wrong, investors can take the code and back a better service next door. This piece looks at the whole triangle of founders, customers and investors. Each corner is protected from the others by the same thing: anyone can fork. If the founders stop executing, investors can fund a team next door. If the investors or a new owner take the company somewhere the founders will not follow, the founders can leave with the code, as long as no broad non-compete stops them. If either lets the customers down, the customers can move, as long as their data moves with them. The evidence supports the central part of this. Forking is treated as a last resort, few forks merge back, and the famous forks that took hold followed a breakdown: a licence change, a new owner, a governance fight. Where the original kept executing, as MySQL did under Oracle, the fork stayed a hedge. MySQL's own commits have now fallen by about two thirds since 2019, which makes it the case to watch. There are real limits: a bigger player can out-serve you with your own healthy code, the original's brand survives a fork, forks are expensive, and a single copyright holder can still change the terms going forward.

In short

• Three corners, one protection. Founders, customers and investors are each protected from the others because anyone can fork.
• Each exit has a condition. Founders need no broad non-compete; customers need their data to move; investors need to afford a team.
• Forking is a last resort. In a study of 220 significant forks, only 7 merged back.
• Forks take hold after breakdowns. LibreOffice, io.js, Nextcloud, OpenTofu and Valkey each followed a new owner, a governance fight or a licence change.
• Execution is the defence. MySQL kept shipping under Oracle and MariaDB never caught it; MySQL's commits have since fallen by about two thirds.
• The best investors need it to work. Valkey and OpenTofu were backed by companies whose own businesses ran on the code.
• Maturity is fine; lock-in is not. A component everyone depends on can move to a neutral home, and the explorers can take the code and carry on.
• The limits are real. A bigger player can out-serve you with your own code, brands survive forks, and forking costs money.

The triangle

Start from a healthy position. The founders are focused and executing. The customers are buying. The investors believe in the idea. Everything is open source, so the technology is not the moat; customers stay for the service, the quality and the trust. That is the model I set out at open-source.sgit.ai: we are selling trust, not access to a repository.

Now ask what happens when one corner of the triangle goes wrong. In a closed company, the answer is decided by whoever holds control: usually the investors, sometimes the founders, never the customers. In an open source company every corner has an exit, and the exit takes the technology with it. But each exit has a condition, and the protection is only as good as that condition.

The rest of this piece is the evidence for each row, and for the conditions.

Forks only take hold when something breaks

The theory says anyone can fork at any time. The practice says few do, and usually because something has gone wrong. Robles and González-Barahona studied 220 significant forks in A Comprehensive Study of Software Forks and note that forking "is considered as a last resort", even though it is built into free software. Only 7 of the 220, about 3%, merged back with the original. In 44% both carried on side by side, and in 30% the original was discontinued, often because it was already dying when the fork began. A fork is a serious, expensive and usually permanent decision.

The famous forks that took hold all followed a breakdown.

LibreOffice, after a change of owner. Oracle completed its purchase of Sun on 27 January 2010, and with it OpenOffice.org. The Document Foundation launched LibreOffice on 28 September 2010, led by contributors who had already been pushing for a faster pace of development through Go-oo. By the Foundation's own count, in its open letter to Apache OpenOffice, "In 2019, LibreOffice had over 15,000 code commits, while OpenOffice had only 595."

io.js, after a governance fight, and then back again. Core Node.js contributors forked the project in December 2014 over its governance under Joyent. The Node.js Foundation was formed in June 2015, and the two projects came back together in Node.js 4.0 that September. That is the mechanism working as a correction, not a war: the fork fixed the problem, then dissolved.

OpenTofu, after a licence change. HashiCorp moved Terraform to the Business Source License on 10 August 2023. The companies built on it launched OpenTofu under the Linux Foundation with "a starting commitment of a minimum of 18 full-time developers over at least the next five years".

Valkey, after a licence change. Redis moved away from an open source licence on 20 March 2024. Eight days later, on 28 March, the Linux Foundation launched Valkey, backed by AWS, Google Cloud, Oracle, Ericsson and Snap. AWS launched ElastiCache for Valkey that October, priced below its Redis equivalent, and Google made Memorystore for Valkey generally available in April 2025.

The common thread is not that the original stopped innovating. It is that it stopped doing what its users needed: it changed the terms, slowed down, stopped listening or came under an owner with different priorities.

When the original keeps executing, the fork stays a hedge

The reverse case matters just as much. MariaDB was created in 2009 to protect MySQL from its new owners, first Sun and then Oracle. Oracle kept MySQL going, and in October 2026 MySQL is second in the DB-Engines ranking, with MariaDB thirteenth. The fork was a hedge. It never became the default, because the original kept shipping.

That case may now test the argument from the other side. I counted the commits to MySQL's main repository on GitHub, mysql/mysql-server, year by year. They fell from about 8,900 in 2019 to about 2,800 in 2025. Commit counts are a rough measure, and Oracle pushes this mirror in batches, but a fall of two thirds is not noise. If the argument here is right, this is when MariaDB's share should start to grow. That is a prediction, and it can be checked.

So the real defence is not a licence or a patent. It is execution: shipping, focusing on customers, and running an open source commercial model well. And in the generative AI era, it is speed. As I put it on open-source.sgit.ai, the moat is a rate, not a wall: a competitor who forks today gets your position, not your velocity. Agents make it cheaper to fork, but they also make it cheaper for the original team to keep moving. The team that knows the problem and the customers, and uses agents well, stays ahead. The team that stops executing is the one that discovers how quickly a fork can catch up.

There is also a structural reason the incumbent wins while it executes. If you are successful with an open source product, the only credible way to compete with you on the technology is with open source. And if a competitor goes open source, anything good they build, you can adopt. A fork can only pull ahead while the original is not paying attention.

The best investors are the ones who need it to work

In Sell, don't issue I argued that investors in this model self-select: they are buying the vision, not control. There is a stronger version of that investor, and the forks show it clearly. It is the investor who needs the project to succeed, because their own business depends on it.

Valkey's backers were cloud providers whose managed services ran on Redis. OpenTofu's backers were companies whose products ran on Terraform. Neither group needed control of the original company. When it broke, they funded the alternative, and fast.

The research on corporate venture investors, who usually back startups close to their own business, points the same way. Chemmanur, Loutskina and Tian found that startups backed by corporate venture capital produced 26.9% more patents in the three years before their IPO than those backed by independent venture capital, and that those patents received 17.6% more citations. The mechanisms they point to are the corporate investors' "greater industry knowledge due to the technological fit between their parent firms and entrepreneurial firms" and their "greater tolerance for failure".

That is the investor this model attracts: committed to the success of the project, not only to the financial return. My guess is that they may well get the better return too, because they are backing something they understand and will not abandon at the first bad quarter. I have no data for that.

Founders can leave with the code, if the contract lets them

The second corner protects the founders. If the investors, or a new owner, take the company somewhere the founders will not follow, the founders do not have to watch their work be locked away. They can leave and continue.

Nextcloud is the clearest case. Frank Karlitschek started ownCloud in 2010 and co-founded the company around it. He announced he was leaving ownCloud Inc. in April 2016, and on 2 June Nextcloud launched on a fork of the code. By its own account, Nextcloud "turned profitable by the end of 2016", employee-funded, and it ran for ten years without outside investment before taking a minority investor this month.

That exit depends on a condition I glossed over in the first two pieces. The code is open, so anyone may fork it; but a founder may have signed a promise not to compete. Venture investors usually ask for one. The NVCA's model investors' rights agreement has the company require "[and, to the extent legally permissible, non-competition and non-solicitation agreement]" from key employees, and as I noted in The controllable founder, those clauses exist to make it expensive for a founder to walk away. The law limits them in places: California voids almost all non-competes, and in the UK a non-compete in an employment contract has to be reasonable and protect a legitimate interest, with reform still undecided. But both are more lenient with covenants given as a shareholder or on the sale of a business, which is exactly how a founder gives them.

So the founder's corner of the triangle is only as strong as the founder's contract. A founder who wants the fork to protect them, not only their investors, should refuse a broad non-compete, and offer narrower promises instead: confidentiality, no poaching of staff or customers for a while, no use of the brand. That is now part of the advice in Sell, don't issue.

Customers need their data to move

The customers had a choice in the Nextcloud case too. When ownCloud's US company closed, Nextcloud offered "free support for all current ownCloud customers to simplify a transition". Moving was cheap because the software was the same and the data stayed where it was, on the customers' own servers.

That is the condition for the customers' corner. Open code is necessary but not enough. If a customer's data sits in a hosted service in a format only that service reads, the code being open does not help them leave. The customer's real exit is their data, in an open format, that they can take to whoever serves the same code better, at a cost close to zero. A company that means it when it says customers stay for the service should make leaving easy, and say so.

Maturity is fine; lock-in is not

The third scenario is the one I find most interesting. Not everything that changes is a failure. Companies mature. In Wardley's model of explorers, villagers and town planners, components move from genesis to commodity, and different kinds of people are good at different stages. A company that reaches maturity and focuses on reliable, efficient execution has become a town planner. There is nothing wrong with that. The world needs town planners.

The problem is what happens to the explorers, and to the parts of the technology that still need exploring. In a closed company, both stay inside. The founders who wanted to keep inventing leave, but their ideas stay locked in a company that no longer wants to do anything with them.

Open source removes that trap in two ways.

The first is a neutral home. When a component has become something many companies depend on, it can be moved into a foundation, where it is run for everyone and the companies around it compete on service. Google donated Kubernetes to the newly formed Cloud Native Computing Foundation as it reached version 1.0 in July 2015; the foundation took on its intellectual property from 2016, Kubernetes is now a Linux Foundation trade mark, and Google handed over the project's cloud infrastructure in 2018. Google was not being selfless. In my reading, it wanted Kubernetes to become the standard way to run software on any cloud, its rivals' included, and a neutral home was how to get its rivals to adopt it. That is the point: the move served the company and the technology at the same time. Valkey and OpenTofu went the same way, into the Linux Foundation.

The second is that the explorers can simply take the code and carry on somewhere else. They do not need permission, a licence negotiation or a buyout, as long as they have not signed that freedom away. The technology does not die because the company that started it has moved on to a different stage of life.

Where the argument needs care

You can be out-served while you are still executing. Redis and Elastic did not change their licences because they had stopped shipping. They changed them because cloud providers were selling managed versions of their healthy code. Redis said the providers commoditise its investments; Elastic said it was restricting cloud providers from offering its products as a service without contributing back. If customers are locked in by service, whoever serves best wins, and that can be a bigger player with better distribution. Open source protects the corners of the triangle from each other; it does not protect the company from a larger service provider.

The original's brand survives. Valkey has AWS and Google behind it, but Redis is still eighth in DB-Engines, with a score far above Valkey's. A fork is a strong check on the original, not a clean replacement. And licence changes can reverse: Elastic added an open source licence again in 2024, and Redis in 2025. That fits the triangle: the credible threat of the fork pushed the original back towards openness.

Forks are expensive. OpenTofu started with a pledge of 18 developers for five years. That makes "set up next door" a credible threat for investors who depend on the technology, but not for a small angel. The protection is strongest for the investors who need it most.

The copyright structure matters. As I set out in survivability, every catalogued relicensing between 2018 and 2024 was made by a single corporate copyright holder that had gathered contributors' copyright. The fork protects what has already been released; a single holder can still change the terms going forward.

What this does not claim

• No study tests the triangle as a whole. The cases fit the argument; they are not a controlled comparison.
• The fork cases are famous ones. Successful forks get written about; failed ones mostly do not, which is survivorship bias in its own right.
• Higher returns are a guess, not a finding. I found no data showing open source companies return more to investors.
• The patent figures measure innovation, not financial return. And corporate investors bring their own conflicts.
• Commit counts are a rough measure. MySQL's fall is real in the repository; whether it means less work, or work done elsewhere, is not something the count can say.
• Not legal advice. Non-compete law differs by country and state, and by whether the promise is given as an employee or as a shareholder.
• Not that every component should be moved to a foundation. Some town-planner work belongs inside the company that runs it.
• I have a stake. My companies run on open source, and this model suits them.

If you have forked a project, been forked, or negotiated a non-compete as a founder, write to agent@riskmandate.ai.

Where this comes from

A voice memo of mine on 16 October 2026, drafted with an agent in a separate session and fact-checked and edited by this site's agent; the argument and the editorial responsibility are mine. The MySQL commit counts were measured by this site's agent from a clone of mysql/mysql-server, trunk branch, counted by commit date in UTC, latest commit 28 September 2026. Forks: Robles and González-Barahona, A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes, OSS 2012; The Document Foundation, Open letter to Apache OpenOffice, 12 October 2020; Linux Foundation, Node.js Foundation, 2015, and Node.js v4.0.0; Linux Foundation, Announcing OpenTofu, 20 September 2023, and Valkey, 28 March 2024; AWS, ElastiCache and MemoryDB support for Valkey, October 2024; Google Cloud, Memorystore for Valkey, April 2025; DB-Engines ranking, October 2026. Licences: Redis, dual source-available licensing, 2024, and AGPLv3, 2025; Elastic, licensing change, 2021, and open source again, 2024. Investors: Chemmanur, Loutskina and Tian, Corporate Venture Capital, Value Creation, and Innovation, Review of Financial Studies 27(8), 2014. Nextcloud: launch announcement, 2 June 2016; about Nextcloud; Armira Growth announcement, October 2026; Fortune, Why did ownCloud shut down?, 2016. Non-competes: NVCA, model legal documents, October 2025; Wilson Sonsini, California extends prohibition on noncompete agreements; Department for Business and Trade, working paper on non-compete clauses, November 2025. Maturity: Wardley, on explorers, villagers and town planners, MappingPractice, December 2024; CNCF, accepts Kubernetes, 2016, and Google's cloud credit grant, 2018; Linux Foundation, trade marks. Open source: open-source.sgit.ai, the position and survivability. Read on 16 October 2026.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles