In 2021, a security researcher found a critical vulnerability in Log4j, a Java logging library that almost nobody outside enterprise software circles had heard of. Within days, every major tech company on the planet was scrambling. Not because they’d chosen Log4j. Because it was just there, buried four or five dependencies deep in software they’d been shipping for years. The library was maintained by a handful of volunteers who had no idea their side project was holding up the internet.
That’s the story of open source software in a single anecdote. The foundation is everywhere. The funding is almost nowhere.
What the Stack Actually Looks Like
If you build software professionally, you don’t write most of what you ship. You assemble it. The operating system running your servers is Linux, maintained by thousands of contributors but held together by a foundation that survives largely on corporate donations and the unpaid labor of people who care. Your web server is probably Nginx or Apache. Your database is PostgreSQL or MySQL or Redis. Your programming language runtime, your HTTP client, your JSON parser, your cryptography primitives: almost all of it came from somewhere outside your company, and almost none of it was built by people who were paid to build it for you.
The Harvard Lab for Innovation Science published a study attempting to put a dollar value on this. Their estimate for the cost to rebuild the most widely used open source software from scratch ran into the hundreds of billions of dollars. The actual funding flowing to the people maintaining it is a fraction of that, by orders of magnitude.
This isn’t a niche problem for idealistic hackers. It is a structural feature of the entire technology industry, and it has produced a system with a very obvious flaw: the people who capture the most value from open source software are almost never the people responsible for keeping it alive.
The Free Rider Problem Has a Name and a Zipcode
Most large technology companies are sophisticated free riders, and they know it. They employ armies of engineers who depend on open source libraries daily. Some of them contribute back. Most don’t, not in any meaningful proportion to how much they extract. The calculus is simple and completely rational from an individual company’s perspective: if the software is free and maintained by others, there’s no competitive reason to pay for something your rivals are also getting for free.
This is a textbook collective action problem. Every company is individually incentivized to take and not give, and the cumulative result is that critical infrastructure gets maintained by whoever cares enough to do it without compensation. Sometimes that’s a retired engineer with time on their hands. Sometimes it’s a graduate student. Sometimes it’s one person holding together a library used by millions of production systems, responding to bug reports at midnight because nobody else will.
Open source maintainers work for free so you don’t have to. We’ve written about the human cost of this before. The economic argument is just as damning.
When the Bill Comes Due
The Log4Shell vulnerability wasn’t a fluke. It was the predictable outcome of under-resourced maintenance on critical infrastructure. The same dynamic produced the Heartbleed bug in OpenSSL in 2014. OpenSSL, at the time of discovery, was securing a significant portion of encrypted internet traffic. The team maintaining it had an annual budget of around $2,000. Two thousand dollars. Companies worth hundreds of billions of dollars were built on top of software maintained on that budget.
After Heartbleed, there was a genuine moment of reckoning. The Linux Foundation launched the Core Infrastructure Initiative. Google, Microsoft, Amazon, and others pledged support. It helped. But the structural incentive didn’t change. Most companies went back to taking the software for granted.
The pattern repeats because the consequences are diffuse and delayed. A vulnerable dependency sits quietly in production for months or years before someone finds it. When the breach happens, the blame lands on the company that shipped the software, not the industry-wide failure to fund the infrastructure underneath it. The software nobody rewrites is usually the most critical, and the software nobody funds is usually the most relied upon.
The Business Model Problem Is Real But Solvable
The counterargument usually runs like this: open source is a feature, not a bug. It enables collaboration and innovation at a scale that proprietary software can’t match. Charging for it would fragment the commons. This is true and irrelevant. Nobody is arguing that open source licenses should change. The argument is that the people doing the work should get paid.
Some companies have figured this out in pieces. HashiCorp sold enterprise features on top of open source tooling. Elastic did the same. Red Hat built an entire business on support and services around Linux. These models work, though they create their own tensions when a company decides to change its license in ways that hurt the community that built it.
The more honest solution is something closer to what a few large companies already do quietly: fund foundations, employ core maintainers directly, and treat open source contributions as a genuine line item rather than a PR story. Google employs full-time contributors to Chromium, V8, and many other projects. Microsoft employs people to work on TypeScript and contributes significantly to Linux. Amazon funds the Rust Foundation. These are real contributions, even if they’re still small relative to the value extracted.
What doesn’t work is the current default: assume the volunteers will handle it, ship the software, collect the revenue, and wait for the next crisis to prompt a temporary wave of concern before attention moves on.
The Reckoning That Keeps Getting Postponed
The tech industry has a long-running habit of treating externalities as someone else’s problem until they become impossible to ignore. The open source funding gap is in that category. The infrastructure is degrading slowly, not catastrophically, which makes it easy to deprioritize. Maintainers burn out and walk away. Security audits don’t get done. Bugs sit unfixed. None of it shows up on any company’s quarterly report until a Log4Shell lands and suddenly everyone’s incident response team is working Christmas.
The companies with the most to lose here are the mid-sized ones: too large to ignore the risk, too small to have meaningful leverage over the foundations and maintainers they depend on. They’ve inherited a stack they didn’t build, can’t fully audit, and have no direct relationship with the people keeping it alive.
Paying for open source is not charity. It’s infrastructure maintenance, the same way paying for your cloud provider is infrastructure maintenance. The industry that prides itself on moving fast has been coasting on a foundation it didn’t build and hasn’t bothered to pay for. Eventually, that bill comes due. The Log4j moment showed what that looks like. The next one will too.
