The simple version
A handful of unpaid or underpaid developers maintain software that powers trillion-dollar companies. Those companies pay almost nothing for it.
How this actually works
In 2021, a security researcher discovered a vulnerability in Log4j, a Java logging library maintained largely by a small group of volunteers. The flaw was critical, affecting hundreds of millions of devices and systems. The ensuing panic cost companies enormous amounts in emergency patching and incident response. Amazon, Apple, Google, Microsoft, all scrambling.
The Log4j maintainers? Still volunteers. Still doing it in their spare time. One of the core contributors, Volkan Yazici, tweeted about the situation with barely concealed exhaustion: the library had been downloaded tens of millions of times, was embedded in some of the most valuable software on earth, and the maintenance team was essentially unfunded.
That moment was clarifying. Not because it was unusual, but because it was unusually visible.
The economics work like this. A developer, often scratching their own itch, writes a library or tool and releases it under an open source license. Others use it. It spreads. Eventually it becomes infrastructure, something so embedded in the software supply chain that removing it would cause cascading failures across industries. The maintainer keeps patching bugs, reviewing pull requests, writing documentation, and answering questions from strangers. All while holding down a day job, because the license they chose specifically allows commercial use with no obligation to compensate them.
As the site has covered before, open source is free the way a puppy is free. Someone is always paying the cost. Usually it’s the maintainer, in time.
Why the value doesn’t flow back
The core mechanism here is the open source license itself. Most permissive licenses, the MIT License, the Apache License, BSD variants, allow anyone to use the software commercially without paying anything. That was an intentional philosophical choice made by people who believed in shared software commons. It worked, in the sense that it enabled widespread adoption. It failed, in the sense that it created no mechanism for value to return to creators.
Companies are rational actors. If they can use something without paying for it, they will. This isn’t villainous. It’s how businesses operate. The problem is that the people relying on this software as critical infrastructure have no particular incentive to ensure its maintenance is funded, until something breaks catastrophically.
There’s also a deeper issue around visibility. Within a large tech company, the engineers know which open source libraries they depend on. But the finance team doesn’t. The procurement team doesn’t. There’s no line item for “dependencies we would be crippled without.” So even when individuals inside companies want to contribute back, they often can’t get budget approved for something that doesn’t have a sales rep calling them.
The attempts to fix it
Several models have emerged for bridging this gap, with mixed results.
Dual licensing. Some projects release under a restrictive license for commercial use and a permissive one for open use. MySQL did this, charging commercial users while keeping community access free. It works when the software has strong enough lock-in that companies will pay rather than switch. It fails when a competitor forks the permissive version and builds around the restriction, which is what happened with MariaDB after Oracle acquired MySQL.
Open core. The strategy where the base software is open but enterprise features cost money. HashiCorp, Elastic, and others built substantial businesses this way. The tension is that the line between “community features” and “enterprise features” is a constant negotiation, and drawing it too aggressively can fracture the community that made the software valuable in the first place. Elastic’s license change in 2021 prompted Amazon to fork the project and distribute their own version, which is exactly the dynamic the company was trying to prevent.
Sponsorship platforms. GitHub Sponsors and Open Collective allow individuals and companies to directly fund maintainers. The amounts involved are almost uniformly inadequate relative to the value the software creates. There are maintainers earning several thousand dollars a year for software embedded in the infrastructure of major financial institutions. It’s better than nothing. It is not a solution.
Foundation models. The Linux Foundation, Apache Software Foundation, and others provide organizational support, legal cover, and sometimes funding. This works reasonably well for very large, high-profile projects. It does nothing for the long tail of smaller libraries that collectively form an enormous part of what software is built on.
Why this matters beyond fairness
The fairness argument matters, but it’s not the most urgent one. The urgent one is fragility.
The Log4j incident showed that a critical vulnerability in one small library could destabilize global infrastructure within hours. The software supply chain depends heavily on packages that have one or two maintainers, no organizational backing, and no guaranteed continuity. When a maintainer burns out, gets sick, or simply decides they’re done, the project either dies or enters an unmaintained limbo where security issues accumulate quietly.
This has happened. The OpenSSL project, which handles encryption for a significant portion of internet traffic, was found in 2014 to have been running for years on a budget of roughly a few thousand dollars in donations per year, with most of the work done by a tiny team. The Heartbleed vulnerability that came out of that project affected an estimated half a billion servers.
The pattern is consistent: underinvestment in maintenance, followed by a crisis, followed by a surge of attention and pledges, followed by the attention dissipating while the underlying incentive structure remains unchanged.
Where this is heading
The honest answer is that no one has solved this cleanly. The approaches that generate real revenue (dual licensing, open core) tend to create tensions with the open source community that made the software worth commercializing. The approaches that preserve community norms (sponsorships, foundations) tend to generate too little money to sustain professional-quality maintenance at scale.
What probably needs to happen is for large institutional consumers of open source to treat critical dependencies the way they treat other infrastructure: as something worth paying to maintain. Some companies are moving this direction. Google, Microsoft, and others have increased contributions to the Open Source Security Foundation. The numbers are still small relative to the risk exposure.
The deeper shift required is a change in how organizations think about their software supply chain. Right now, most companies audit their dependencies for licenses and vulnerabilities. Fewer audit them for maintenance health, asking whether the projects they depend on have funded maintainers, an active development community, and a realistic succession plan. Those questions have answers. Companies mostly aren’t asking them.
Until the incentive structure changes, the people keeping the internet running will keep doing it mostly out of principle, goodwill, and stubbornness. That’s not a stable foundation for critical infrastructure. It just happens to be the one we’ve built on.
