The Killed Business Model

2026-04-07

The primary model is dead

The first log entry establishes the basic problem: the Open Source Definition deliberately kills the business model of selling software. Free redistribution, no discrimination against persons or fields of endeavour — together, these guarantee that anyone who gets the software can give it away. The equilibrium price of a digital good with zero marginal cost and no artificial scarcity is zero.

This is well understood. What's less discussed is what happens next.

The obvious pivot: sell services

If you can't sell the software, sell what surrounds it. This is the standard advice, and it comes in several flavours:

Support — pay us to help you when things break
Consulting — pay us to configure, integrate, and customise
Maintenance — pay us to keep it running in your environment
Development — pay us to build the features you need
Hosting — pay us to run it so you don't have to

Each of these is real. Companies do pay for them. Red Hat built a billion-dollar business on support subscriptions. Canonical sells Ubuntu Pro. Countless consultancies make a living on WordPress, Drupal, Kubernetes, and the rest.

So the model works — right?

The structural problem: no moat

Here's what the services pivot misses. When you sell proprietary software, you have a structural advantage: you control the code. Only you can fix it, extend it, or explain its internals with full authority. Your knowledge is exclusive. Your position is defensible.

When you sell services around open source, that structural advantage disappears. The code is public. Anyone can read it, understand it, modify it, and offer services around it. Your knowledge is not exclusive. Your position is not defensible.

This changes the economics completely.

The race to the bottom

Suppose you build an open source project and find a successful niche. Companies adopt it. They're willing to pay for support, development, and maintenance. You've done everything right. You have expertise, reputation, and paying customers.

The problem: everyone can offer similar services.

The code is open. Anyone can learn it. A consultancy in a lower-cost market can read the same source, build the same expertise, and undercut your prices. A freelancer who contributed a few patches can credibly claim deep knowledge. A cloud provider can wrap it in a managed service and bundle it with their platform at a price you can't match.

You have no exclusive right to your own expertise, because the thing your expertise is built on is public.

The result is classic commodity economics:

Multiple suppliers — anyone with the skills can enter the market
Low switching costs — the customer isn't locked into your service because the underlying software is open
Price competition — with multiple substitutable suppliers, margins get competed down
Differentiation is temporary — any advantage you develop (documentation, tooling, integrations) can be copied, because you can't prevent others from building on the same open codebase

This is a race to the bottom. Not immediately — early movers have a window where expertise is scarce and demand is growing. But as the project matures and knowledge diffuses, the service market commoditises.

Why reputation doesn't save you

The common counterargument: "But we wrote the software. We know it better than anyone. Customers will always prefer the original authors."

This is true early on. It becomes less true over time, for three reasons:

Knowledge diffuses. The longer a project exists, the more people understand it deeply. The original authors' advantage erodes with every new contributor, every blog post, every Stack Overflow answer.
Customers buy outcomes, not pedigree. A company that needs Kubernetes support cares whether their cluster stays running, not whether the support engineer was on the original Google team. If a cheaper provider delivers the same outcome, they'll switch.
Scale advantages favour platforms, not projects. AWS, Azure, and GCP can offer managed open source services at margins that individual maintainers can't match, because the service cost is amortised across millions of customers. The original authors can't compete on unit economics with a hyperscaler.

How companies fight the race to the bottom

The race is the default. But companies don't accept defaults — they build defences. Every serious open source business model is, at its core, an attempt to reintroduce artificial scarcity into a system designed to eliminate it.

Here's the catalogue.

Open washing

Use a licence that looks open but isn't. MongoDB's Server Side Public License (SSPL), Elastic's Elastic License, HashiCorp's Business Source License (BSL) — all give you the source code, all restrict what you can do with it. The BSL explicitly prohibits competing with the vendor's hosted service. The SSPL requires anyone offering the software as a service to open-source their entire stack — a condition so onerous it functions as a commercial use ban.

These are marketed as "open source" or "source-available." They are neither. They are proprietary licences with readable source code. The Open Source Initiative does not recognise any of them. But the branding works: many users don't read licences, and "source-available" sounds close enough to "open source" to capture most of the goodwill.

Restrictive copyleft

Use a licence that is genuinely open source but scares away business use. The GNU Affero General Public License (AGPL) requires that anyone who modifies the software and offers it as a network service must release their modifications under the same licence. This is a legitimate open source licence — the OSI approves it. But many corporate legal departments treat it as radioactive. Google bans AGPL software internally. Most enterprises won't touch it.

This creates a two-tier market. Individual developers, academics, and startups use the AGPL version for free. Enterprises who won't accept the copyleft terms pay for a commercial licence. MongoDB used this model before switching to the SSPL. Qt still does. MySQL (under Oracle) offers GPL for the community and a commercial licence for companies that don't want copyleft obligations.

The dual-licensing variant makes the strategy explicit: same code, two licences. One free with strings attached, one paid without. The "open" version is real, but the strings are designed to make the paid version necessary for any serious commercial use.

Strategic weaponisation

Don't make money from the open source project — use it to destroy someone else's revenue. This is open source as a competitive weapon, not as a business model.

Google open-sourced Android not as a gift to humanity, but to eliminate Nokia and Microsoft's mobile licensing revenue. If the operating system is free, you can't charge for it. Google didn't need to charge — they made money from search and advertising on the devices. Their competitors needed the licence fees to survive.

Meta open-sources LLaMA and PyTorch for similar reasons. If frontier AI models are free, OpenAI's business model — charging for API access to proprietary models — comes under pressure. Meta doesn't need to sell model access. They need AI to be cheap enough that it runs across their platforms. Open-sourcing the model commoditises the layer their competitor monetises.

The pattern: open source the layer you don't monetise to destroy the margins of companies that do.

Intellectual property beyond copyright

Open source licences govern copyright — the right to copy, modify, and distribute code. But intellectual property is broader than copyright, and the gaps are where business models hide.

Trademarks. The code is open. The name is not. Red Hat's source code was always available, but the Red Hat trademark — the name, the logo, the brand — was proprietary. CentOS could take the code but not the name. This is why it was called CentOS and not Red Hat Enterprise Linux. The trademark forced competitors to strip all branding, losing the certification and support ecosystem that the name carried. Firefox has the same structure — Debian couldn't use the Firefox name and logo under Mozilla's trademark terms, so they shipped the identical code as "Iceweasel."

Patents. Some open source licences (Apache 2.0, GPLv3) include explicit patent grants. Others (MIT, BSD) say nothing about patents. A company can release code under MIT, then enforce patents that cover the same functionality. The code is free. The right to use the method it implements is not. This creates a patent minefield around apparently open software.

Trade secrets and proprietary assets. The code is open but the training data isn't. The model weights are published but the RLHF dataset is proprietary. The server software is open but the hosted version includes proprietary monitoring, analytics, and operational tooling that never touches the open repository. The boundary between "open" and "proprietary" is drawn wherever the business model needs it.

Dependency economics

Open source something that drives demand for something you sell. The open source project isn't the product — it's the marketing.

Meta open-sources large language models. Running those models requires enormous GPU clusters. Meta, as one of the world's largest purchasers of NVIDIA hardware, benefits from an ecosystem where everyone needs GPUs. The more people who run LLaMA, the higher the demand for the hardware Meta's infrastructure already depends on — and the more leverage Meta has in negotiating hardware prices at scale.

Google open-sourced Kubernetes. Running Kubernetes well is complex enough that many companies choose a managed service — and Google Cloud Platform sells one. The open source project creates the ecosystem; the cloud service captures the revenue.

Android is the same play at a different layer. The OS is free. The Google Play Services that make it useful are not. The dependency is invisible to most users but structural to the business.

Open core

Give away the base. Sell the extensions.

GitLab publishes its Community Edition under an open source licence. The Enterprise Edition adds features — advanced CI/CD, security scanning, compliance dashboards — that are proprietary. The free version is genuinely useful. The paid version is necessary for enterprise use cases. The boundary between tiers is carefully managed to create upgrade pressure without making the free version feel crippled.

This is the most common model for venture-backed open source companies. Elastic (before the licence change), Grafana, Minio, Confluent — all follow variations of it. The tension is always the same: put too many features in the open core and you can't monetise; put too few and no one adopts.

Delayed open source

Make it proprietary now, open source later. The Business Source License (BSL) pioneered by MariaDB works on a time delay: the code is source-available with commercial restrictions for a fixed period (typically 2-4 years), then automatically converts to a genuine open source licence.

CockroachDB, Sentry, and (since 2023) HashiCorp's Terraform all use variants of this. The logic: by the time the code becomes truly open, the company has moved several versions ahead. Competitors get access to yesterday's software. The vendor keeps the lead.

Certifications, compliance, and trust

You can't certify yourself. If a government, industry body, or enterprise procurement process requires a specific certification — FIPS 140-2 for cryptography, FedRAMP for US government cloud, SOC 2 for SaaS — the software must be validated by the vendor, not by a downstream distributor.

Red Hat's RHEL certifications are the classic example. The code is open. The certification is not. Hardware vendors certify their drivers against RHEL specifically. ISVs certify their applications against RHEL. A downstream rebuild like CentOS or Rocky Linux runs the same code but doesn't carry the certifications. For regulated industries — finance, healthcare, government — the certification is what you're paying for, not the software.

This is a genuine moat because certifications are expensive, slow, and vendor-specific. A competitor can fork the code in a day. They cannot fork the certification ecosystem.

Contributor licence agreements

Require every contributor to sign a legal agreement granting the company special rights over contributed code — typically the right to relicense under any terms, including proprietary ones.

This means the company can take community contributions and include them in a proprietary product. The open source version benefits from community contributions. The proprietary version benefits from the same contributions plus exclusive features. The community does free labour that strengthens the company's paid product.

MongoDB, Elastic, and Canonical all used CLAs before their licence changes. The CLA gave them the legal right to change the licence later — which they did.

Data and network effects

The code is open. The value isn't in the code.

WordPress is open source. WordPress.com is a business. The software is the same, but the hosted version comes with a network of themes, plugins, support, and a domain marketplace that creates switching costs the licence cannot.

OpenStreetMap's software is open. The map data is CC-BY-SA. But the editing community, the data quality, and the network effects of millions of contributors create a position that no fork can replicate by copying code alone.

The pattern: make the code open, keep the data or network proprietary. The moat is above the software layer.

What this means

Every one of these strategies is an attempt to reintroduce scarcity into a system that removed it. Some are legitimate (trademarks, certifications, open core). Some are deceptive (open washing). Some are strategic (weaponisation, dependency economics). All exist because the pure services model — selling support and consulting around truly open software — converges toward commodity pricing.

Red Hat is not an exception to the race to the bottom. Red Hat is the most sophisticated example of using trademarks, certifications, and first-mover scale to fight it. They didn't sell software or even services in the pure sense — they sold the Red Hat name, the RHEL certification ecosystem, and the trust that comes with being the vendor that regulated industries could point to in an audit. When CentOS threatened even that position, they acquired it and eventually killed it.

The pattern across all of these strategies is the same: the code is open, but the business model depends on something that isn't. The question for any open source company is: what's your thing that isn't?

If you don't have one, you're in the commodity services business. And in commodity services, the race to the bottom is not a risk — it is the destination.