Your Side Project Is Now Someone Else's Critical Infrastructure — Now What?

Imagine you spend a few weekends building a small library that solves a problem you kept running into at work. You put it on GitHub, write a decent README, and mostly forget about it. A year later, you notice the download numbers climbing. Two years later, you're getting bug reports from people at companies you recognize. Three years later, someone at a conference mentions your project in a talk about their production stack, and you realize that a tool you built for fun is quietly keeping something important running.

This is not a hypothetical. It happens constantly in the open-source world, and it's the origin story of some of the most consequential infrastructure vulnerabilities and maintainer crises of the past decade. The names change — Log4j, colors.js, left-pad, core-js — but the pattern is remarkably consistent: a small project, often maintained by one or two people, becomes load-bearing for an ecosystem far larger than its authors ever intended to support.

Understanding why this keeps happening, and what maintainers can actually do about it, matters more than ever as open-source software becomes the invisible foundation of nearly every digital product in the country.

How Projects End Up Here

The path from hobby project to critical infrastructure is usually gradual enough that nobody notices it happening in real time. A library solves a common problem well. Developers adopt it because it works. Those developers build products that ship to customers. Those products generate revenue. The library becomes a dependency of other libraries, multiplying its reach. At some point, removing it from the ecosystem would require coordinated work across dozens or hundreds of projects — which means, in practice, it's not going anywhere.

None of this requires any action or decision by the maintainer. It happens through the aggregated choices of thousands of individual developers, each making a locally rational decision to use something that works. The maintainer, meanwhile, is still treating the project as a side project: responding to issues when they have time, cutting releases when something important breaks, maybe burning through a Saturday to fix a regression.

The asymmetry is stark. A single maintainer's weekend work is holding up infrastructure that might generate millions of dollars in value for companies that have never contributed a line of code or a dollar to the project.

The Power Dynamic Nobody Wants to Name

When corporate users of open-source software do engage with maintainers, the interaction often reveals an uncomfortable power dynamic. The company needs the project to keep working. The maintainer wants help maintaining it. But the company holds most of the leverage — it can threaten to fork the project, fund a competitor, or simply stop using it — while the maintainer's options for extracting fair compensation are limited.

This plays out in ways that are sometimes subtle and sometimes not. Enterprise users file detailed bug reports that amount to free QA work — useful, but also time-consuming to triage. They request features that serve their specific use cases, creating implicit pressure on maintainers to prioritize commercial needs over community ones. They sometimes show up to project governance discussions with resources and organizational capacity that individual contributors can't match, gradually shifting the project's direction without anyone quite deciding that happened.

Daniel Stenberg, the creator and primary maintainer of curl — software that runs on billions of devices and is used by virtually every major tech company — has written extensively about this dynamic. The pattern he describes is familiar to anyone who has maintained a widely-used open-source project: enormous responsibility, limited recognition, and a funding model that essentially relies on the goodwill of organizations with significant financial interests in the project's continued existence.

What Burnout Actually Looks Like

Maintainer burnout in this context doesn't always look like dramatic exit announcements or angry mailing list posts (though those happen too). More often it looks like slower response times, longer gaps between releases, a gradual withdrawal from community engagement, and eventually a project that's technically still alive but effectively unmaintained.

That quiet neglect is arguably more dangerous than a maintainer who explicitly steps down. An abandoned project with a maintained appearance still gets downloaded. Dependencies on it still accumulate. Security vulnerabilities still go unfixed. The Log4Shell vulnerability in 2021 was a watershed moment partly because it illustrated how a project maintained by a small volunteer team could have a flaw that took months of global effort to fully address — not because the maintainers were careless, but because the scale of the dependency had long since outpaced the capacity of the people maintaining it.

For maintainers in this situation, the emotional weight is real. You built something because you loved it. Now it's a job you didn't apply for, don't get paid for, and can't easily quit without letting people down.

Strategies That Are Actually Working

The good news is that the open-source community has been developing practical responses to this problem, and some of them are gaining real traction.

Explicit sustainability frameworks. Projects like curl, Babel, and webpack have adopted explicit sustainability policies that communicate to users what the project can and cannot provide, what commercial use looks like, and how companies can contribute meaningfully. Making the implicit explicit — even just documenting that the project is maintained by volunteers with limited capacity — changes the conversation.

Tiered support models. Some projects have implemented support tiers where commercial users can pay for prioritized issue responses, security disclosures, or compatibility guarantees. This doesn't change the open-source license, but it creates a financial relationship that reflects the actual value exchange happening. Tidelift has built a business around aggregating this kind of arrangement across many projects.

Foundation alignment. Bringing a project under the umbrella of a foundation — the Linux Foundation, Apache, CNCF, or others — can provide governance structures, legal resources, and sometimes funding that individual maintainers can't access alone. It also distributes decision-making authority in ways that reduce single points of failure.

License adjustments. A small but growing number of projects have moved to licenses that are free for individual and non-commercial use but require commercial users to pay. HashiCorp's controversial move to BSL and Elasticsearch's shift away from Apache 2.0 generated significant backlash, but they also sparked genuine conversations about whether traditional open-source licenses serve maintainers' interests in a world where cloud providers can build businesses on open-source software without contributing back.

Simply asking. This sounds obvious, but many maintainers have found that directly and publicly asking corporate users for financial support — through GitHub Sponsors, Open Collective, or direct invoicing — produces results. Companies that genuinely depend on a project often have budget for this; they just haven't been asked in a way that made it feel necessary.

The Structural Problem Underneath

All of these strategies help at the margins, but they don't address the underlying structural issue: the open-source ecosystem has created enormous value by making it trivially easy to depend on other people's work, without creating any corresponding mechanism to compensate the people doing that work.

Fixing that probably requires action at multiple levels — from individual developers being more intentional about the sustainability of their dependencies, to companies building open-source contribution into their engineering culture and budgets, to foundations and industry groups developing better norms around commercial use of community software.

For maintainers navigating this right now, the most important thing might be the simplest: recognize what's happening early, before the weight of unacknowledged responsibility becomes crushing. Set explicit boundaries about what you will and won't support. Communicate clearly about the project's maintenance status. And don't feel obligated to subsidize corporate infrastructure on your own time and dime indefinitely.

You built something valuable. That's worth something. The open-source community is slowly, imperfectly, learning to say so out loud.