12  The Asymmetry

By 2023, open source had won so completely that even victory could feel like extraction. Asked by the Tidelift survey what sustaining open source feels like now, one maintainer replied: “If you asked me this 20 years ago I might have something inspiring to say, but now that open source has ‘won,’ it feels like we’re just giving away our work to companies who profit from it” (Tidelift 2023, 36). The complaint is not abstract. Log4j, the small Java logging library at the center of the 2021 emergency, was run by volunteers for nothing while, in the words of the technology journalist Patrick Howell O’Neill, quoted in a 2024 Sovereign Tech Fund report, “million- and billion-dollar companies rely on it and profit on it every single day” (Ellis and Bollampalli 2024, 8). The felt reality is a one-way flow: value pours out of the commons, and very little flows back.

Put in numbers, the imbalance is vast. A 2024 Harvard Business School working paper estimated the supply-side value of all the open-source software in use, the cost of writing it once, at $4.15 billion, against a demand-side value, the replacement value firms would face if they had to build that software internally, of $8.8 trillion (Hoffmann et al. 2024). Researchers measuring the public funding of open source read that gap as evidence of a “risk of underproduction” (Osborne et al. 2024, 3). Three orders of magnitude separate what the world takes from the commons and what it returns. Noah Kantrowitz, of the Python Software Foundation, drew the conclusion a maintainer reaches: the imbalance between producers and consumers “has become so ingrained that for a company to re-pay (in either time or money) even a small fraction of the value they derive from the Commons is almost unthinkable” (Eghbal 2016, 75). And because software liability is weak, “the costs of insecurity are largely externalized and displaced onto the public” (Ellis and Bollampalli 2024, 29): the firms that profit from a fragile dependency are not the ones who pay when it breaks.

The story is true, and it is also, at the core of the structure, wrong. The simple version holds that the companies built on open source merely freeload. They do not. The Linux kernel, the most depended-upon piece of the substrate, is overwhelmingly paid work. The kernel’s twenty-fifth-anniversary report, surveying development through 2016, found that “even if one assumes that all of the ‘unknown’ contributors are working on their own time, well over 80 percent of all kernel development is demonstrably done by developers who are being paid for their work” (Corbet and Kroah-Hartman 2016, 12). The paid share was not static but rising: unpaid contribution had fallen from 14.6% in 2012 to 11.8% in 2014 to 7.7% by the period the report covered (Corbet and Kroah-Hartman 2016, 12). And the money came from no single master. “Corporate participation in the process is crucial, but no single company dominates kernel development,” the report observed, so that “no company can drive development in directions that hurt the others” (Corbet and Kroah-Hartman 2016, 12).

The breadth is the point. Across 2007 to 2019, the Linux Foundation counted 780,048 commits accepted into the kernel from 1,730 organizations, with the top twenty accounting for 68% and “a long tail of companies that only made a single commit” (Linux Foundation 2020, 13). The roster churns: firms that were strong contributors in 2007 have since been acquired and dropped away, others arrived late, and the foundation reads the turnover as a virtue, since “the diversity of contributors has been a strength and continues to provide resilience to the project” (Linux Foundation 2020, 14). Across open source as a whole, the researchers behind the Harvard estimate note that “the private sector has been the largest direct and indirect funder of OSS development to date, which is unusual among public goods” (Osborne et al. 2024, 3). Corporate money is not absent from the commons. It is the dominant input.

The funding is not only historical; it is visible and current. In March 2026 the Linux Foundation announced “$12.5 million in total grants from Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft, and OpenAI to strengthen the security of the open source software ecosystem” (Linux Foundation 2026), building on the Alpha-Omega security fund, whose grants are “made possible by generous and significant donations from Amazon Web Services, Google, and Microsoft” (Alpha-Omega 2024, 3). The security researcher Michał Zalewski, writing during the disclosure weekend, rejected the freeload diagnosis outright. The pundits “pointing fingers at the supposedly exploitative relationship between Big Tech and the open source community,” he wrote, “claim that the lack of adequate compensation is the source of all malaise. I don’t buy this.” Many major projects, he added, “are supported to a significant extent. Countless prominent OSS developers are on Big Tech payroll; quite a few projects receive hefty grants” (Zalewski 2024). Linus Torvalds had named the mechanism a quarter century earlier, and approved of it: “what better way of getting some of the less interesting work accomplished, boring stuff like maintenance and support, than doing it inside companies?” (Torvalds and Diamond 2001, 163).

What the simple story gets wrong is the core; what it sees correctly is the edge. The money is real, and it lands on the legible center while thinning across everything around it. Nadia Eghbal, the most precise chronicler of maintainer labor, mapped the shape years before XZ Utils. Projects “function well on a community basis if they are on the extremes of size,” she wrote: small ones that need little upkeep, or “very large projects that have found significant corporate support (as in the example of Linux)” (Eghbal 2016, 63). The danger sits between the poles. “Many projects are trapped somewhere in the middle: large enough to require significant maintenance, but not quite so large that corporations are clamoring to offer support. These are the stories that go unnoticed and untold” (Eghbal 2016, 63). XZ Utils, the compression project whose liblzma library every major Linux distribution leaned on, was a story in the middle. And the middle is mostly small: “47% of the packages have 0 or 1 functions,” the 2020 Census II report observed of npm, the package registry for the JavaScript world, “and the average npm package has 112 physical lines of code” (Nagle, Wilkerson, et al. 2020, 22), the scale at which a library nobody notices can still sit beneath everything.

The mechanism that funds the center is a hiring pipeline, and it runs in only one direction. For the kernel, the anniversary report observed, demonstrated skill converts into salary: “Kernel developers are in short supply, so anybody who demonstrates an ability to get code into the mainline tends not to have trouble finding job offers. . . . As a result, volunteer developers tend not to stay that way for long” (Corbet and Kroah-Hartman 2016, 12). The economists Josh Lerner and Jean Tirole had named the underlying logic in 2005: contribution pays off later, in jobs and reputation, through what they called the “signaling incentive,” and the signal is loudest where the audience is largest (Lerner and Tirole 2005, 58). Work “related to the operating systems and programming languages, whose natural audience is the community of programmers” carries “strong signaling incentives,” they wrote, while the unglamorous tasks, the ones aimed at “the much less sophisticated end user,” carry “lower signaling incentives” (Lerner and Tirole 2005, 60–61). liblzma was the second kind: critical, boring, invisible plumbing with no audience to perform for. Collin remained what he had long been, by his own public account: an unpaid hobby maintainer, carrying a dependency the rest of the system treated as settled.

Set the two measurements side by side and the asymmetry is the distance between them. The kernel runs above 80% paid; the broad population of open-source contributors does not. The 2020 FOSS Contributor Survey, which polled people rather than projects, found that “over half (51.65%)” of respondents were paid for their work, which means just under half were not (Nagle, Wheeler, et al. 2020, 14). The two numbers measure different worlds, and the survey says so itself: its data describe “people, not projects,” and “[s]ome projects may not have anyone paid to contribute to them — even if they are critical and even if some of the contributors are being paid to work on other projects” (Nagle, Wheeler, et al. 2020, 4). That caveat is the whole asymmetry in miniature. Money clusters where it can see a return, and the most critical maintainers are the hardest to see. The apparent counter-evidence runs the same way. An analysis of 2017 GitHub data, the 2020 Census II report noted, found that many of the most active contributors worked under their “Microsoft, Google, IBM, or Intel employee email addresses,” contrary to the “popular image . . . of ‘the overworked and underpaid programmer’” (Nagle, Wilkerson, et al. 2020, 25). The top committers of the most-used packages are disproportionately on a payroll, which looks like a refutation of the unpaid-maintainer thesis and is in fact the asymmetry seen from the other side: the subsidy concentrates on the heavily used, legible packages the report can rank, while the critical dependency below the ranking, liblzma among them, draws no such employment. The developer Feross Aboukhadijeh named the paradox: “[R]eliable, error-free transitive dependencies are invisible. Therefore, the maintainers are invisible, too. And, the better these maintainers do their job, the more invisible they are” (Eghbal 2020, 190).

None of this is new. The clearest precedent ran a decade before XZ Utils, in a library even more widely deployed. After the 2014 Heartbleed vulnerability exposed the private keys of much of the encrypted web, the researchers who measured its reach delivered a verdict that reads now like a forecast: “Despite the fact that OpenSSL is critical to the secure operation of the majority of websites, it receives negligible support,” and “a code review would have uncovered the vulnerability” (Durumeric et al. 2014, 486). Their closing line named the open problem directly: “Our community needs to determine effective support models for these core open-source projects” (Durumeric et al. 2014, 486). The support, at the time, amounted to almost nothing. OpenSSL, the cryptographic library standing behind hospital chains, Amazon, the FBI, and the Pentagon, was maintained by a single engineer on an annual budget of $2,000, most of it small donations, the reporter Nicole Perlroth found (Perlroth 2021). Critical-everywhere code, one unpaid maintainer, no money: the support pattern visible before Heartbleed in 2014 and Log4j in 2021 is the same one that left XZ Utils exposed in 2024, even though the failures themselves were different. The industrially subsidized kernel sits beside that pattern as the exception that proves the rule.

The asymmetry keeps producing the same failure because it is not negligence. It is rational. A company deciding how much care to spend on a dependency is running a calculation, and Russ Cox, who leads Google’s Go programming language, wrote it down in 2019: the cost of a bad dependency is “the sum, over all possible bad outcomes, of the cost of each bad outcome multiplied by its probability of happening” (Cox 2019, 38). For a hobby project the expected cost is near zero; for production software, where “servers may go down, sensitive data may be divulged, customers may be harmed,” it is high, and the rational response is to concentrate scrutiny on the dependencies that are both legible and high-stakes (Cox 2019, 38). Companies fund what they treat as an asset. They are “mostly interested in open source code itself as a ‘product’ or commodity,” Eghbal notes, valuing “code quality, influencing the project’s roadmap, and brand association” (Eghbal 2020, 187), none of which a small, invisible dependency offers. The trouble is that the diligence is unaffordable even to the person prescribing it. Cox admitted as much: the careful inspection he recommends for every new dependency is something “I have done only a subset of them for a subset of my own dependencies” (Cox 2019, 43). If the expert who designed the procedure cannot run it at scale, the gap is not a lapse. It is built into the economics.

The institutions created to close the gap demonstrate it in their own operating rules. Alpha-Omega, the security fund underwritten by the largest technology companies, explains its selection logic plainly: “we look for points of leverage and ‘shovel readiness,’” which leads to “ecosystems like Rust and foundations like the Eclipse Foundation,” because “these organizations already have relationships with security talent and the ability to hire and manage their work” (Alpha-Omega 2022, 9). A solo maintainer has no organization to receive a grant, no security team to staff, nothing to make shovel-ready. The fund concedes a floor to its own sight, the level of granularity below which, as an earlier chapter quoted it admitting, it cannot reliably measure criticality at all. That level is precisely where liblzma lived, a small library reachable beneath sshd. And when the money flows, it flows to the visible: of the roughly $2.84 million Alpha-Omega granted across eight organizations in 2023, the single largest grant, $620,000, went to the Linux kernel (Alpha-Omega 2024, 14), one of the most industrially subsidized projects in open source. The logic is sound, the recipients are real, and not one dollar reached a one-maintainer dependency like liblzma.

The neglect is not even unique to open source. Zalewski, who rejected the freeload story, pointed to its mirror image inside well-funded companies: “even with Big Tech staffing and money, if you have an internal library that almost never needs any attention, the ‘ownership’ of that code becomes pretty theoretical too. It’s hard to build a rewarding career on being very familiar with some boring, old dependency that’s just taken for granted by everyone else” (Zalewski 2024). The problem is attention and career value, not only money, which is why a 2025 interview study of closed-source firms found the opposite pattern from open source: where major supply-chain failures like SolarWinds “had no significant impact” on open-source signing adoption, they did move industry, because of “the substantial incentives, such as commercial and reputation losses, that drive greater adoption in the non-open-source industry” (Kalu et al. 2025, 94). The legible, commercially exposed core gets defended; the diffuse, unowned periphery does not. None of this makes the asymmetry acceptable. Rational is not the same as adequate, or fair, or safe.

The asymmetry is not only a matter of money. It is written into the instruments built to secure the supply chain. The flagship U.S. measure was the secure-software attestation form federal agencies required vendors to sign until the Office of Management and Budget rescinded the mandate on January 23, 2026 (Office of Management and Budget 2026, 1). Even at full force, the form carved open source out of its own scope. The form, it states, “does not cover . . . Open source software that is freely and directly obtained directly by a Federal agency,” nor “Third-party open source and proprietary components that are incorporated into the software end product used by the agency,” nor “Software that is freely obtained and publicly available” (Cybersecurity and Infrastructure Security Agency 2024, sec. I, p. 5). A freely obtained, publicly available, third-party open-source component incorporated into countless products is exactly what XZ Utils’ liblzma library is: it falls into three of the carved-out categories at once. And the form had to be signed by “the Chief Executive Officer . . . or their designee, who must be an employee of the software producer and have the authority to bind the corporation” (Cybersecurity and Infrastructure Security Agency 2024, instructions p. 4). The unit of accountability was the firm. A volunteer maintaining a critical dependency had no CEO, no corporation, and nothing to bind. The carve-out was not an oversight: the original 2022 mandate had already conceded there was no “software producer” to self-attest for open source, and routed it instead to a paid third-party assessor (Office of Management and Budget 2022, sec. II(1)(d)). The door narrowed from there, and then the mandate was withdrawn.

The same grammar runs through the rest of the apparatus. The NIST Secure Software Development Framework, the federal government’s reference standard, addresses itself to two audiences, “software producers” and “software acquirers,” both of them organizations bound by procurement (National Institute of Standards and Technology 2022, iii). The unpaid maintainer of a transitive dependency is neither. The framework knew the gap: in February 2022, as the operation against xz was already months underway, it listed applying itself “in the context of open-source software” among the topics that “future work may expand on” (National Institute of Standards and Technology 2022, 1). The instrument built to secure the software supply chain had not yet reached the part of the supply chain then being compromised. Europe’s regulators drew the same line. In the EU’s recommendations on supply-chain threats, open source appears only as something a commercial supplier must attest to, “ensuring and attesting to . . . the integrity and origin of open source software used within any portion of a product” (European Union Agency for Cybersecurity (ENISA) 2021, 28), never as labor to be sustained. The one real attempt to push the cost back onto the beneficiary is in the EU Cyber Resilience Act (CRA), which requires that a manufacturer who finds and fixes a flaw in an open-source component “report the vulnerability to the person or entity . . . maintaining the component” and “share the relevant code” upstream (European Parliament and Council of the European Union 2024, art. 13(6)). It is a genuine redistribution of effort, and it is also more work arriving in the maintainer’s inbox, triggered only when a firm happens to look.

Underneath the money and the policy sits a question about a word. Who gets to call a thing “open,” and what does the claim oblige? The dispute is not new, and it is not vague, because “open source” has a published, checkable definition. “Open source doesn’t just mean access to the source code,” the Open Source Definition begins, before listing the ten criteria a license must meet (Open Source Initiative 2007, Introduction). The standard makes corporate claims on the word falsifiable rather than rhetorical. Torvalds had used it that way in 2001, dismantling Sun Microsystems’ claim that its Jini system was open: “It was open source in the sense that you could read the source, but if you wanted to make any modifications or make it part of your infrastructure, you had to license it from Sun” (Torvalds and Diamond 2001, 151). Readable source is not open source if use and modification are gated. The move was old. The AI boom merely raised the stakes.

The current test case is Llama, the family of large language models Meta began releasing in 2023 under a license it calls open. At the center is a real grant: users get a “non-exclusive, worldwide, non-transferable and royalty-free limited license” to “use, reproduce, distribute, copy, create derivative works of, and make modifications to” the model (Meta 2024b, sec. 1(a)). The word that does the work is “limited.” Any company whose products exceeded “700 million monthly active users” on the release date “must request a license from Meta, which Meta may grant . . . in its sole discretion” (Meta 2024b, sec. 2), which is openness offered to everyone except the handful of competitors large enough to matter. A separate, incorporated acceptable-use policy bars whole fields of endeavor: “Military, warfare, nuclear industries or applications, espionage” (Meta 2024a, sec. 2(a)). And every product built on the model must display a “Built with Llama” notice (Meta 2024b, sec. 1(b)(i)), the one trademark obligation the license imposes, since “[a]ll goodwill arising out of your use of the Mark will inure to the benefit of Meta” (Meta 2024b, sec. 5(a)).

Measured against the published standard, the claim fails where the standard is most explicit. A license “must not discriminate against any person or group of persons,” which the user gate does (Open Source Initiative 2007, point 5), and “must not restrict anyone from making use of the program in a specific field of endeavor,” which the use policy does (Open Source Initiative 2007, point 6). The Open Source Initiative, the nonprofit that maintains the definition, had reached exactly that verdict about the model’s earlier version and stated it without hedging: Meta “has created the misunderstanding that LLaMa 2 is ‘open source’ – it is not,” confusing open source with “resources available to some users under some conditions” (Maffulli 2023). The grounds it named, the user gate and the field bar, carry into Llama 3.1 unchanged. None of this makes the license worthless. It is not simply closed: Meta grants users ownership of the “derivative works and modifications” they make (Meta 2024b, sec. 5(b)). The shape is the point, permissive at the center and controlled at the strategic edges of scale, brand, and field of use. That is a precise description of strategic openness. It is not a description of open source.

That openness might be a posture rather than a principle is the oldest theme in the story. In 1976 a young Bill Gates, furious that hobbyists were copying his software, wrote an open letter that framed the whole future argument in two sentences: “Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid?” (Gates 1976). He meant it as a reductio; the commons spent fifty years answering it in earnest. And when the movement needed a name that business could accept, it chose one for its marketing value. “Open source” was coined at a 1998 strategy meeting as a deliberate rebrand of “free software,” in Eric Raymond’s candid account “a marketing campaign” requiring “spin, image-building, and rebranding” to make it work (Raymond 2001, 175). The biographer Sam Williams recorded the design intent: the new label let companies “examine the free software phenomenon on a technological, rather than ethical, basis” (Williams 2010, 114). Michael Tiemann, the founder of the first free-software business, later put the lesson plainly: “it turns out that brand trumps almost everything” (Moody 2001). Eghbal saw where the logic led. Large companies embrace open source “to build trust and influence” (Eghbal 2016, 114), she wrote in 2016, and warned that digital infrastructure might come to exist in “a series of ‘walled gardens,’ each well-supported and technically open, but effectively championed by one company” with the resources to control it (Eghbal 2016, 117). The fight over Llama is that prophecy arriving on schedule.

The asymmetry is real and harmful, and the funding logic that produces it is rational; corporate openness is strategic, not charitable, and the word “open” was a brand before it was a principle. All of that holds at once. The man at the top of the structure conceded the core of it. Asked about the kernel’s elaborate, well-funded development process, Torvalds allowed that “what we do is not necessarily something that can translate to 99% of all the open source projects” (Mastery Learning 2024, 7:20). The kernel is the exception, not the model, and the distance between the exception and everything else is the asymmetry itself. The open question is the one the 2020 Census II report asked in its flat phrasing: “Are those who benefit most from FOSS projects doing their ‘fair share’ to support the communities behind them?” (Nagle, Wilkerson, et al. 2020, 14). The money reaches the legible core and stops. Who actually does the work in the long tail, who pays for it, and what it costs the people who carry it without pay are the questions the asymmetry leaves open.

Alpha-Omega. 2022. 2022 Annual Report. Open Source Security Foundation (OpenSSF). https://openssf.org/wp-content/uploads/2022/12/OpenSSF-Alpha-Omega-Annual-Report-2022.pdf.

Alpha-Omega. 2024. 2023 Annual Report. Open Source Security Foundation (OpenSSF). https://alpha-omega.dev/wp-content/uploads/sites/22/2024/02/Alpha-Omega-Annual-Report-2023.pdf.

Corbet, Jonathan, and Greg Kroah-Hartman. 2016. Linux Kernel Development: How Fast It Is Going, Who Is Doing It, What They Are Doing and Who Is Sponsoring the Work. Linux Foundation. https://www.linuxfoundation.org/hubfs/lf_pub_whowriteslinux2016.pdf.

Cox, Russ. 2019. “Surviving Software Dependencies.” Communications of the ACM 62 (9): 36–43. https://doi.org/10.1145/3347446.

Cybersecurity and Infrastructure Security Agency. 2024. Secure Software Development Attestation Form. https://www.cisa.gov/sites/default/files/2024-04/Self_Attestation_Common_Form_FINAL_508c.pdf.

Durumeric, Zakir, James Kasten, David Adrian, et al. 2014. “The Matter of Heartbleed.” Proceedings of the 2014 Conference on Internet Measurement Conference (IMC ’14) (New York), November 5, 475–88. https://doi.org/10.1145/2663716.2663755.

Eghbal, Nadia. 2016. Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation. https://www.fordfoundation.org/learning/library/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/.

Eghbal, Nadia. 2020. Working in Public: The Making and Maintenance of Open Source Software. Stripe Press.

Ellis, Ryan, and Jaikrishna Bollampalli. 2024. Bug Bounties and FOSS: Opportunities, Risks, and a Path Forward. Sovereign Tech Fund. https://www.sovereign.tech/public/files/Bug-Bounties-and-FOSS-EN.pdf.

European Parliament and Council of the European Union. 2024. Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on Horizontal Cybersecurity Requirements for Products with Digital Elements and Amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). https://eur-lex.europa.eu/eli/reg/2024/2847/oj.

European Union Agency for Cybersecurity (ENISA). 2021. ENISA Threat Landscape for Supply Chain Attacks. European Union Agency for Cybersecurity (ENISA). https://doi.org/10.2824/168593.

Gates, William H. 1976. “An Open Letter to Hobbyists.” Homebrew Computer Club Newsletter 2 (1): 2. https://commons.wikimedia.org/wiki/File:Bill_Gates_Letter_to_Hobbyists.jpg.

Hoffmann, Manuel, Frank Nagle, and Yanuo Zhou. 2024. The Value of Open Source Software. Working Paper Nos. 24-038. Harvard Business School Strategy Unit. https://doi.org/10.2139/ssrn.4693148.

Kalu, Kelechi G., Tanmay Singla, Chinenye Okafor, Santiago Torres-Arias, and James C. Davis. 2025. “An Industry Interview Study of Software Signing for Supply Chain Security.” 34th USENIX Security Symposium (USENIX Security 25) (Seattle, WA), August, 81–100. https://www.usenix.org/conference/usenixsecurity25/presentation/kalu.

Lerner, Josh, and Jean Tirole. 2005. “Economic Perspectives on Open Source.” In Perspectives on Free and Open Source Software, edited by Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani. MIT Press.

Linux Foundation. 2020. 2020 Linux Kernel History Report. Linux Foundation. https://www.linuxfoundation.org/resources/publications/linux-kernel-history-report-2020.

Linux Foundation. 2026. https://www.linuxfoundation.org/press/linux-foundation-announces-12.5-million-in-grant-funding-from-leading-organizations-to-advance-open-source-security.

Maffulli, Stefano. 2023. Meta’s LLaMa License Is Not Open Source. Open Source Initiative. https://opensource.org/blog/metas-llama-2-license-is-not-open-source.

Mastery Learning. 2024. Linus Torvalds: XZ Utils Breach Raises Questions about Trust in Open Source Development. https://www.youtube.com/watch?v=vtce4vmZIC8.

Meta. 2024a. Llama 3.1 Acceptable Use Policy. https://www.llama.com/llama3_1/use-policy.

Meta. 2024b. Llama 3.1 Community License Agreement. https://github.com/meta-llama/llama-models/blob/main/models/llama3_1/LICENSE.

Moody, Glyn. 2001. Rebel Code: Linux and the Open Source Revolution. Perseus.

Nagle, Frank, David A. Wheeler, Hila Lifshitz-Assaf, Haylee Ham, and Jennifer L. Hoffman. 2020. Report on the 2020 FOSS Contributor Survey. The Linux Foundation; Laboratory for Innovation Science at Harvard. https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf.

Nagle, Frank, Jessica Wilkerson, James Dana, and Jennifer L. Hoffman. 2020. Vulnerabilities in the Core: Preliminary Report and Census II of Open Source Software. The Linux Foundation; The Laboratory for Innovation Science at Harvard.

National Institute of Standards and Technology. 2022. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (NIST SP 800-218). U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800-218.

Office of Management and Budget. 2022. Enhancing the Security of the Software Supply Chain Through Secure Software Development Practices. https://bidenwhitehouse.archives.gov/wp-content/uploads/2022/09/M-22-18.pdf.

Office of Management and Budget. 2026. Adopting a Risk-Based Approach to Software and Hardware Security. https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf.

Open Source Initiative. 2007. The Open Source Definition. https://opensource.org/osd.

Osborne, Cailean, Paul Sharratt, Dawn Foster, and Mirko Boehm. 2024. “A Toolkit for Measuring the Impacts of Public Funding on Open Source Software Development.” arXiv Preprint arXiv:2411.06027, November 9. https://arxiv.org/abs/2411.06027.

Perlroth, Nicole. 2021. This Is How They Tell Me the World Ends: The Cyberweapons Arms Race. Bloomsbury.

Raymond, Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Revised. O’Reilly.

Tidelift. 2023. The 2023 Tidelift State of the Open Source Maintainer Report. Tidelift. https://tidelift.com/open-source-maintainer-survey-2023.

Torvalds, Linus, and David Diamond. 2001. Just for Fun: The Story of an Accidental Revolutionary. HarperBusiness.

Williams, Sam. 2010. Free as in Freedom (2.0): Richard Stallman and the Free Software Revolution. 2nd ed. Free Software Foundation. https://static.fsf.org/nosvn/faif-2.0.pdf.

Zalewski, Michał. 2024. Techies Vs Spies: The xz Backdoor Debate. https://lcamtuf.substack.com/p/technologist-vs-spy-the-xz-backdoor.