Who pays for the open source everything runs on?

The internet runs on open-source software maintained by a surprisingly small number of people working for surprisingly little money: the cryptography, compression, and networking libraries beneath nearly every product are volunteer projects or one or two funded maintainers, and the bill for that dependency has come due repeatedly — Heartbleed in 2014 exposed OpenSSL's near-zero funding, and the 2024 XZ Utils backdoor showed a patient attacker targeting exactly that economic fragility. The response has slowly institutionalized: corporate funding programs, government mandates, and dedicated foundations now channel money toward the critical few, but the structural gap between how much the world depends on this code and how much sustains its maintainers remains enormous.

How did the dependency stack get so deep?

Because open source won. Modern applications assemble from packages — npm, PyPI, Maven — with dozens or hundreds of transitive dependencies, each maintained by someone, somewhere, for reasons ranging from reputation to gratitude to a employer's incidental need. Surveys of the ecosystem repeatedly find the same shape: a tiny core of packages accounts for the vast majority of all downloads, and a meaningful share of that core is maintained by individuals or teams without direct funding. When a library you have never heard of — a logging component, a file-format parser, a regex engine — sits under a billion devices, its maintainer's burnout is everyone's problem. The Log4Shell crisis of December 2021 made the abstraction concrete: a volunteer-maintained logging library used almost everywhere contained a flaw that set global incident response in motion for months.

What did the incidents actually change?

Heartbleed (2014) embarrassed an industry running critical cryptography on donations; the Core Infrastructure Initiative that followed became the Linux Foundation's Core Infrastructure Program, pioneering census-style analysis identifying the most critical projects. XZ Utils (2024) raised the stakes from neglect to attack: a multi-year social-engineering campaign earned the attacker maintainer access to a library shipped by every major Linux distribution, aimed at a backdoor that was caught — barely — before wide distribution. Government responded: the U.S. National Cybersecurity Strategy explicitly commits to open-source software security as a national-resilience issue, federal grant programs have funded maintainers, and the OpenSSF — the industry's main consortium — runs funding for audits, tooling, and developer stipends. The EU's Cyber Resilience Act adds product-security duties that land partly on companies shipping open source inside products, pushing funding down the stack contractually.

Where does the money come from now?

• Corporate sponsorship and foundations: the Linux Foundation and its projects, Apache, and the Software Freedom Conservancy hold funds and pay maintainers; major tech companies sponsor at seven-figure annual levels.
• Direct developer funding: GitHub Sponsors, and for the largest projects, dedicated programs — Rust, curl, OpenSSL now run structured sponsorship rather than tip jars.
• Sovereign funds: Germany's Sovereign Tech Fund has become the model, investing public money in foundational open-source infrastructure by paying maintainers for specific backlog work, with the EU exploring similar mechanisms.
• Consortium programs: OpenSSF's Alpha-Omega funds security work on the most critical projects; its audits have covered core packages by the dozen.

Against the need, it is still thin: the entire world's institutional funding for open-source security is measured in the low hundreds of millions per year, beneath the security budget of a single large bank — for infrastructure carrying the entire digital economy.

What should organizations do?

1. Inventory your dependencies — an SBOM is now a procurement and regulatory expectation, and you cannot fund what you cannot name.
2. Fund the specific projects you lean on. The maintainers of the five libraries your product genuinely rests on deserve a sponsorship line in the engineering budget; it is cheaper than one incident.
3. Contribute back: engineering time on upstream fixes pays for itself in patch latency and maintainer goodwill.
4. Track criticality lists — Harvard's census work and OpenSSF's criticality scores tell you which projects the whole world needs healthy.

What should individuals take from this?

Two things. First, gratitude with structure: if a volunteer tool holds your work together, the maintainers' sponsor links are worth clicking. Second, realism about the software supply chain: the fragility is systemic, not a scandal — it is what a commons looks like before the institutions finish forming. The decade's trend line is genuinely toward funding, audits, and accountability becoming normal; the XZ near-miss was terrifying precisely because it showed what is at stake while that construction is still underway.