Somewhere in the dependency tree of nearly every piece of commercial software in America sits a library maintained by one person, unpaid, in their spare time. This has been true for twenty years and known for ten — the 2014 Heartbleed bug in OpenSSL, then maintained by a handful of people on a shoestring, made the point loudly enough to spawn an industry initiative. What changed in the past two years is that the problem acquired a body count of near-misses serious enough to move policy.
The defining event was the xz Utils backdoor, disclosed in March 2024: a multi-year social engineering campaign placed a maintainer in control of a compression library embedded in most Linux systems, and the backdoor was discovered essentially by luck — a Microsoft engineer noticed a half-second delay in SSH logins and pulled the thread.
Why it matters
The economic exposure is measurable. Studies of software composition consistently find that 90 percent or more of the code in a typical commercial application is open source, and the critical-path components — compression, cryptography, networking, date handling — include projects with maintainer counts you can hold in one hand. A compromise of one such library is a supply-chain incident affecting thousands of companies simultaneously.
The policy exposure is newer. Cybersecurity authorities in the United States and Europe now describe open-source maintenance as critical-infrastructure-adjacent: CISA publishes guidance on open-source security, and the EU's Cyber Resilience Act creates obligations that flow through commercial software to its open-source dependencies. The era of treating volunteer maintenance as someone else's externality is ending, however slowly the replacement arrives.
How it works
The funding mechanisms that exist fall into tiers. At the top, major foundations — the Linux Foundation, Apache, the OpenSSF — receive corporate memberships in the millions and run staffed security programs; the Core Infrastructure Initiative after Heartbleed was the template. In the middle, platforms like GitHub Sponsors, Open Collective and Tidelift route money toward individual maintainers, with total flows in the low tens of millions annually. At the bottom, government programs have appeared: Germany's Sovereign Tech Fund has funded maintenance of critical projects directly, treating it as digital public infrastructure.
The structural problem lives between the tiers. Money flows to projects with governance, branding and grant-writing capacity. The libraries most likely to be critical-and-underfunded are, almost by definition, the ones without those things — a single maintainer of a transitive dependency three levels down, whose project appears in no foundation's portfolio and whose burnout is invisible until the commits stop. The xz attacker, notably, exploited exactly this: patient, helpful-seeming contribution to an overworked solo maintainer until the keys were handed over.
Evidence
The xz incident is documented in unusual detail: the original disclosure by Andres Freund on the Openwall security list, and CISA's advisory, remain the canonical primary sources. On the dependency side, the Linux Foundation's Census studies of free and open-source software have quantified how widely a small set of packages is depended upon, and Harvard's Laboratory for Innovation Science has published census research naming the most critical packages.
On the response side, the OpenSSF's Alpha-Omega project funds security audits of critical projects; the Sovereign Tech Fund publishes its funded project list, which reads like a who's-who of invisible infrastructure — OpenSSL, curl, log4j-class components. The EU Cyber Resilience Act, now in force with phased obligations, is the first major regulation to make the maintenance status of dependencies a commercial-software compliance question.
The competing read
One school argues the market is working: after xz, corporate funding and security audits for critical projects increased materially, and the foundations' staffing of formerly neglected projects is real progress. On this view the system self-corrects through salience — each incident funds its category.
The opposing school notes that salience-driven funding is cyclical and misdirected: it arrives at the projects that had incidents, not the ones that will. The deeper fix on offer is procurement: companies that build on open source should fund their dependency tree systematically — the OpenSSF and several industry proposals call for exactly this, and a few large firms now do. The honest summary is that the problem is diagnosed, the remedies are demonstrated at small scale, and adoption lags diagnosis by the usual decade.
What happens next
Watch whether software bills of materials — now required for US federal procurement — become the mechanism that makes dependency funding auditable: you cannot fund what you cannot list. Watch whether the CRA's implementation forces European vendors to formalize their open-source stewardship. And watch the maintainer metrics themselves: commit velocity and response times on the critical-package lists are the closest thing this domain has to a vital sign, and several public dashboards now track them.