The Invisible Labor Problem: Open Source Software's Unsustainable Foundation

In January 2022, a developer named Marak Squibb deliberately corrupted two of his own open source libraries—colors.js and faker.js—rendering them dysfunctional and briefly breaking thousands of applications that depended on them. His stated reason was not sabotage in the conventional sense. It was protest. Squibb had spent years maintaining widely used software without compensation, watching corporations integrate his work into revenue-generating products while he received nothing in return. "I am no longer going to support Fortune 500s," he wrote, in a note that circulated widely across the developer community.

The incident was jarring precisely because it made visible something the industry had long preferred to treat as invisible: the enormous human labor that underpins the open source ecosystem, and the almost complete absence of any reliable mechanism for compensating the people who perform it.

This is not a new observation. Security researchers, maintainers, and a handful of technology journalists have been raising versions of this concern for years. But the accumulation of evidence—high-profile vulnerabilities in understaffed projects, a documented epidemic of maintainer burnout, and a series of near-misses that exposed just how fragile critical infrastructure can be—has made the comfortable fiction of sustainable volunteerism increasingly difficult to maintain.

The Scale of the Dependency

To understand the stakes, it helps to appreciate just how deeply commercial software depends on open source components. The Linux Foundation has estimated that free and open source software would cost more than five trillion dollars to rebuild from scratch. Libraries like OpenSSL, which encrypts a substantial portion of internet traffic, or Log4j, the logging utility whose 2021 vulnerability triggered one of the most significant security responses in recent memory, are embedded in products and services generating billions in annual revenue.

The organizations profiting from these dependencies are not primarily small startups. They are among the largest companies in the world. Amazon Web Services, Microsoft Azure, and Google Cloud have each built substantial businesses on top of open source infrastructure. The value extraction is not incidental—it is structural.

And yet the people responsible for maintaining that infrastructure frequently operate without salaries, without benefits, and without any formal acknowledgment of their contributions to the commercial ecosystem they support. A 2021 study published by Harvard Business School estimated that the total value of open source software consumed by businesses vastly exceeds the investment flowing back into its maintenance. The gap is not marginal. It is enormous.

Burnout as a Security Risk

The human consequences of this imbalance are well documented, if underappreciated in boardrooms. Maintainer burnout is not simply a welfare concern—though it should be treated as one. It is a direct security risk. Exhausted maintainers make mistakes. They defer security reviews. They stop responding to vulnerability disclosures. In some cases, they abandon projects entirely, leaving critical dependencies unmaintained and increasingly vulnerable.

The XZ Utils backdoor discovered in early 2024 illustrated this dynamic with unusual clarity. A sophisticated, patient actor spent years cultivating trust within the project's community before inserting malicious code into a compression library present in many Linux distributions. The attack succeeded in part because the legitimate maintainer was, by his own account, struggling under the weight of maintaining the project largely alone. The backdoor was caught before widespread exploitation—but only barely, and only by accident.

Log4Shell, the critical vulnerability disclosed in Log4j in late 2021, told a similar story. The library was maintained by a small group of volunteers. When the vulnerability was disclosed, those volunteers were suddenly responsible for producing a patch for software embedded in hundreds of thousands of enterprise systems, under intense pressure, without compensation, and largely without institutional support. The experience prompted at least one core contributor to publicly question whether continued involvement was worth the personal cost.

What Accountability Looks Like

The industry's response to these episodes has ranged from genuine engagement to performative concern. On the more substantive end, the White House's 2023 National Cybersecurity Strategy explicitly identified open source security as a federal priority, and subsequent executive engagement with major technology companies produced commitments—of varying specificity—to contribute resources toward open source maintenance.

The OpenSSF, the Open Source Security Foundation, has attracted meaningful corporate membership and funding, including from Google, Microsoft, and Amazon. Its efforts to systematically improve the security posture of critical open source projects represent genuine progress. But foundation membership and project-level investment are not the same thing, and the dollars flowing toward individual maintainers remain a fraction of what the problem demands.

Some funding models have shown promise at the margins. GitHub Sponsors, Open Collective, and Tidelift have each created mechanisms for directing money toward maintainers. A small number of developers have built sustainable incomes through these channels. The majority have not. The fundamental challenge is that the value created by open source software is diffuse and difficult to attribute, while the costs of maintaining it are concentrated in the lives of specific individuals.

The Corporate Accountability Gap

What is largely absent from the current conversation is a serious discussion of corporate obligation. The companies most dependent on open source infrastructure have, with notable exceptions, treated their dependency as a free resource rather than a shared responsibility. Contribution policies that sound generous in press releases often translate into a handful of engineers working on upstream projects—a rounding error relative to the value extracted.

A more defensible framework would treat open source dependency the way mature organizations treat any critical supplier relationship: with formal investment, contractual commitments, and accountability for the health of the supply chain. Some version of this is beginning to emerge through software bill of materials requirements and emerging regulatory frameworks in the European Union, but US policy in this area remains nascent.

The open source community built the infrastructure of the modern internet largely out of idealism and a genuine belief in the value of shared knowledge. That idealism deserves respect—and it deserves to be met with something more durable than gratitude. The invisible labor that keeps critical software running is not a gift the industry can continue accepting without consequence. The only question is whether the reckoning comes through deliberate reform or through the next catastrophic failure that could have been prevented.