Who Pays for Open Source? The Case For and Against Funding Maintainers
Almost every modern program is assembled, in large part, from software that its authors did not write and did not pay for. A web service may rest on an open-source operating system, a web server, a database, a programming language runtime and hundreds of smaller libraries, many of them maintained by a handful of volunteers. This arrangement has produced extraordinary economic and technical value, yet it also raises a question that the industry has answered poorly: who should pay for the upkeep of software that everyone uses and no one owns? This article argues that sustained funding of open-source maintainers is justified on grounds of security and reliability, but that funding is not a cure-all. Money brings its own distortions, and the most durable solutions are likely to combine several models rather than rely on any single one.
The problem of shared infrastructure
Open-source software has the economic character of a public good. One organization’s use of a library does not diminish another’s, and it is difficult to exclude anyone from using it. Economists have long observed that such goods tend to be underprovided when each beneficiary hopes that someone else will bear the cost. In the open-source world, the result is a familiar pattern: a small library becomes widely depended upon, its original author continues to maintain it in spare time, and the volume of bug reports, feature requests and security reports grows long after the author’s enthusiasm has faded.
Several well-known episodes made this pattern visible. The Heartbleed vulnerability, disclosed in 2014, affected the OpenSSL library, which protected a very large share of encrypted web traffic while being maintained by a very small team with modest resources. The Log4Shell vulnerability, disclosed in December 2021, was found in Log4j, a logging library embedded in countless enterprise applications and maintained by volunteers at the Apache Software Foundation. In 2016, the removal of a tiny package called left-pad from the npm registry briefly broke the builds of many projects, demonstrating how deep and fragile dependency chains had become. None of these incidents proves that volunteer-maintained software is inferior to commercial software, which has suffered its own serious flaws. They do show that critical dependence and thin resourcing can coexist.
The case for funding maintainers
The strongest argument for paying maintainers is that the work has real costs and real beneficiaries. Reviewing contributions, triaging security reports, writing documentation, answering questions and coordinating releases are demanding forms of labor. When they are unpaid, they are performed by people who can afford to work for free, which narrows the pool of maintainers and exposes projects to burnout and abrupt abandonment. Funding allows a project to treat maintenance as a profession rather than a hobby, and it allows maintainers from a wider range of economic circumstances to participate.
A second argument concerns security. Many serious vulnerabilities persist not because they are hard to fix but because no one has the time to audit code, build test suites or respond promptly to reports. Paid maintainers can schedule security reviews, adopt safer development practices and respond to disclosures within a predictable window. For an organization that depends on a library, supporting its maintainers is often cheaper than absorbing the consequences of a breach or an emergency migration. In this sense, funding functions as a form of insurance that benefits the whole ecosystem, including the funders.
A third argument is one of fairness. Companies that earn substantial revenue from open-source components while contributing nothing back are, in a plain sense, free riders. Many organizations have recognized this and now employ maintainers directly, sponsor foundations or contribute to community funding platforms. Those arrangements show that the principle is workable: organizations can and do pay for the commons when they conclude that their own interests depend on it.
The case for caution
The counterarguments deserve equal weight. The first is that funding can alter the character of a project. Open-source communities often function because participants share a norm of voluntary, merit-based contribution. When money enters, questions arise about who decides how it is spent, which tasks are compensated and which are not, and whether paid contributors gain disproportionate influence over the direction of the project. A project that is funded chiefly by a few large companies may find its priorities drifting toward those companies’ needs, even without any explicit pressure.
The second concern is that money does not automatically produce quality or security. Audits are valuable, but they are periodic and limited in scope, and a funded project can still ship a serious flaw. There is also a risk of moral hazard: if organizations come to believe that a donation purchases assurance, they may invest less in their own testing, monitoring and dependency management. A sponsorship payment is not a substitute for a company’s responsibility to understand what it ships. Treating funding as a complete answer to supply-chain risk could therefore foster a false sense of safety.
The third concern is distributional. Funding tends to flow toward projects that are already visible, such as large frameworks and widely used tools, while the quiet utility libraries deep in the dependency tree remain unnoticed. Because attention and money are both unevenly distributed, a funding-based approach can reproduce the very concentration of resources that it was meant to correct. Identifying which projects are truly critical is itself a difficult analytical task, and any metric used to allocate money will invite attempts to game it.
Finally, there is a philosophical objection. Some contributors value open source precisely because it is a space outside the market, where people build things because they find them worthwhile. They may worry that commercializing maintenance changes the relationship between maintainers and users, turning a collaborative exchange into a service contract, with the expectations of responsiveness and warranty that a contract implies. Maintainers who accept payment may find themselves under pressure to prioritize paying users over the wider community, and some find that tension uncomfortable enough to decline funding altogether.
Models that have been tried
Several funding models exist, each with its own strengths and weaknesses. Individual sponsorship, offered by platforms such as GitHub Sponsors and Open Collective, is simple and keeps decision-making close to the maintainer. Its weakness is that the money is often small and unpredictable, and it favors maintainers who are skilled at self-promotion. Foundations, such as the Apache Software Foundation, the Linux Foundation and the Python Software Foundation, provide legal structure, neutral governance and pooled resources. They can offer stability, though they also introduce administrative overhead and may be shaped by the priorities of their largest members.
Direct employment is perhaps the most common arrangement in practice: a company hires a maintainer to work on a project the company relies on. This provides a steady income and deep expertise, but it ties the maintainer’s livelihood to a single employer, whose commercial interests may change. Dual licensing and commercial support offerings let a project sell a paid edition or services alongside the free code. These can fund development, but they sometimes cause friction with the community, as when several projects have changed from permissive open-source licenses to licenses with usage restrictions, such as the Server Side Public License adopted by Elastic in 2021 or the Business Source License adopted by HashiCorp in 2023. Supporters of those changes argued that they protected the ability to fund development against cloud providers; critics argued that they broke the compact on which community contributions had been made. Reasonable observers have disagreed, and both sides have identified real costs.
Public funding is a more recent addition. Governments and public bodies in several countries have begun to treat critical open-source software as infrastructure worthy of investment, much like roads or standards bodies. The appeal is that public money is not tied to a single company’s interests. The drawbacks are the usual ones for public programs: slow processes, political variation from year to year, and the difficulty of deciding what counts as critical.
Weighing the evidence
Comparing these arguments, a few conclusions seem defensible. First, the status quo of unpaid maintenance for critical infrastructure is difficult to defend on either efficiency or security grounds. The costs of neglect are real, and they fall on organizations and individuals who had no say in the matter. Second, funding is necessary but not sufficient. A payment makes maintenance sustainable; it does not guarantee that the maintenance is done well, and it should accompany, not replace, good engineering practice on the part of those who consume the software.
Third, the form of funding matters as much as the amount. Arrangements that preserve open governance, spread risk across many contributors and avoid dependence on a single sponsor appear more resilient than arrangements that concentrate influence. Fourth, consumers of open-source software have obligations beyond payment. Maintaining an inventory of dependencies, contributing fixes upstream, reporting problems constructively and budgeting time for updates are all forms of support that cost money to the consumer but strengthen the project.
It is also worth acknowledging what remains uncertain. We lack a reliable way to measure how critical a given project is, and so we cannot be sure that money is reaching the places where it would do the most good. We also cannot say with confidence how much funding changes community culture over the long term, since the experiments are still young and the circumstances of each project differ. Honest advocates of funding should concede this uncertainty, just as honest skeptics should concede that volunteerism alone has repeatedly proved too fragile for the loads placed on it.
Conclusion
The sustainability of open source is neither a crisis that demands a single sweeping remedy nor a problem that will resolve itself. The software commons has delivered immense value precisely because it was open, and the same openness makes it easy for beneficiaries to take without giving. Funding maintainers addresses that imbalance, improves security and broadens participation, but it also carries risks of capture, complacency and uneven distribution. A measured approach would diversify the sources of support, preserve transparent governance, and pair financial contributions with responsible dependency management on the part of every organization that builds on shared code. The goal is not to turn the commons into a market, but to ensure that the people who keep it running can afford to do so.
GenM Software Team
