The software industry has a subsidy it rarely talks about. Hundreds of billions of dollars in commercial value rest on a foundation of code written and maintained by people who, in most cases, receive nothing for it.
This is not a niche problem. It is structural. And the industry’s preference for treating it as someone else’s concern has already produced serious failures, with more coming.
The scale is not hypothetical
The Linux Foundation and Harvard’s Laboratory for Innovation Science commissioned research, published as the Census II report, that attempted to estimate the value of widely-used open source software. Their conservative finding: replacing the top open source packages used in production would cost the commercial sector around $8.8 billion. That figure almost certainly understates reality, because it only covers the most commonly imported libraries and doesn’t account for the full dependency tree any production system actually pulls in.
Consider what rides on top of that foundation. The majority of web servers run on open source software. Most cloud infrastructure runs on Linux. The machine learning frameworks powering billions in AI investment, PyTorch, TensorFlow, Hugging Face’s libraries, are open source projects. Android, which runs most of the world’s smartphones, is built on open source. When you add up the commercial activity that depends on this code, $8.8 billion starts to look like a rounding error.
The people maintaining most of this software are not doing it as part of a paid job. Many are doing it in evenings and weekends, driven by a mix of craftsmanship, community obligation, and the quiet satisfaction of building something useful. That motivation is real. It is also not a reliable substitute for compensation.
What unpaid labor actually produces
The Log4Shell vulnerability, disclosed in late 2021, affected an enormous portion of enterprise Java applications worldwide. The library at its center, Log4j, was maintained by a small group of volunteers at the Apache Software Foundation. When the vulnerability was disclosed, those volunteers faced the full weight of the internet’s security response: government agencies issuing emergency directives, Fortune 500 companies demanding immediate patches, security researchers publishing proof-of-concept exploits. The maintainers had no incident response team, no legal support, no communications staff. They had their own time and the same 24-hour days as everyone else.
This is the recurring pattern. A critical piece of infrastructure gets discovered only when it breaks or gets compromised. Before that, it was invisible, which meant no one was asking whether the people responsible for it had the resources to do the job properly.
The xz Utils backdoor discovered in 2024 followed a similar dynamic. A malicious actor spent roughly two years methodically building trust with the maintainer of a small but critical compression library, contributing helpfully, then embedding a sophisticated backdoor. The reason this attack vector existed is that the maintainer was a single volunteer under pressure, and the attacker offered relief from that pressure.
Corporate free-riding is rational and wrong
From an individual company’s perspective, not paying for open source software is completely rational. The code is free to use, competitors use it too, and contributing money or engineering time mostly benefits others. Every company faces the same calculation, so almost none of them contribute proportionally to the value they extract.
The Harvard research found that while the demand side of open source (companies consuming the software) is enormous, the supply side (funded contributors) is concentrated in a small number of large technology firms. Google, Microsoft, Meta, and a handful of others contribute meaningfully. The rest of the industry free-rides.
Funding platforms like GitHub Sponsors and Open Collective exist, and they help at the margins. But a maintainer whose library is downloaded 50 million times a month and whose work protects the integrity of thousands of production systems should not have to run what amounts to a tip jar.
The counterargument
The standard response to this argument is that open source works fine, has worked fine for decades, and that the market will sort it out. Companies that depend on critical libraries will fund them when the risk becomes visible enough.
This is partly true. After the Heartbleed vulnerability in OpenSSL exposed how thinly resourced that project was, the Linux Foundation launched the Core Infrastructure Initiative to fund critical open source security work. The Log4Shell crisis accelerated government attention to software supply chain security. The market does eventually respond.
But “eventually” is doing a lot of work in that sentence. The response comes after the crisis, not before it. The incentive structure rewards reaction, not prevention. And the maintainers who burn out quietly, who abandon projects without a headline-generating vulnerability, leave behind software that continues to run in production systems long after it stops receiving updates. That’s a risk that doesn’t show up until it does.
The position worth taking
Companies that generate material revenue from open source software have an obligation to fund it proportionally. Not as charity. Not as a reputation exercise. As a cost of doing business that they are currently externalizing onto volunteers.
The mechanism matters less than the commitment. Direct sponsorship of maintainers, funded engineering time dedicated to upstream contributions, participation in foundations, all of these work. What doesn’t work is the current default, which is to extract value continuously and contribute occasionally when embarrassed into it.
The industry has accepted that salary is only part of what engineers cost when those engineers are on payroll. It should apply the same logic to the engineers whose work it depends on but doesn’t employ. The debt is real. The question is whether the industry addresses it deliberately or waits for the next crisis to force the conversation.
