The Sustainability Gap: What Organizations Owe the Open-Source Infrastructure They Depend On

In February 2021, a developer named Marak Squires modified two of his own npm packages—faker.js and colors.js—in ways that broke thousands of applications that depended on them. The incident was deliberate, a protest against what Squires described as corporations extracting value from his unpaid labor without contribution or compensation. The disruption was temporary, but the conversation it ignited was not.

For many in the software industry, the episode crystallized something that had been building for years: the open-source ecosystem is not a free resource. It is a commons maintained by human beings who have finite time, finite energy, and in many cases, finite patience for working without recognition or support. When those human beings reach their limits, the consequences are felt far beyond their personal projects.

For organizations that have built their products, pipelines, and operations on open-source foundations, this is not a peripheral concern. It is a structural risk.

The Scope of the Problem

The scale of corporate dependence on open-source software is difficult to overstate. The Linux Foundation has estimated that the open-source software used by a typical commercial application has a replacement value in the hundreds of millions of dollars. A 2022 study examining the security and sustainability of the open-source supply chain found that a significant proportion of widely-used packages were maintained by a single individual, often working without compensation.

The Log4Shell vulnerability, disclosed in late 2021, exposed just how consequential this dependence can be. The affected library—Apache Log4j—was embedded in systems across virtually every sector of the American economy, from financial services to healthcare to federal government. The maintainers responsible for patching the vulnerability worked around the clock under enormous pressure. They were volunteers.

Burnout in this context is not simply a wellness issue. It is an infrastructure issue. When a maintainer steps away from a critical project—or worse, when they make changes out of frustration or exhaustion—the downstream effects can be severe.

Why Corporate Engagement Has Fallen Short

Most large technology companies are aware of this problem in the abstract. Many have made public commitments to open-source sustainability. And yet, the gap between stated values and actual investment remains wide.

Part of the problem is structural. The benefits of open-source software accrue broadly and diffusely across an organization, while the costs of supporting it would need to be borne by a specific team with a specific budget. In most corporate accounting frameworks, there is no obvious home for "investment in the health of shared infrastructure we did not build."

Another part of the problem is cultural. Many organizations have internalized the idea that open-source software is simply available—a feature of the landscape rather than a resource that requires stewardship. This framing is convenient but inaccurate, and it leads to patterns of consumption without contribution that are, in aggregate, depleting the commons.

Finally, there is the guilt problem. When organizations do engage with open-source sustainability, they often do so in ways that feel performative or that inadvertently add burden to maintainers. Sponsorship programs that come with expectations, contribution programs that generate low-quality pull requests requiring extensive review, or public recognition campaigns that generate attention without resources—all of these can leave maintainers more exhausted, not less.

The Enlightened Self-Interest Framework

The most durable argument for corporate investment in open-source sustainability is not altruistic. It is pragmatic.

Organizations that depend on specific open-source projects have a direct financial interest in the health of those projects. If a critical dependency becomes unmaintained, the organization faces a choice between maintaining a fork internally (expensive), migrating to an alternative (disruptive), or accepting mounting security and compatibility risk (dangerous). The cost of any of these outcomes almost certainly exceeds the cost of reasonable support for the upstream project.

Framed this way, investment in open-source sustainability is not charity. It is risk management. And risk management is something that finance teams, security teams, and executive leadership already understand how to value.

This framing also changes the nature of the conversation with maintainers. Rather than approaching support as a gift that requires gratitude, organizations can approach it as a mutual arrangement—one in which the organization receives reliability and influence over project direction, and the maintainer receives resources that allow them to do the work sustainably.

What Responsible Support Actually Looks Like

Not all forms of corporate engagement with open-source projects are equally valuable. The following approaches have demonstrated meaningful impact:

Financial sponsorship without strings. Platforms like GitHub Sponsors and Open Collective allow organizations to provide direct financial support to maintainers. When this support comes without prescriptive demands about what the maintainer works on or how quickly they respond to issues, it tends to be received positively and used effectively. The Open Source Initiative and similar organizations have published guidelines for structuring these arrangements in ways that respect maintainer autonomy.

Dedicated employee time. Some organizations have created programs that allow employees to spend a portion of their working hours contributing to open-source projects their company depends on. This is distinct from volunteer contribution—it is paid time, allocated explicitly for upstream work. Google, Microsoft, and a number of other major technology employers in the United States have versions of this practice. For smaller organizations, even a few hours per week from a senior engineer can make a meaningful difference to a project's maintainers.

Sabbaticals for open-source work. A smaller but growing number of companies have offered employees extended sabbaticals specifically to focus on open-source contributions. These arrangements benefit the employee—who gains focused time for skill development and community engagement—as well as the projects they work on, and by extension, the organization that depends on those projects.

Thoughtful contribution quality. When organizations do contribute code, the quality of those contributions matters as much as the quantity. Pull requests that are well-scoped, clearly documented, and aligned with the project's existing direction reduce the review burden on maintainers. Organizations that invest in training their employees to contribute effectively are doing more for project health than those that generate high volumes of low-quality submissions.

The Broader Obligation

At OpenSkills, we believe that building open skills—skills rooted in collaboration, transparency, and shared contribution—carries with it a responsibility to the ecosystems that make those skills possible. Open-source communities are not simply a training ground or a recruitment pipeline. They are a shared professional infrastructure that requires active stewardship.

For organizations that are serious about their relationship with open-source—not just as consumers but as participants—the sustainability question is inescapable. The maintainers who keep critical projects alive are not an inexhaustible resource. They are professionals, often working without adequate support, in service of infrastructure that generates enormous value for others.

The business case for addressing this is clear. The tools to act on it exist. What remains is the organizational will to treat open-source sustainability as the legitimate business priority it has always been.