The simple version

Most of the software running the internet was built by volunteers and released for free. The companies that depend on it mostly don’t pay for it, and the people who maintain it mostly don’t get paid to do so.

What we’re actually talking about

When you visit a website, somewhere in the chain of events that delivers that page to your browser, open source software is doing most of the work. The server is probably running Linux. The web server software is probably Nginx or Apache. The database is likely PostgreSQL or MySQL. The programming language running the application code might be Python, Ruby, or PHP. The libraries those programs depend on number in the hundreds.

All of it is free to use. All of it was written, at least in part, by people who weren’t compensated for that specific work. And all of it is actively maintained right now, by a community that operates largely on goodwill, professional reputation, and occasional employer sponsorship.

This isn’t a niche corner of the software world. The Linux Foundation estimated that the code in a typical modern application depends on hundreds of open source components. A 2023 study by Harvard Business School researchers attempted to quantify the economic value of widely used open source software and arrived at a figure in the hundreds of billions of dollars, with a small fraction of that value flowing back to the people who built it.

Why anyone would do this for free

The standard explanation is idealism, and it’s partially right. Richard Stallman launched the free software movement in the 1980s on explicitly political grounds: software should be free as in freedom, not just free as in price. Linus Torvalds started Linux in 1991 as a personal project and made it open partly because that’s what you did in that community.

But ideology explains the origins better than it explains the present. Today, most open source contributions come from people employed at companies, and those companies have a clear financial interest in the software being maintained. Google employs engineers who work on the Linux kernel. Microsoft contributes to dozens of open source projects. Meta built and released PyTorch, the library that now underpins much of modern AI research. These aren’t acts of charity. Companies that depend on shared infrastructure have an incentive to keep it healthy, and contributing code is cheaper than forking the project and maintaining a private version.

The subtler motivation is professional. Open source work is visible in a way that internal work at most companies isn’t. A software engineer with a strong track record of contributions to a major project has a public portfolio that follows them from job to job. That visibility has real labor market value.

Dependency graph showing many large systems relying on a single small, fragile component
The shape of most open source dependency is not a web. It is a funnel, narrowing to a handful of maintainers at the bottom.

The free rider problem nobody solved

Here’s the uncomfortable math. If a library has ten million users and costs roughly $50,000 a year in maintainer time to keep running safely, each user’s fair share of that cost is less than a cent. But because individual contributions are voluntary, almost none of those users pay anything. The project is instead maintained by a handful of people who work on it out of passion or habit, often burning out after years of unpaid labor.

This isn’t hypothetical. In 2021, a maintainer of a widely used JavaScript library called colors deliberately introduced broken code into his own project to protest the lack of compensation. Thousands of applications broke overnight. A year earlier, a different maintainer of a package called is-sorted simply deleted his code from the npm registry, which cascaded into failures across projects that depended on it.

The most dangerous example remains the one that already happened. In 2014, a vulnerability called Heartbleed was discovered in OpenSSL, a library responsible for securing a significant portion of internet traffic. The project was maintained by a tiny team, chronically underfunded. The bug had been present for years. After the disclosure, companies that had relied on OpenSSL for free scrambled to fund the project retroactively. It was exactly the wrong order of operations.

The funding gap and who’s trying to close it

A few models have emerged for getting money into open source projects. None of them has fully worked at scale.

GitHub Sponsors lets individuals and companies pay maintainers directly. It’s real money for some maintainers, but the amounts are small relative to the economic value being captured. The Open Source Security Foundation, backed by major tech companies, pools resources to fund security audits and developer time. Tidelift acts as a kind of subscription intermediary, paying open source maintainers in exchange for commitments to maintain and secure their work.

The model that has produced the most actual revenue is the one described in detail in our piece on how open source became the most profitable business model in enterprise tech: give the software away, charge for the hosted service, support, or enterprise features around it. Red Hat built a multi-billion dollar business on support and certifications for Linux. HashiCorp, MongoDB, and Elastic all started as open source projects before building commercial layers on top. This approach funds the company, but it doesn’t necessarily fund the underlying community. The maintainers of the open source components those companies depend on often see nothing.

What this means going forward

The honest position is that we have built critical global infrastructure on a funding model that doesn’t work, and we have decided, collectively, to keep doing it because the infrastructure keeps working well enough that the problem stays invisible.

It stays invisible right until it doesn’t. Heartbleed was a warning. The log4shell vulnerability in 2021, which affected the Log4j logging library embedded in software across virtually every large company on earth, was another one. Log4j was maintained by volunteers.

The companies best positioned to fix this are the ones with the most to lose from a failure. When critical open source infrastructure fails, the cost falls on everyone who depends on it, which means the largest users absorb the largest losses. A coordinated funding arrangement, where major cloud providers and enterprise software companies contribute to a shared maintenance fund proportional to their reliance on specific projects, would be economically rational. It’s also the kind of collective action that companies historically resist until something breaks badly enough to force their hand.

Until then, the software that runs the world will continue to be maintained by people working largely for free, and the companies extracting value from that work will continue to account for it at its price rather than its cost.