How do open source companies make money?

The question comes up every time I explain to a client that the software on their new server costs nothing. If it is free, who pays the people who write it, and what happens to me when they stop? That is a good question and a sceptical one, and the honest answer is more interesting than "donations".

The clearest single data point: IBM bought Red Hat, a company whose entire product was assembled from software anyone could download for free, for around thirty-four billion dollars. That transaction settles the theoretical part of the argument. Whatever the model is, it is not charity.

What you are actually buying

The confusion comes from assuming the price of software is payment for the code. It is not, and it never really was. It is payment for a bundle: the code, plus the assurance that somebody competent will fix it, plus somebody to be accountable when it breaks, plus a guarantee that it will still be maintained in five years.

Open source separates those. The code becomes free. Everything else remains scarce, and everything else is what an organisation with something to lose is actually paying for. A bank does not buy an operating system; it buys somebody's obligation to answer the phone at three in the morning.

That is the Red Hat model in one line, and it is also, at a rather different scale, mine. Nobody pays me for Nextcloud. They pay me because the machine arrives configured, because the drives were tested, because the backup is already running, and because there is a person to call. The software being free is the reason the business is possible, not a problem it has to work around.

The models that work, and what each one costs

Support and certification. The software is free; a supported, tested, guaranteed-for-a-decade version is not. This works where the customer has regulatory or contractual reasons to need somebody accountable. It is the most durable model on the list.

Hosting. Somebody runs it for you. The software is free, the operation of it is the product. This is how a large share of modern software companies actually earn, including several whose code you could download this afternoon.

Open core. The base is open, specific additions for large organisations are not — single sign-on, audit logs, compliance features. Pragmatic and common, and also the model with the most friction, because the boundary between free and paid moves over time and users notice when it moves toward them.

Corporate employment. Much of the work on major infrastructure projects is done by people employed by companies who need that infrastructure to work well. They are not sponsoring anything; they are maintaining a shared dependency, which is cheaper than each of them maintaining a private copy.

Foundations. Neutral organisations holding trademarks and infrastructure, funded by member companies who want a shared thing to survive without any one of them controlling it. Unglamorous and load-bearing.

Where the model genuinely strains

Two failure modes, and I would be selling you something if I left them out.

The first is licence changes. Several well-known projects have, after years of open development and a large user base, moved to terms that are no longer open — usually to stop a cloud provider selling their software as a service without contributing. The reasoning is frequently sympathetic and the effect on users is the same as any other change of terms: the thing you built on is not what you built on any more. This is the strongest argument for preferring projects governed by a foundation rather than a single company, and I weight it heavily when choosing what to put on a client's machine.

The second is the distribution of money, which is badly skewed. Large infrastructure projects with corporate users are well funded. The small libraries underneath them — the ones every large project depends on, maintained by one or two people in their own time — frequently are not. That imbalance has produced real incidents, and it deserves more than a paragraph, which is why it has an article of its own.

What it means for you as a customer

One practical thing. When you choose software, look at how the project earns, because that tells you what it will do when it needs money. A project backed by a foundation with corporate members behaves differently from one owned by a company that has taken investment and must eventually show a return. Neither is disqualifying. But the second one has a plausible future in which the terms change, and knowing that in advance is the difference between a decision and a surprise.

And to answer the client's original worry: if the people writing it stop, the code does not vanish. It is on your machine, under a licence that lets anyone continue it. That is a weaker guarantee than a support contract and a considerably stronger one than the alternative, where a discontinued product simply stops existing and you were never given a copy of anything.