Who Pays for Software Nobody Sells

Section 01The money behind free code isn't obvious, but it's real

Open-source software powers the internet, runs hospitals and ships inside products made by some of the wealthiest companies on earth — and much of it was written by someone who wasn't paid a cent for it. That apparent paradox has a handful of answers, none of them complete on its own.

Section 02The maintainer working evenings

The most common funding model for open-source software is no funding model at all. A programmer solves a problem, publishes the solution, and other people find it useful. Maintenance — fixing bugs, answering questions, updating the code when the world changes around it — accumulates quietly into a second job that nobody agreed to pay for.

This isn't a small phenomenon. Audits of major software infrastructure consistently turn up critical libraries maintained by one or two people in their spare time, sometimes for years. The fragility isn't hidden; it's just easy to ignore until something breaks. When the OpenSSL vulnerability known as Heartbleed was disclosed in 2014, the world discovered that a library protecting the encryption of a large fraction of the internet had been maintained by a handful of volunteers with very little financial support.

Audits of major software infrastructure consistently turn up critical libraries maintained by one or two people in their spare time, sometimes for years.

The response that followed is instructive: the Linux Foundation launched the Core Infrastructure Initiative specifically to direct money toward exactly these overlooked projects. It was a recognition that the assumption — someone will surely be paid to maintain this — was simply wrong, and that making it right required deliberate effort.

Section 03Foundations and the institutional layer

For larger projects, formal institutions provide structure and, crucially, a legal entity that can accept money. The Apache Software Foundation shepherds hundreds of projects under its umbrella, handling the legal and financial overhead so that communities of developers can focus on the code. The Free Software Foundation supports GNU software and funds some development directly. The Open Source Initiative does not fund development, but it maintains the definition of open source and accredits licences — a kind of standards body for the ecosystem.

Corporate sponsorship flows through these channels and through direct grants to projects. A company that depends on an open-source tool has a clear business reason to keep it healthy; the question is whether that reason translates into a cheque. Increasingly, it does — partly because of events like Heartbleed, and partly because platforms like GitHub Sponsors and Open Collective have made it easy to fund a specific person or project directly. Small recurring donations from many users can, in aggregate, amount to a meaningful salary, though they rarely do.

Section 04Dual licensing and selling the extras

Some projects fund themselves by selling something alongside the free code. Dual licensing is one method: the software is available under a copyleft licence, meaning anyone can use it freely but must share modifications under the same terms. A business that doesn't want those terms — typically because it wants to incorporate the code into a proprietary product without sharing its changes — can buy a commercial licence instead. The GPL and its relatives create a natural market: the licence itself becomes the lever.

MySQL, before its acquisition by Oracle, was a prominent example. Qt, the toolkit used to build graphical applications, operates on a similar principle today. The model works when the software is genuinely useful to commercial developers who have legal reasons to avoid copyleft terms.

A related approach is open-core: the core software is free and open, while advanced features — usually aimed at enterprises — are proprietary and sold as a subscription. Critics argue this can hollow out the open version over time; supporters point out that it keeps the project funded without asking users to pay for something they don't need.

Section 05What this means in practice

No single model dominates, and most successful open-source projects draw on several at once: a foundation, some corporate sponsors, a dual-licence option, and a handful of individual donors. The patchwork holds together more often than not, though the underlying tension — between software that is free to use and the people who have to maintain it — never fully resolves.

The practical upshot for anyone relying on open-source tools is simple: occasional fragility is not a sign that something is wrong with the ecosystem. It is the ecosystem, and understanding it is the first step toward contributing to its health, financially or otherwise.