In March 2024, a Microsoft engineer named Andres Freund noticed something odd: SSH logins on a Debian test system were taking 0.5 seconds longer than they should. That half-second led him to discover a backdoor deliberately planted in xz-utils, a compression library buried so deep in the Linux stack that almost nobody thinks about it — until they have to. The backdoor had been engineered over more than two years by a contributor who had slowly earned the trust of the library's sole maintainer, a volunteer named Lasse Collin who had been publicly struggling to keep up with the project alone. Xz-utils runs on hundreds of millions of servers. It has no company behind it, no dedicated security team, and until recently, no paid maintainer. That gap between how much the world depends on a piece of software and how much anyone invests in keeping it safe has a name: the open source free rider problem.
What Is the Open Source Free Rider Problem?
The open source free rider problem is the mismatch between who uses open source software and who pays to secure and maintain it. Anyone can download, fork, and ship an open source package for free, and most companies do exactly that without ever contributing code, money, or maintainer time back to the project. The 2020 Census II report from the Linux Foundation and Harvard's Laboratory for Innovation Science found that many of the most widely used open source components in enterprise codebases are maintained by fewer than a handful of people, often a single unpaid volunteer working in their spare time. Economists call this a classic public goods problem: the software is non-excludable (nobody can be stopped from using it) and non-rivalrous (one company using it doesn't reduce the supply for anyone else). That combination means individual firms have every incentive to consume the resource and almost no individual incentive to fund it, because whatever they invest benefits every competitor who free rides on their contribution too.
Why Did Log4Shell Expose This as an Economic Failure, Not Just a Technical One?
Log4Shell exposed the free rider problem because a piece of software embedded in an estimated 3 billion devices was being maintained by a small volunteer team with no dedicated security budget. When CVE-2021-44228 was disclosed on December 9, 2021, it affected Apache Log4j, a Java logging library used inside products from Amazon, Apple, Cloudflare, IBM, Microsoft, and thousands of other companies collectively worth trillions of dollars. Yet Log4j's core maintainers were a handful of volunteers, several of whom later said publicly they had never been paid for their work on the project and were fielding hundreds of urgent messages a day during the response. The U.S. government held an Open Source Software Security Summit at the White House the following month, in January 2022, explicitly because the incident made clear that critical digital infrastructure was resting on labor nobody was funding. Log4Shell didn't create a new vulnerability class; it revealed that the companies extracting the most value from open source had invested the least in its upkeep.
How Much Value Are Companies Actually Extracting for Free?
Companies are extracting far more value from open source than they put back into it, by orders of magnitude. A 2024 Harvard Business School study by Manuel Hoffmann, Frank Nagle, and Yanuo Zhou estimated the demand-side value of open source software to firms at $8.8 trillion, meaning that's roughly what companies would have to spend to build equivalent proprietary software from scratch. The same study estimated the supply-side cost — what it would actually take to recreate the current open source ecosystem — at about $4.15 billion. That is not a rounding gap; it means the value extracted is on the order of 2,000 times greater than the cost to produce it, and only a sliver of that value ever flows back to maintainers. Synopsys' 2024 Open Source Security and Risk Analysis report found that 96% of commercial codebases now contain open source components, and 74% contained high-risk vulnerabilities, yet Tidelift's annual maintainer surveys have repeatedly found that a majority of maintainers receive no financial compensation at all for their work.
Why Did the xz-utils Backdoor Almost Succeed?
The xz-utils backdoor almost succeeded because the project's chronic understaffing made it easy for a patient attacker to become indispensable. Lasse Collin had maintained xz-utils largely alone for years and had said in mailing list threads as far back as 2022 that he was dealing with burnout and a long-term mental health leave. An account using the name "Jia Tan" began contributing patches in late 2021, steadily built credibility, and was eventually granted co-maintainer access and commit rights. Over the following two years, that access was used to insert obfuscated malicious code into the library's build process, designed to give an attacker a backdoor into SSH authentication on affected systems. It was caught by pure chance — one engineer's attention to a half-second latency spike — not by any structural safeguard in how the project was resourced or reviewed. Security researchers who examined the timeline afterward noted that the same social-engineering pattern, exploiting an overworked solo maintainer, could plausibly be running today against other single-maintainer projects that sit just as deep in the software supply chain.
Can Funding Actually Fix the Incentive Gap?
Funding helps, but at current levels it is nowhere near proportional to the risk being carried by under-resourced projects. In response to Log4Shell, the Open Source Security Foundation launched Alpha-Omega in February 2022 with $5 million in initial funding from Microsoft and Google, aimed at improving security for the most critical open source projects. Germany's Sovereign Tech Fund, launched the same year, has since invested in the maintenance of foundational projects including curl and PHP components. These are real, meaningful commitments, but they are still measured in the single-digit millions against an ecosystem the Harvard study valued in the trillions. Tidelift's paid-maintainer model and GitHub Sponsors have created some direct funding channels, yet most critical infrastructure packages still rely on maintainers subsidizing the world's largest companies with unpaid nights and weekends. Money alone also doesn't solve the problem if it isn't targeted: a 2022 Linux Foundation survey found that only about 2.5% of major open source contributors are compensated by the largest tech companies specifically for their open source work, even when those same companies rely on that code in production.
What Can Organizations Actually Do About It Today?
Organizations can act on the free rider problem today by treating dependency risk as something to be measured and managed, not assumed away. That starts with knowing what you actually run: a real software bill of materials (SBOM) rather than a spreadsheet updated once a year, so a project like xz-utils or Log4j doesn't surprise you when its next CVE lands. It continues with prioritizing which of your thousands of transitive dependencies are maintained by one or two people with no institutional backing, since those are statistically the ones most likely to be compromised or abandoned, per the same Census II findings. And it means treating financial or engineering contribution back to critical upstream projects as a cost of doing business rather than a nice-to-have, the same way companies budget for cloud infrastructure they don't own either. None of this requires waiting for the next Log4Shell to force the conversation.
How Safeguard Helps
Safeguard is built for the reality that the free rider problem isn't going away — organizations still need to ship software built on open source, they just need to stop being surprised by what's inside it. Safeguard continuously maps your software supply chain to generate accurate, real-time SBOMs across your codebases, so you know exactly which packages, versions, and transitive dependencies you're running the moment a new CVE like the next Log4Shell or xz-utils drops. It goes further than inventory by surfacing maintainer and project health signals — single-maintainer status, contributor concentration, and update cadence — the same risk factors that made xz-utils exploitable, so security teams can flag high-risk dependencies before an attacker does. When vulnerabilities are disclosed, Safeguard correlates them against your actual deployed footprint instead of every package that theoretically exists in your registry, cutting the noise that buried teams during the Log4Shell response down to the alerts that actually matter for your environment. And because the free rider problem is ultimately a resourcing problem, Safeguard gives security and engineering leaders the data to make the case internally for where to direct funding, contribution, or replacement effort — turning an abstract economic imbalance into a concrete, prioritized action list.