Who Should Pay for Source Code Availability? The Economic Dilemma of Open Source Sustainability

A Neglected Question in Open Source Economics

Open source software has long become the cornerstone of modern digital infrastructure. From operating systems and programming languages to countless libraries and frameworks, virtually every commercial software product relies to some degree on open source components under the hood. The dependency relationships in modern software have grown to staggeringly complex levels—take the JavaScript ecosystem as an example: npm's registry hosts over 2 million packages, and a typical enterprise Node.js application may directly or indirectly depend on hundreds or even thousands of open source packages. A 2020 report on "Open Source Software Supply Chain Security" published by Harvard and the Linux Foundation noted that open source components account for over 70% of global commercial software, with a significant proportion of these components in a state of inadequate maintenance.

Yet a core question that has long been avoided is now surfacing: When source code needs to remain continuously "available," who exactly should bear the cost?

This question seems simple but actually involves the sustainability of the open source ecosystem, the equitable distribution of benefits to maintainers, and the boundaries of responsibility for companies that depend on open source. A Hacker News discussion titled "Who Should Pay for Source Code Availability?" was modest in scale but touched on a pain point felt across the entire industry.

What Source Code Availability Really Means

It's More Than Just Putting Code on GitHub

Many people's understanding of "source code availability" stops at "uploading code to a public repository." But true availability goes far beyond that—it's an ongoing process that requires continuous resource investment:

• Hosting costs: Code repositories, mirror sites, and download bandwidth all require ongoing server and traffic expenses;
• Maintenance costs: Fixing vulnerabilities, updating dependencies, responding to issues, and reviewing PRs consume maintainers' energy day after day;
• Compliance costs: Many open source licenses require distributors to provide the corresponding version of source code, which in enterprise scenarios means additional archiving and traceability responsibilities;
• Long-term continuity: Once a project is widely adopted, it takes on an implicit social contract that it "cannot just disappear."

In other words, source code "availability" is a public good that requires long-term sustenance—not a one-time act of charity.

The Free Lunch Is Collapsing

Maintainer Burnout and the Dependency Chain Crisis

Over the past decade-plus, the open source world has repeatedly faced the same type of crisis: a critical library depended upon by millions of projects often has only one or two unpaid volunteers struggling to keep it going. When maintainers burn out and choose to walk away, the entire supply chain trembles.

The specific manifestations of these events are alarming. The 2014 Heartbleed vulnerability remains one of the most cautionary cases: OpenSSL, the cryptographic library used by two-thirds of the world's web servers, had a core development team of fewer than five full-time members for years, with annual donations under $2,000. In 2016, the npm package left-pad—just 11 lines of code—was removed from the registry by its author, causing build failures in numerous projects including React and Babel. In 2022, Marak Squires, the maintainer of colors.js and faker.js, deliberately injected infinite loop code into his own libraries to protest large companies' "free-riding" behavior, affecting over 20,000 dependent projects. That same year, the Log4Shell vulnerability (CVE-2021-44228) shook the entire industry—Apache Log4j, a logging library used by countless Java applications, had key maintainers who similarly faced severe resource constraints.

These events remind us time and again: Infrastructure built on unpaid labor is fragile.

The essence of the problem lies in a severe misalignment of value distribution: those who benefit most from open source are often large companies that integrate it into commercial products and earn enormous profits, while the costs are borne by dispersed individual maintainers who receive little in return. Research by Tidelift shows that over 80% of critical open source maintainers are unpaid individuals, while the enterprises depending on their code may generate billions in annual revenue.

Implicit Obligations Under License Terms

Interestingly, some open source licenses (such as the GPL family) explicitly require that if you distribute software, you must make the corresponding source code available to recipients. This means "source code availability" isn't just a moral expectation—under certain conditions, it's a legally binding obligation. And the cost of fulfilling this obligation is often glossed over by users.

The GPL (GNU General Public License) is a copyleft license first published in 1989 by Richard Stallman, founder of the Free Software Foundation (FSF). Its core mechanism is "viral"—any derivative work based on GPL code must also be released under the GPL, and when distributing binary code, the complete corresponding source code must be simultaneously provided or promised. GPLv2 requires distributors to provide source code at "no more than the cost of physical copying," valid for at least three years; GPLv3 further clarifies obligations in network distribution scenarios. The AGPL extends these obligations to network service scenarios, meaning that even without distributing binary files, providing services over a network requires making source code public. These clauses create complex compliance challenges in embedded devices, cloud services, and other domains, requiring enterprises to use specialized tools (such as Black Duck, FOSSA, Snyk) to track and manage open source compliance—which itself constitutes a non-negligible cost.

Who Pays: Several Possible Paths

Commercial Beneficiaries Bearing Open Source Maintenance Responsibility

The most direct answer is: Companies that derive commercial value from open source should give back to the ecosystem. This can take multiple forms:

• Directly funding maintainers of critical projects;
• Making regular donations through platforms like GitHub Sponsors and Open Collective;
• Assigning their own engineers to participate in core project maintenance;
• Bearing the infrastructure costs of mirror hosting and distribution.

In recent years, an increasing number of tech giants have established Open Source Program Offices (OSPOs), attempting to systematically manage their investment in open source communities. Google was one of the earliest companies to establish an OSPO, with responsibilities including setting open source usage policies, managing external contribution processes, handling license compliance, and coordinating funding and human resource contributions to upstream projects. As of 2023, the TODO Group (an industry organization promoting OSPO best practices) has over 80 members, including Microsoft, Amazon, and Meta.

This is a positive trend, but coverage remains far from sufficient. OSPO resource allocation tends to favor "star projects" that the enterprise depends on most deeply, while neglecting critical but inconspicuous foundational dependencies. Furthermore, small and medium-sized enterprises typically lack the resources to establish OSPOs, creating a structural blind spot in ecosystem contributions.

Foundations and Collective Sustenance Models

Another path is to pool resources and distribute them centrally through neutral foundations. Organizations like the Linux Foundation and the Apache Foundation essentially serve as "public goods sustenance intermediaries"—enterprises pay membership fees to the foundation, which then directs resources toward projects that need maintenance.

The Linux Foundation currently hosts over 700 projects, with member companies including virtually all major tech companies, and an annual budget exceeding $200 million. The Apache Software Foundation is known for its "Apache Way"—a consensus-based community governance model—hosting over 350 projects. These foundations provide not only funding but also legal protection (such as patent defense), infrastructure (CI/CD, mirror distribution), and project governance frameworks. The Open Source Security Foundation (OpenSSF), established in 2020, focuses on supply chain security, launching tools like Scorecard and Sigstore to raise the overall security level of the open source ecosystem.

The advantage of this model is that it reduces any single project's dependence on a particular company and makes maintenance work more sustainable. But it faces its own challenges: How do you fairly assess which projects deserve funding? Those obscure yet critical "long tail" dependencies often struggle to enter a foundation's field of vision. Globally, there are an estimated hundreds of thousands of active open source projects, yet only a tiny fraction can enter a foundation's protective umbrella—the vast majority of critical infrastructure continues to operate "unprotected" outside the foundation system.

Novel Licenses and Open Source Commercialization Experiments

Various "source-available" (as opposed to strictly "open source") licenses that have emerged in recent years are products of the industry's search for sustainability. These licenses allow users to view and modify code but impose restrictions on commercial use, attempting to find a balance between openness and monetization.

Since 2018, multiple open source commercial companies have modified their licensing strategies: Redis Labs introduced the Commons Clause addendum; MongoDB moved from AGPL to its self-created SSPL (Server Side Public License); Elastic changed Elasticsearch from Apache 2.0 to dual licensing under SSPL and the Elastic License; HashiCorp changed Terraform from MPL to BSL (Business Source License) in 2023. BSL, designed by MariaDB, allows code to be freely used in non-production environments but requires paid licensing for commercial production use, with the code automatically converting to a fully open source license after a specified period (typically 4 years).

The OSI (Open Source Initiative) has explicitly stated that these licenses do not conform to its "Open Source Definition" (OSD) because they impose restrictions on fields of use, violating clause 6 of the OSD. While this has sparked heated debate about whether these moves "betray the spirit of open source," it at least reflects a reality: A model that relies purely on altruism can no longer sustain the scale of the modern software ecosystem. This licensing battle fundamentally reflects the deep tension between "open source" as a public good and as a business model—when a project's commercial value is extracted at scale by cloud service providers, the original developers' impulse to protect their own interests is both understandable and in need of balance within a larger ecosystem framework.

Conclusion: From "Free" to "Fair"

The question "Who should pay for source code availability?" has no standard answer, but the very act of raising it is significant. It forces us to reexamine an assumption long taken for granted—that open source is free.

The truth is that open source has never been free; the costs have simply been invisibly transferred to a group of maintainers who lack bargaining power. As software supply chain security receives increasing attention—the 2021 U.S. White House cybersecurity executive order, the 2022 Open Source Software Security Summit, and the EU's Cyber Resilience Act with its potential implications for open source software—discussions around open source sustainability are moving from the margins to the center. Regulators are beginning to pay attention to the risks of open source dependencies, bringing unprecedented visibility to the open source ecosystem while also raising new governance challenges.

A healthy future ecosystem may not lie in keeping all software absolutely free, but rather in establishing mechanisms that allow value to flow more fairly between beneficiaries and contributors. Whether through corporate sponsorship, foundation sustenance, or licensing innovation, the ultimate goal should be the same: ensuring that the code underpinning our entire digital world can be continuously and reliably maintained.