Open Source Research

What open source actually means — and the business model it kills

  • definition
  • business-model
  • collaboration
  • sustainability

There is a lot written about what open source means. The Open Source Definition lists 10 criteria. The FSF has its own four freedoms. They agree on roughly 95% of cases but disagree about why it matters — the OSI frames open source as a superior development methodology, the FSF frames it as an ethical imperative. Edge cases exist. A licence can be approved by one and rejected by the other. Then there are the grey areas — "source-available" licences like the Business Source License or Server Side Public License that give you the code but restrict what you can do with it. Companies market these as open source. They are not. I will probably write more about this.

But the summary is simple. Open source software must grant three freedoms to anyone who receives it: access to the source code, the right to modify it, and the right to redistribute it.

The business model this kills {#killed-business-model}

See also: The Killed Business Model — the full consequences, including why the services pivot leads to a race to the bottom.

Criterion 1 of the Open Source Definition is Free Redistribution. Anyone who gets the software can give it away or sell it. No royalties. No restrictions.

Criteria 5 and 6 close the workarounds. No discrimination against persons or groups. No discrimination against fields of endeavour. You cannot say "free for personal use, paid for commercial." The definition explicitly prevents that escape route.

Together, these kill the basic business model of selling software. If anyone who buys your product can legally redistribute it for free, you have no monopoly on your own work. Someone will always undercut you. And the equilibrium price of a digital good with zero marginal cost and no artificial scarcity? Zero.

You can sell copies — nothing prohibits it. Red Hat sold RHEL subscriptions for years. But you have no exclusive right to do so. CentOS took the same code and gave it away for free. That is exactly what the licence permits.

What replaces the profit motive

If you cannot sell the software, most contributors must have other reasons to contribute.

They do. Some do it for the craft. Some scratch their own itch — they need the tool, so they build it. Some do it for reputation — open source contributions are a public portfolio that no résumé can match. And increasingly, most do it because their employer pays them to. The Linux kernel's largest contributors are Intel, Google, Red Hat, Huawei, and Meta. Not volunteers. Engineers on salary, contributing because their employer depends on the project.

Whatever the motivation, it is rarely "I want to sell this software to customers."

That changes everything about how people work together.

Collaboration without customer competition

When nobody in a project is competing for customers, something unusual happens. No incentive to hoard features. No reason to withhold improvements or sabotage other contributors. Every improvement benefits everyone.

Companies that are fierce commercial rivals — Google and Microsoft, Intel and AMD — contribute to the same Linux kernel. It helps all of them. None can capture exclusive benefit. The scale of collaboration this produces, in projects like Linux, Kubernetes, or Apache, is unlike anything in proprietary software.

But it is not as clean as the idealists claim.

Companies compete intensely for governance influence even when they collaborate on code. Strategic open-sourcing is sometimes a weapon — Google open-sourced Android not as a gift to humanity, but to undermine Nokia and Microsoft's mobile platforms. Free-rider problems are real. Amazon consumed Elasticsearch without proportional contribution until Elastic got frustrated enough to change their licence. Maintainer burnout exists regardless of how collaborative the culture is.

The absence of customer competition lowers one barrier to collaboration. It does not eliminate conflict.

The race to the bottom

If the primary business model is dead, the obvious pivot is services — support, consulting, maintenance, hosting. Companies pay for these. Red Hat built a billion-dollar business on them.

But services around open source are structurally different from services around proprietary software. When the code is public, anyone can learn it. Anyone can offer competing services. A consultancy in a lower-cost market can read the same source, build the same expertise, and undercut your prices. You have no exclusive right to your own expertise, because the thing your expertise is built on is public.

The result is commodity economics. Multiple suppliers, low switching costs, price competition, temporary differentiation. The race to the bottom is not a risk — it is the default trajectory.

Companies know this. Every serious open source business model is an attempt to reintroduce artificial scarcity into a system designed to eliminate it — through trademarks, restrictive licences, open core models, certification ecosystems, strategic weaponisation, or dependency economics. Red Hat isn't an exception to the race. It's the most sophisticated example of fighting it.

The full catalogue of these defences — and why most of them work by keeping something not open — is in The Killed Business Model.

The sustainability question {#sustainability-question}

Individual open source projects are, for the most part, not sustainable on their own. The xz utils backdoor in 2024 showed what happens when critical infrastructure depends on a single overworked maintainer who can be socially engineered. Nadia Eghbal's work documented how digital infrastructure is chronically underfunded relative to its importance.

The usual counterargument is Linux — but the Linux phenomenon required conditions so specific (procurement bypass, GPL copyleft, scope that prevents forking, a singular governance model) that it tells you very little about whether your project can be sustainable.

And yet people keep trying. New projects launch every day. Contributors show up. Code gets written.

Why that happens — and whether it can continue — is what I want to explore in this project.

Topics I plan to cover next: