Why big tech pays for open source

In 2001 the chief executive of Microsoft called Linux a cancer. Today Microsoft employs kernel developers, runs an enormous amount of Linux in its own cloud, ships a Linux environment inside Windows, and is a member of the foundation that stewards the project. That is not a change of heart. It is arithmetic, and the arithmetic is worth understanding because it explains something counter-intuitive about how large companies behave.

People generally read corporate involvement in open source as either charity or conquest. It is neither. It is cost control, and once you see it that way the whole pattern makes sense.

The maintenance cost of a private fork

Suppose your company needs a change to a piece of infrastructure software. You have two options. Make the change privately and keep it, or send it to the project and have it accepted.

The private version feels cheaper and is not, because the project keeps moving. Every time it releases a new version, somebody on your payroll has to reapply your change to the new code, retest it, and fix whatever it now conflicts with. That is a permanent tax, paid monthly, forever, and it grows as the gap widens. Companies that took the private route in the 2000s discovered this the expensive way.

Send the change upstream and the tax disappears. The project now maintains your change for you, because it is their code too. You paid once. That is the entire economic logic of corporate contribution, and it requires no goodwill whatsoever — which is exactly why it is reliable.

Why fund the parts you do not need

That explains contributions. It does not explain why companies pay into foundations for general maintenance of things they are not changing. The reason there is different and, I think, more interesting.

A shared platform that nobody owns is, for a large company, a defensive position. If your entire business runs on top of a component controlled by a rival, that rival has leverage over you — on pricing, on features, on timing. Contributing to a neutral commons is how you ensure the ground you are standing on cannot be sold out from under you.

This is why you find companies who compete viciously in their own markets sitting on the same foundation board, funding the same infrastructure. They are not cooperating out of fellow feeling. Each of them prefers a commons nobody controls to a platform controlled by one of the others, and that preference is stable regardless of how much they dislike each other.

There is a hiring argument too, and it is not trivial. Engineers who work on open projects are visible — their judgement is on public record, which makes them easier to assess than any interview process. Companies fund the projects their future employees are already in.

What this buys them, and what it costs everyone else

It would be naive to present this as costless. Money brings influence, even when the governance is designed to resist it.

The people with the most time to spend on a project are the ones paid to be there. Over years, priorities drift toward the use cases of the employers — which in infrastructure means large-scale server deployment, because that is who is paying. Features that matter to a person running one machine at home get attention only if a volunteer does the work.

Governance is the thing that keeps this honest, which is why I pay attention to it when choosing software. A project where one company employs the majority of maintainers is, functionally, that company's product with a permissive licence attached. That may be perfectly fine. It is simply a different risk profile from a project with a genuinely distributed set of contributors, and the difference only shows up on the day the company's interests and the users' interests separate.

The imbalance nobody has fixed

Corporate money goes where corporate risk is: big, visible, load-bearing projects. It does not reach the small libraries underneath them, which are equally load-bearing and frequently maintained by one person without payment.

This has produced real incidents — a critical flaw in a logging component used almost everywhere, maintained by volunteers; an attack that succeeded by targeting an exhausted single maintainer rather than the code. Both were failures of funding distribution rather than of open development, and both were predictable.

There are now funds specifically aimed at this, and they are an improvement on nothing. Whether they are an improvement on enough is not yet clear, and it is the open question I would put to anybody who thinks this model has settled into a stable arrangement. It has not. The money found the parts it was afraid of losing, which is not the same as the parts that matter.