The software running your bank, your hospital records system, your car’s navigation stack, and the AI model your company just licensed almost certainly depends on open source code written by people who were never paid for it. Not as employees. Not as contractors. As volunteers who wrote good code and then discovered they’d accidentally become critical infrastructure.
This is the foundational tension of modern software: an industry worth trillions of dollars is built on a gift economy that has no real mechanism for reciprocity.
How Big Is the Number
Researchers at Harvard Business School published a study in 2024 attempting to put a dollar figure on the value of open source software used in production environments. Their estimate: the supply-side value of widely used open source packages would cost more than $4 trillion to recreate from scratch. The demand-side value, meaning what companies would have to spend to replace it, they put at roughly $8.8 trillion.
Those numbers are large enough to feel abstract, so consider a more concrete framing. The npm registry alone hosts more than two million packages. A significant portion of those are maintained by a single person. Many of those people have day jobs that have nothing to do with the package that half the internet depends on.
The Log4Shell vulnerability in 2021 made this legible to people outside the security community. Log4j, a Java logging library, was embedded in systems everywhere, from enterprise software to video games. The maintainers of the Apache project that governed it were volunteers. When a critical zero-day surfaced in December 2021, those maintainers were expected to patch, document, and communicate to millions of affected organizations, around the clock, without compensation. The response was heroic. The expectation that it would be heroic was not.
The Freeloading Problem Has a Name
Economists call this a public goods problem. Open source software is non-excludable (anyone can use it) and largely non-rivalrous (your use doesn’t reduce mine). That combination creates a classic free rider dynamic: the rational move for any individual company is to consume the resource without contributing to its maintenance, because the resource will exist regardless.
The result is a tragedy of the commons running in slow motion. The commons doesn’t collapse overnight. It degrades. Maintainers burn out. Bugs go unfixed for months. Security patches take longer than they should. Eventually, someone who cared deeply about a project stops caring, not because the work stopped mattering, but because the work stopped being sustainable.
This isn’t a niche problem affecting obscure tools. OpenSSL, the library that encrypts a substantial fraction of internet traffic, was famously found in 2014 to have a critical vulnerability called Heartbleed. At the time of discovery, the project was maintained by a handful of volunteers, one of whom was effectively a full-time contributor surviving on roughly $2,000 per year in donations. The foundation’s entire annual budget was under $1 million. The software it protected was handling transactions across hundreds of billions of dollars in commerce daily.
Why Companies Don’t Pay, Even When They Should
The free rider logic explains corporate behavior, but it doesn’t fully excuse it. Most companies using open source software aren’t making a deliberate calculation to exploit maintainers. They’re not really thinking about it at all.
Part of this is structural. When a company builds on top of open source packages, the maintenance cost doesn’t appear anywhere in a budget. There’s no invoice. No vendor relationship. No renewal reminder. The dependency is invisible until it breaks. And until it breaks, there’s no organizational pressure to fund it.
Part of it is coordination failure. Even companies that recognize the problem struggle to act. If your company pays $50,000 a year to sponsor a critical dependency and your competitors don’t, you’ve subsidized them. Unless payment becomes normalized or required, the incentive to defect is always present.
The small number of companies that do contribute back tend to be ones where engineers have enough organizational standing to make the case internally, or where a specific dependency failure has already caused expensive downtime. It takes a crisis to create a budget line.
The Experiments That Have Tried to Fix This
Several funding models have been attempted, with varying degrees of success.
GitHub Sponsors, launched in 2019, lets individuals and companies donate directly to maintainers. It has resulted in meaningful income for a small number of high-profile maintainers and essentially nothing for the long tail. The visibility problem is severe: a maintainer whose package has 50 million downloads a week may have 12 sponsors.
Open Collective provides a transparent fundraising layer for projects and has worked reasonably well for some community-governed projects. But it still requires maintainers to run what amounts to a small nonprofit alongside the technical work.
Tidelift takes a more commercial approach, signing maintainers to paid agreements in exchange for commitments to maintain, document, and remediate security issues. It’s closer to the right model because it creates an actual contractual relationship. But it covers a relatively small number of packages and requires maintainers to engage with a sales and legal process they didn’t sign up for.
The most structurally interesting intervention has been at the policy level. The EU Cyber Resilience Act, which passed in 2024, places security obligations on software products sold in Europe. The implications for open source are still being worked out, but the regulation has forced a serious conversation about who bears responsibility when free software fails in commercial contexts.
What the AI Moment Is Making Worse
The large language model boom has added a new dimension to this problem. Open source code repositories, particularly GitHub, were core training data for virtually every major code-generation model. The maintainers who wrote that code received nothing for its use in training. The companies that trained on it are now selling access to systems that can generate code in the style of, and often directly drawing from, work those maintainers produced.
This isn’t straightforwardly illegal under current copyright law. Whether it should be is a live debate. But the economic reality is clear: the value flowing from open source labor has expanded, and the compensation flowing to maintainers has not.
There’s also a subtler effect. Code-generation tools are beginning to shift how companies think about open source contributions. If an AI can write a passable implementation of something a package does, the argument for funding that package’s maintenance weakens. This logic is shortsighted, because maintaining complex software over time is nothing like generating it once, but it will influence budget conversations in ways that are hard to counter.
The Structural Fix Nobody Wants to Implement
The only durable solution is making open source maintenance a paid profession at scale. Not for every hobbyist project, but for the software on which commercial systems depend. That requires companies to treat open source dependencies as infrastructure they’re renting, with corresponding maintenance obligations, rather than gifts they’re receiving with no strings attached.
Some version of a usage-based contribution model, where companies above a certain revenue threshold that depend on critical open source packages are expected to contribute proportionally to maintenance costs, has been proposed in various forms. The Linux Foundation, the Open Source Security Foundation, and others have pushed for greater corporate commitment. Progress has been slow.
The companies with the most leverage here are the cloud providers, AWS, Google, Azure, who have built multi-hundred-billion-dollar businesses on top of open source infrastructure. All three have made contributions to open source projects. None has made those contributions at a scale proportionate to the value they extract. There is a reasonable argument that they should be required to, not asked.
The maintainer model is, in a very real sense, your most important work never making the task list. The work is invisible until it fails, and that invisibility is precisely what allows the funding problem to persist.
What This Means
The open source funding problem is not unsolved because it’s technically hard. It’s unsolved because solving it requires companies to voluntarily pay for something they currently get for free, and markets don’t do that without external pressure.
The pressure is building. Heartbleed, Log4Shell, and a string of supply chain attacks have raised the security stakes. The EU Cyber Resilience Act is forcing legal accountability. A generation of burned-out maintainers is publicly documenting why they’re quitting.
None of that is sufficient yet. But the window in which the industry can treat this as someone else’s problem is closing. The software the world runs on was written by people who deserved to be paid. Many of them are still waiting.
