Unmaintained: The Human Cost of Sustaining Open Source Infrastructure

Somewhere in a GitHub repository, a critical security patch is waiting for review. The library it addresses is downloaded tens of millions of times each week. It underpins payment processing systems, healthcare portals, and municipal government websites across the United States. And the person responsible for reviewing that patch has not opened their laptop in three weeks. Not because they are negligent. Because they are exhausted.

This scenario is not hypothetical. Variants of it have played out repeatedly over the past decade, surfacing most visibly in incidents like the Heartbleed vulnerability in OpenSSL — a project maintained by a skeleton crew with minimal funding despite being embedded in an enormous share of encrypted internet traffic — and the Log4Shell crisis, which exposed how deeply a single Java logging library had permeated enterprise software stacks without anyone systematically tracking or supporting its maintenance.

Open source maintainer burnout is not a new concern. But the scale of the problem, the structural factors driving it, and the inadequacy of existing responses have converged into something that the development community can no longer address with individual gestures of goodwill.

The Asymmetry at the Core of Open Source

The open source model rests on a fundamental asymmetry that is rarely stated plainly: the people who create and maintain software bear all of the labor costs, while the people who consume that software bear none of them. For small, niche libraries with limited audiences, this imbalance is manageable. For infrastructure-grade packages — the kind that appear in the dependency trees of thousands of commercial applications — it becomes untenable.

Consider the math. A widely used npm package might be downloaded by several hundred thousand projects. A meaningful fraction of those projects belong to companies generating substantial revenue. The maintainer of that package, in many cases, receives no compensation whatsoever. They handle bug reports, respond to security disclosures, manage pull requests, write documentation, and navigate the interpersonal dynamics of a distributed community of contributors — all while typically holding a separate full-time job.

When that workload becomes unsustainable, maintainers do not always make a formal announcement. More often, they simply stop responding. Issues go unanswered. Pull requests accumulate. Security advisories sit unacknowledged. The project enters a state of de facto abandonment that may not be formally recognized for months or years — by which point, the software it powers has propagated throughout production environments that have no visibility into its maintenance status.

What Burnout Actually Looks Like

Discussions of maintainer burnout sometimes treat it as primarily an overwork problem — a matter of too many issues and too few hours. That framing is accurate but incomplete. The developers who have spoken publicly about stepping back from major projects describe something more corrosive: a gradual erosion of the sense that their contribution is valued, combined with an intensification of its most draining aspects.

Entitlement in issue trackers is a recurring theme. Maintainers describe receiving demands framed as obligations, criticism that crosses into personal hostility, and a persistent assumption that because software is free to use, the labor of maintaining it is also free — and therefore unlimited. The emotional labor of managing these interactions, layered on top of the technical work itself, proves to be what breaks people.

There is also the particular weight of security responsibility. When a vulnerability is discovered in a widely deployed package, the maintainer becomes the focal point of an urgent, high-stakes situation that they did not create and are not compensated to resolve. The pressure can be acute, and it falls on individuals who may have no organizational support structure behind them.

Structural Responses: What Has Been Tried

The open source community and the technology industry have not been entirely passive in the face of this crisis. Several models for addressing maintainer sustainability have emerged, with varying degrees of success.

GitHub Sponsors, launched in 2019, created a direct financial channel between users and maintainers. Open Collective provides a transparent fiscal infrastructure for projects that want to receive and disburse funds collectively. Platforms like Tidelift have built a business model around aggregating enterprise subscriptions and distributing proceeds to the maintainers of packages those enterprises depend upon. These mechanisms have provided meaningful support to some projects and individuals.

The limitations, however, are significant. Funding tends to concentrate around high-visibility projects and charismatic maintainers, leaving the less prominent but equally critical infrastructure underfunded. The process of setting up and managing sponsorship programs adds administrative overhead to people who are already overwhelmed. And the amounts involved, while genuinely helpful, rarely approach compensation commensurate with the commercial value the software generates.

Some large technology companies have made more direct investments. Google's Open Source Security Foundation, Amazon's involvement in specific project funding, and Microsoft's stewardship of various open source tools represent institutional engagement that goes beyond token gestures. But critics note that corporate involvement in open source governance introduces its own complications, including the risk that company priorities shape project direction in ways that do not align with the broader community's interests.

What Organizations Can Do Differently

For companies that rely heavily on open source software — which, in 2024, means virtually every technology organization in the United States — there is a straightforward argument for treating maintainer support as an operational necessity rather than an act of charity.

A practical starting point is dependency auditing with a sustainability lens. Most engineering teams have some visibility into their dependency trees for security purposes. Extending that analysis to identify which dependencies have single maintainers, limited funding, or declining commit activity provides a basis for targeted support decisions. If a library is critical to your product and its maintainer is one person working in their spare time, that is a business risk as well as a human one.

Direct financial contributions through available platforms represent the most immediate action. Participating in programs like Tidelift, which structure enterprise contributions as subscriptions tied to specific packages, makes the economic relationship explicit and manageable. Some organizations have begun allocating a percentage of their engineering budget specifically for open source support — a small fraction of overall spend that can make a significant difference to individual maintainers.

Beyond money, contributing engineering time is often more valuable than it is perceived to be. Funded engineers assigned to upstream open source maintenance — a practice sometimes called "upstreaming" — reduce the burden on volunteer maintainers while improving the software that the contributing organization itself relies upon. This model requires organizational commitment to working in public and accepting that the resulting work benefits competitors as well as the company itself. That discomfort is worth examining critically.

A Question of Infrastructure

The framing that may ultimately prove most productive is an infrastructural one. Roads, bridges, and water systems are not maintained by individual volunteers working in their spare time because society has recognized that infrastructure too important to fail cannot be sustained on goodwill alone. Open source software has achieved a comparable level of criticality in the digital economy without attracting a comparable level of institutional commitment to its upkeep.

The Log4Shell incident prompted the White House to convene a meeting with major technology executives specifically about open source security. Legislative interest in software supply chain security has increased. These are signals that the conversation is moving, however slowly, toward treating open source maintenance as a matter of public concern rather than private virtue.

The developers who built the tools that power the modern internet deserve better than exhaustion and abandonment. Whether the community, the industry, and policymakers can collectively construct the conditions for sustainable maintenance is one of the more consequential questions facing software development in the coming decade.