Every day, millions of developers pull dependencies from npm, PyPI, and RubyGems without a second thought. But behind each package is a person—often unpaid—triaging issues, reviewing pull requests, and releasing security patches. The gap between the value these maintainers create and what they receive has never been wider. This isn't a funding problem alone; it's a governance problem. The structures that govern open source projects—or fail to govern them—determine who gets paid, who burns out, and who walks away.

Maintainers Are Burning Out on a Broken Social Contract

Unpaid labor sustains billion-dollar companies. A 2023 Tidelift survey found that roughly 60% of maintainers report symptoms of burnout, and many cite financial stress as a primary factor. Nadia Eghbal's book "Working in Public" documented that a large fraction of npm packages are maintained by a single person. When that person steps away, the entire downstream supply chain wobbles. The left-pad incident of 2016, where a developer unpublished a trivial package that broke thousands of projects, remains the canonical example of this fragility.

The social contract is simple in theory: maintainers contribute code freely, and users—including corporations—give back in the form of contributions, funding, or at least gratitude. In practice, the flow is almost entirely one-directional. Companies deploy open source software to build products worth millions, yet few allocate budget to sustain the projects they depend on. The result is a system where the most critical infrastructure is maintained by volunteers who are exhausted and undercompensated.

Some maintainers have responded by reducing their availability or abandoning projects entirely. The "abandoned" label on GitHub is becoming more common. When a maintainer leaves, the community forks or adopts the project, but the underlying problem remains: the work is not valued in any economic sense. The industry consumes while contributing nothing back, and the gap is widening as the number of dependencies per project continues to grow.

Consider the case of a popular JavaScript library like Moment.js, which was maintained by a single developer for years. Despite being used by millions of projects, the maintainer received minimal financial support and eventually declared the library in maintenance mode. Similarly, the maintainer of the widely used Ruby gem 'rest-client' stepped down after years of unpaid work, leaving the project in limbo until a new maintainer stepped in. These examples highlight a pattern: the industry relies on individual goodwill, and when that goodwill runs out, the entire ecosystem suffers.

The Funding That Never Arrived: Why Open Collective and GitHub Sponsors Failed to Scale

Open Collective processes roughly $10 million per year in donations, but the distribution is heavily skewed. The top few projects—like webpack, Babel, and Vue—capture the majority of funds, while thousands of smaller projects receive a few dollars a month. GitHub Sponsors launched with a matching fund that expired in 2020, and while the platform remains active, the median maintainer earns far less than minimum wage per hour spent on project work. A 2022 survey by the GitHub Sponsors team indicated that the average sponsored maintainer earns around $500 per month, which translates to roughly $3–5 per hour for the time they invest.

Bounty programs like Bountysource and Gitcoin attract drive-by fixes for specific issues, but they rarely fund ongoing maintenance. A developer might earn $100 for a single pull request, but the triage, documentation, and community management that keep a project alive remain uncompensated. Corporate sponsorship, when it happens, is often PR-driven and irregular—a company might donate $5,000 once and then disappear for years.

The root cause is structural: donation-based funding is inherently unreliable. Maintainers cannot plan a budget around unpredictable monthly contributions. Platforms like Open Collective and GitHub Sponsors reduce the friction of giving but do not solve the problem of sustained, adequate funding. The matching fund experiment showed that even when money is available, the pipeline of donors does not grow fast enough to match the number of projects in need.

For instance, the popular web framework Svelte raised over $400,000 on Open Collective in 2023, but that is an exception. Most projects struggle to reach even $1,000 per month. The disparity creates a winner-take-all dynamic where only the most visible projects attract funding, while the long tail of dependencies remains underfunded. This is not a criticism of the platforms themselves, but a reflection of the limits of voluntary donation models.

Governance Models That Treat Contributors as Free Labor

Most open source projects use a Benevolent Dictator for Life (BDFL) model, where a single maintainer or small group holds final decision-making authority. This model concentrates power without accountability. If the BDFL burns out, becomes unresponsive, or makes unpopular decisions, the project can stall or fork. The Rust project experienced a governance crisis in 2024 over moderation policies, leading to a restructuring that added more formal checks and balances. The Node.js and io.js fork of 2014 showed that governance disputes can split communities and create long-term fragmentation.

Foundation-backed projects, such as those under the Linux Foundation or Apache Software Foundation, offer more structured governance but often favor corporate interests. Board seats are typically occupied by employees of large companies, and decisions about funding and direction reflect those companies' priorities. Individual contributors without corporate backing have little say. No standard governance document includes provisions for maintainer compensation, even though the labor is essential to the project's survival.

The absence of governance around compensation means that maintainers are expected to work for free indefinitely. When a project becomes critical to a corporation's infrastructure, the corporation may hire a maintainer, but that is a personal arrangement, not a structural one. The project itself has no mechanism to ensure that the maintainer is paid. This is a governance gap as much as a funding gap.

Take the example of the webpack project, which is governed by a core team of maintainers, most of whom are employed by companies like Google or Atlassian. While this arrangement provides stability, it also means that the project's direction is influenced by the needs of those employers. Individual contributors who are not employed by a corporate sponsor have limited influence. The governance model effectively creates a two-tier system: those with corporate backing have a voice, while independent maintainers are marginalized. This is not unique to webpack; it is a common pattern in foundation-backed projects.

The Licensing Trap: When Permissive Licenses Enable Exploitation

MIT and Apache 2.0 licenses allow anyone to use, modify, and distribute the code for any purpose, including commercial use, without payment. This is by design—open source is about freedom, not price. But the consequence is that corporations can build proprietary products on top of open source code without compensating the original authors. The license is not a contract; it's a permission grant. There is no legal obligation to pay.

Several companies have attempted to close this trap by changing licenses. HashiCorp switched from MPL to the Business Source License (BSL) in 2023, restricting commercial use by competitors. Elastic and MongoDB made similar moves, adopting the SSPL and changing their licenses to protect their revenue streams. These changes were controversial and split communities—the license change that split a database community is a case in point. The Commons Clause, which adds restrictions to permissive licenses, remains a contentious approach.

License choice is a governance decision, not just legal boilerplate. A permissive license signals that the project is free for all, but it also signals that the maintainer expects no payment. A copyleft license like AGPL forces users to share their modifications, but it does not guarantee funding. The BSL and SSPL attempt to create a middle ground, but they introduce complexity and risk alienating the community. The debate is far from settled, and each project must weigh the trade-offs.

For example, the database company Cockroach Labs adopted the BSL in 2022, generating revenue from enterprise licenses while keeping the source code available. However, this move was criticized by some in the open source community who argued that the BSL is not truly open source because it restricts use by competitors. Similarly, the Redis project's shift from BSD to the SSPL in 2018 led to the creation of a fork, GoodFORM, by a consortium of companies that preferred the original license. These examples illustrate that licensing changes can have unintended consequences, including community fragmentation and loss of goodwill.

Real Numbers: What a Maintainer's Time Is Actually Worth

The Linux Foundation estimated that the total value of unpaid open source labor is roughly 100,000 person-years per year. That figure includes contributions from occasional pull requests to full-time maintainers. The average maintainer of a popular library spends around 20 hours per week on triage alone—responding to issues, reviewing code, and testing patches. Security patches for Log4j, which emerged in late 2021, took weeks of volunteer effort from a small team, with no compensation for the overtime.

CVE assignment and disclosure coordination is another uncompensated task. When a vulnerability is found, the maintainer must communicate with reporters, coordinate embargoes, and release patches. This work is critical to the security of the entire software ecosystem, yet it is almost always done for free. At a conservative rate of $50 per hour, the annual maintenance cost for a widely used library would be around $500,000. Very few projects receive that level of funding.

These numbers are not hypothetical. The chip architect who forgot the firmware spec story illustrates how a single overlooked component can cascade into systemic risk. When maintainers are not paid, they cannot afford to focus on security, documentation, or long-term planning. The industry gets what it pays for.

To put this in perspective, consider the cost of a single security incident. The Equifax breach in 2017 was attributed to an unpatched vulnerability in Apache Struts, a widely used open source framework. The breach cost Equifax over $1.4 billion in penalties and settlements. Had the maintainers of Apache Struts been adequately funded to patch vulnerabilities promptly, the breach might have been prevented. This is not to blame the maintainers, but to highlight that the cost of underfunding open source can far exceed the cost of funding it properly.

Three Practical Fixes That Could Pay a Salary Tomorrow

One approach is to adopt a dual-license model, where the project is available under AGPL for open source use and a commercial license for proprietary use. Sentry uses this model successfully, generating revenue from companies that want to avoid the AGPL's requirements. The key is to make the commercial license affordable and easy to obtain, so that companies pay rather than risk non-compliance.

Another option is to form a maintainer-owned cooperative that pools revenue from multiple projects and distributes it based on contributions. The Open Source Collective, a fiscal host for Open Collective projects, is a step in this direction, but it does not yet enforce recurring payments. A cooperative could negotiate bulk licenses, provide shared services like security auditing, and ensure that all maintainers receive a baseline salary.

Finally, maintainers can negotiate dependency audits as paid consulting gigs. When a company depends on a library, it has an incentive to ensure the library is well maintained. A maintainer can offer a security audit, performance review, or architectural consultation for a fee. This approach works best for niche libraries where the maintainer has deep expertise. It is not scalable to every project, but it can supplement other income sources.

These fixes are not silver bullets. Dual licensing can alienate some users. Cooperatives require trust and administrative overhead. Consulting takes time away from coding. But each provides a path to a salary that does not rely on donations or corporate charity. The BSL that turned open source into a vendor lock-in playbook shows that licensing changes can backfire, but thoughtful implementation can work.

Consider the example of the web framework Django, which is governed by the Django Software Foundation. The foundation uses a dual-license model (BSD and a commercial license) to generate revenue from companies that want to use Django in proprietary products. While the foundation does not pay maintainers directly, it funds infrastructure and community events. This model could be extended to compensate core maintainers if the foundation chose to do so. Similarly, the Python Software Foundation uses a combination of sponsorship and donations to support the development of CPython, but individual maintainers are not salaried. A cooperative model could ensure that funds are distributed more equitably.

The Bottom Line: Governance Is Infrastructure, Not Charity

The gap between "free as in speech" and "free as in labor" is widening. The 2025 EU Cyber Resilience Act may force companies to pay for maintenance, because it holds them liable for using insecure software. If enforced, it could create a market for paid maintenance contracts. But regulation is slow and uncertain.

Without structural change, critical projects will collapse. Maintainers are not machines; they have bills to pay. The industry must recognize that open source governance—including funding, licensing, and decision-making—is infrastructure, not charity. A salary for a maintainer is not a handout; it's the cost of reliable software.

Some maintainers have already walked away. Others are unionizing or forming collectives. The path forward is not clear, but the status quo is unsustainable. The question is whether the industry will act before the next left-pad moment—or worse, a catastrophic supply-chain failure—forces its hand.

In the meantime, maintainers can take steps to protect themselves. They can set clear expectations about response times, limit the scope of their work, and communicate openly with their communities about burnout. They can also explore alternative revenue streams, such as paid support contracts, training workshops, or merchandise sales. While these measures are not a complete solution, they can help maintainers stay afloat while the industry catches up.

Ultimately, the responsibility lies with the companies that depend on open source software. They must invest in the infrastructure they rely on, whether through direct funding, hiring maintainers, or contributing code and resources. The era of free labor is ending. The question is whether we will build a sustainable system or watch the foundations of our digital world crumble.