Built on Borrowed Code: The Volunteer-Maintained Foundations Beneath Modern Software

The Infrastructure Nobody Owns

In 2021, a security researcher named Volkan Yazıcı discovered that Log4j, a Java logging library maintained by a small group of Apache Software Foundation volunteers, contained a critical remote code execution vulnerability. The library was embedded in an estimated hundreds of millions of applications and services worldwide, including systems operated by major financial institutions, government agencies, and technology companies. The vulnerability — Log4Shell — triggered one of the most extensive emergency patching efforts in the history of enterprise software.

The Apache team that maintained Log4j consisted of volunteers. They received no compensation from the organizations whose infrastructure depended on their work. They had no advance warning that a flaw in their library would become a global incident requiring around-the-clock response from security teams across virtually every sector of the American economy.

Three years later, the XZ Utils backdoor demonstrated that the problem had not been structurally addressed. A sophisticated, patient threat actor had spent approximately two years cultivating trust within the XZ Utils project — a compression library present in most Linux distributions — before inserting malicious code into a release candidate. The attack was discovered by accident, by a Microsoft engineer who noticed unusual SSH latency while investigating an unrelated issue.

These are not isolated incidents. They are symptoms of a systemic architectural decision that the software industry made decades ago and has never fully reckoned with.

The Dependency Economy

Modern software development is built on the concept of reusable components. Rather than implementing standard functionality from scratch, developers pull in libraries and packages that handle common tasks — cryptography, parsing, logging, networking, compression. This is, in principle, an efficient approach. Writing a reliable cryptographic library is genuinely difficult; using one that has been reviewed and tested by a large community is often more secure than writing your own.

The problem is not the concept. The problem is the economic model — or rather, the absence of one.

The npm registry, which serves the JavaScript ecosystem, hosts over two million packages. PyPI, the Python package index, contains more than five hundred thousand. The Rust crates registry, Maven Central for Java, RubyGems — each ecosystem maintains its own dependency repository, and collectively they underpin the vast majority of commercial software development in the United States. A non-trivial fraction of the packages in each of these registries is maintained by a single developer, receives no funding, and has not been updated in years.

Enterprise applications routinely carry dependency trees containing hundreds or thousands of transitive dependencies — packages that are not directly referenced by the application but are pulled in as dependencies of dependencies. The average enterprise development team has limited visibility into this dependency graph and even more limited awareness of the maintenance status of the packages within it.

The Volunteer Maintenance Problem

The central tension in this model is straightforward: the organizations that extract the most economic value from open-source packages are frequently not the organizations contributing to their maintenance. A Fortune 500 company might build a product generating hundreds of millions of dollars in annual revenue on a foundation that includes dozens of packages maintained by individuals working in their spare time, with no financial relationship between the company and the maintainers.

This is not, by itself, a violation of any agreement. Open-source licenses generally impose no maintenance obligations on authors. The problem is that the resulting system creates what economists would recognize as a classic free-rider dynamic — one in which the benefits of the shared resource are widely distributed while the costs of maintaining it are concentrated among a small group of volunteers.

Maintainer burnout is a well-documented phenomenon in open-source communities. The combination of unpaid labor, user entitlement, security pressure, and the social weight of knowing that production systems depend on your weekend project creates conditions that regularly drive capable maintainers to abandon their packages. When a maintainer abandons a widely used package, the options available to the ecosystem are limited: another volunteer steps up, the package is forked, or the dependency quietly continues to be used in an unmaintained state — sometimes for years.

Unmaintained packages are not merely a theoretical risk. They are an attack surface. The XZ Utils incident demonstrated that a well-resourced adversary is willing to invest significant time and social engineering effort to gain commit access to a trusted open-source project. The trust that makes the dependency model function — the assumption that a package with a strong reputation and a history of responsible maintenance is safe to include — is exactly the assumption that sophisticated supply chain attacks are designed to exploit.

Why the Model Persists

Given the documented risks, the persistence of this model requires explanation. Several factors contribute.

First, the immediate costs of dependency risk are largely externalized. When a vulnerability in an open-source library results in a breach, the reputational and financial damage falls on the organization operating the affected system — not on the package maintainer, who bears no legal liability. This creates weak incentives for organizations to invest in the health of the packages they depend on.

Second, the alternative to pulling in a dependency — writing and maintaining equivalent functionality internally — is genuinely expensive. For most organizations, the expected cost of a supply chain incident remains lower than the certain cost of replacing open-source components with proprietary alternatives. This calculus may be incorrect when systemic risk is properly accounted for, but it reflects how individual organizations make decisions in the absence of collective coordination mechanisms.

Third, initiatives designed to address the problem — GitHub's Sponsors program, the Open Source Security Foundation, various corporate open-source contribution programs — have made meaningful but insufficient progress. The funding that has flowed to open-source maintainers through these channels represents a small fraction of the economic value extracted from the ecosystem.

Toward a More Honest Accounting

The Software Bill of Materials — a concept that has gained regulatory traction following executive orders focused on software supply chain security — represents one structural response to the visibility problem. Requiring organizations to document and disclose their dependency trees creates at least the precondition for informed risk management.

But visibility alone does not address the underlying economic imbalance. What the dependency ecosystem requires is a funding model that aligns the interests of package consumers with the sustainability of package maintainers — one in which the organizations that build commercial value on open-source foundations contribute meaningfully to those foundations' continued health.

Until that alignment exists, the infrastructure of modern software will continue to rest on a foundation of borrowed code, maintained on borrowed time, by contributors whose continued participation no commercial enterprise has any contractual right to expect.