The open-source business models that work, and the one that keeps failing

Open source as a business model attracts two kinds of nonsense: the claim that it cannot work, and the claim that it works by itself. Both are wrong, and the interesting question is more specific — which arrangements have produced durable companies, and which one keeps ending in the same place.

The ones that work

Support and operations. The software is free, the obligation is paid. Response times, escalation, updates, and somebody accountable when it breaks. Grows linearly with people rather than exponentially with licences, which makes it unfashionable and durable. The failure mode is a supplier who becomes the only one who understands the deployment, which is a thing to check rather than a reason to avoid the model.

Hosting the thing you wrote. Charging to run software anybody could run themselves. Honest, and the value is real: most organisations would rather not operate it. The pressure point is when a large cloud provider hosts it better, which is the pressure that has produced most licence changes of the last five years.

Hardware or a physical component. The software is open, the thing it runs on is not free to manufacture. Clean alignment, limited to businesses that have a physical side.

Building it for one customer at a time. Paid development that lands upstream. Unglamorous, often the first revenue an open-source company ever has, and the model that most reliably keeps a small team alive while the others develop.

The one that keeps failing

Open core: a free core with paid proprietary additions. It fails often enough that the pattern is predictable.

The problem is that the boundary has to move. Early on, generosity in the core drives adoption. As revenue pressure arrives, features that were going to be open become paid, and features that were open sometimes move. Every move damages trust with the community that produced the adoption, because the community correctly perceives that the terms are not fixed.

Then the second pressure arrives: a cloud provider offering the core as a service, capturing the hosting revenue without contributing. The usual response is a licence change to something source-available with commercial restrictions, announced as a defence of open source and functionally a departure from it.

There are companies for which this worked commercially. It has rarely worked without the trust cost, and the trust was the reason the adoption happened.

How to tell what you are looking at

Read the licence, not the headline. Source-available with restrictions is legitimate and is not open source. A company that blurs the two on its own website is telling you something about its relationship with precision.

Ask where the boundary is and who moves it. Written down, or it will move.

Check whether the free version is actually usable. A core that is a demonstration rather than a product is a trial with a different name.

Look at what happens if the company stops. Independent maintainers, a foundation, other companies shipping it. If the answer is that the project stops, the openness was a licence file rather than an ecosystem.

What we back

Support, operations and hosting, on software that is genuinely open, from teams who have written down where the boundary is before the pressure arrives.

That is a smaller opportunity than open core in the years when open core is working. It is also the version where the promise made to the customer is the same promise five years later, and for this thesis that consistency is the product.