In 2021, a single engineer named Evan Czaplicki was the primary maintainer of Elm, a programming language used in production by companies generating hundreds of millions in revenue. He was, for a long stretch, working on it part-time, sustained mostly by donations that covered less than a modest salary. This is not unusual. This is Tuesday in open source.
The math here is uncomfortable. The software infrastructure of the modern internet, from the Linux kernel to OpenSSL to curl to countless npm packages, was built largely by people who weren’t getting paid proportionally to the value they were creating. Sometimes they weren’t getting paid at all. The companies extracting that value often were.
Here’s what’s actually going on.
1. The Free Rider Problem Is Enormous and Mostly Ignored
Every company using open source software is, to some degree, a free rider. That’s not an insult. It’s the design. Open source licenses explicitly allow it. But the gap between who consumes the value and who produces it is staggering.
Consider curl. It’s on something like ten billion devices. Daniel Stenberg has maintained it for over two decades. For most of that time, the project ran on essentially no institutional funding. The companies shipping curl inside their products, some of the largest on earth, contributed almost nothing back. Stenberg has written about this at length, and his frustration is earned. You can use a piece of software in products generating billions in revenue and have no legal or social obligation to support the person keeping it alive.
2. Security Is Where the Free Riding Gets Dangerous
The 2014 Heartbleed vulnerability in OpenSSL was a landmark moment, not because it was technically unprecedented, but because it revealed something embarrassing: a library protecting encrypted communications across most of the internet was, at the time of discovery, maintained by essentially two people, one of whom was working on it part-time. The OpenSSL Foundation was operating on a budget of less than a million dollars a year. The companies depending on it included banks, cloud providers, and governments.
After Heartbleed, the Core Infrastructure Initiative (now the OpenSSF) was formed to fund critical open source projects. It helped. It did not solve the problem. The Log4Shell vulnerability in 2021 hit Log4j, a Java logging library maintained by volunteers. The blast radius covered thousands of enterprise systems worldwide. The maintainers had no advance warning, no incident response team, and no resources to match the scale of the crisis dropped in their laps.
This is the actual risk model most security teams aren’t pricing in. The unpaid labor holding up the internet is also the labor defending it.
3. VC-Backed Open Source Is a Specific Kind of Trap
The common response to the funding problem has been: build a company around the open source project. Raise venture capital, offer a hosted version, sell enterprise support. This has worked for some projects. It has quietly destroyed others.
The problem is that venture capital has a specific return requirement, and open source has a specific culture. When MongoDB changed its license to SSPL in 2018, or when HashiCorp moved Terraform to BSL in 2023, it wasn’t because the founders were greedy. It was because the economics of maintaining infrastructure software while AWS offers a managed version of your product for less is brutal. Investors want exits. Open source communities want permanence. These objectives collide.
When HashiCorp moved Terraform, the community forked it into OpenTofu within weeks. That fork now has real backing from the Linux Foundation. So you get fragmentation, confusion, and a community that learned to trust commercial open source a little less. The project that was supposed to fund the maintenance problem created a different maintenance problem.
4. The Consumption-to-Contribution Ratio Is Getting Worse
As AI coding tools make it faster to write software, more software gets written. More packages get created, more dependencies get added, more projects spin up. The number of things needing maintenance grows faster than the pool of people willing to do the maintenance work.
The npm ecosystem now has over two million packages. The vast majority are maintained by individuals, many of whom have moved on or lost interest. The famous left-pad incident in 2016, where one developer unpublishing an eleven-line package broke builds across the internet, was a preview. The actual risk isn’t malice, it’s entropy. Maintainers burn out. They get jobs. They have kids. They stop answering issues.
There’s no structural reason this gets better. The incentives for creating new open source projects are higher than ever (reputation, hiring leverage, portfolio). The incentives for doing the unglamorous work of maintaining an existing one are largely unchanged.
5. A Few Companies Do Pay, and It’s Worth Examining Why
Google, Microsoft, and Red Hat (now IBM) are among the largest contributors to Linux kernel development by commit volume. This isn’t charity. Google runs Linux at a scale that means kernel improvements directly translate to savings in data center costs. Microsoft’s Azure runs more Linux workloads than Windows workloads. They pay because their business model requires the thing they’re paying for to keep working.
This is the actual model that functions: contribution as enlightened self-interest, not altruism. When Shopify funds Ruby core development, it’s because Ruby’s performance directly affects their infrastructure costs. When Cloudflare contributes to open standards and open source networking tools, it’s because their product depends on those tools being excellent.
The lesson for everyone else is uncomfortable: if you’re not contributing, you’re hoping the companies who find it economically rational to do so will cover the gap. Sometimes they will. Sometimes they won’t prioritize the specific corner of the ecosystem your product depends on.
6. The Fix Isn’t More Donation Buttons
GitHub Sponsors, Open Collective, Tidelift, thanks.dev. These platforms exist. They help at the margins. They do not solve the structural problem, because the structural problem is that the value of open source accrues to large organizations and the maintenance burden falls on individuals.
The approaches that actually move the needle look different. Sovereign Tech Fund in Germany directly funds open source infrastructure projects as a matter of public interest, treating it like roads. The OpenSSF funds security audits and pays for actual remediation work. Some larger companies have started tracking their open source dependencies systematically and creating internal budgets for contributions, either in code or cash.
None of this is at the scale the problem requires. But the companies that take it seriously are making a different kind of bet: that the software they depend on will still be maintained when they need it most. Given what happened with Log4Shell, that bet looks pretty rational.
