Software maintains the world.
Not just apps you click on every day — but the unseen layers beneath them: libraries, modules, tools, and frameworks that have become foundational.
Yet in many cases, the people keeping this code alive are one person or a tiny team. That dynamic looks paradoxical: global systems depending on a handful of maintainers.
But it is the reality of how modern software scales.
Small Teams Under Big Pressure
When open source projects first start, they solve a specific problem. A developer writes code that makes their life easier. They publish it.
Other people begin to use it.
And use it.
And use it.
Eventually, the project becomes critical: part of clusters of libraries used in enterprise apps, infrastructure tooling, cloud stacks, and embedded systems.
But the ownership rarely changes.
The original maintainer — often a volunteer, a hobbyist, or an engineer with a day job — ends up with responsibilities that extend far beyond the project’s original scope.
They review pull requests. They triage bugs. They respond to security reports. They try to keep dependencies up to date.
Meanwhile, thousands of downstream projects integrate that code as if it were backed by a dedicated engineering team.
This imbalance was visible during crises like Log4Shell and the Myth of Mature Infrastructure. A fundamental logging library exposed massive infrastructure risk — and the people responsible for it suddenly found themselves at the center of global patching efforts.
Invisible Workload, Visible Impact
Maintainers often do this work quietly.
They:
- review contributions from strangers
- arbitrate design decisions without formal governance
- update documentation
- field questions about compatibility
- juggle multiple versions used across ecosystems
Yet compensation rarely matches the economic value built on top of their code.
The infrastructure supported by this code spans industries: cloud computing, enterprise software, IoT, financial systems, and consumer applications. But support for the code itself rarely scales with its impact.
This dynamic becomes especially striking when we juxtapose it with what happens at the platform level. Massive companies can absorb failure gracefully — as we explored in The Day Facebook Went Offline: A Case Study in Centralization — because they control resources, teams, and infrastructure.
Maintainers at the open source layer have none of that luxury.
The Unseen Dependency Tree
Modern applications — even small ones — depend on a forest of packages.
A library may import five others. Each of those imports ten more. And so on.
By the time code reaches production, it carries an entire dependency ecosystem.
At the leaves of that tree, critical infrastructure code may be maintained by one person. That person might be juggling personal commitments, professional work, or even mental health challenges — all while supporting code that forms the backbone of services used by millions.
The contrast between distributed usage and concentrated maintenance creates a form of hidden concentration risk.
Funding Gaps and Sustainability
Why does this situation persist?
Partly because of expectations.
In the open source model, code is free. But “free” often becomes shorthand for “no funding required.”
Organizations happily integrate dependencies, but few contribute back proportional to their usage. Many companies run countless instances of open source stacks without sponsoring maintainers or contributing patches upstream.
The outcome is a governance gap: critical software maintained by under-resourced people, relied on by well-funded companies.
That gap matters most when things break — or when vulnerabilities emerge.
When Maturity Doesn’t Mean Safety
Libraries with widespread adoption are sometimes trusted implicitly. They are considered “mature.” But maturity in software can mean only one thing: many people use it.
Mature does not always mean audited. Mature does not always mean funded. Mature does not always mean secure.
We saw that starkly in Log4Shell and the Myth of Mature Infrastructure. Widespread adoption made the vulnerability systemic, even though the component had sat unexamined for years.
Maturity is often conflated with stability — but the two are separate.
The Social Layer of Software
Open source is not just code.
It is a social ecosystem.
Bits of code represent discussions, disagreements, compromises, and choices. They reflect the lives of people — rarely homogeneous, often distributed, and sometimes overextended.
Maintainers represent both technical expertise and human limitations.
Sustainability requires recognizing that open source success depends on their work — and then asking whether our systems, tools, and organizations invest adequately in that work.
The Next Frontier in Infrastructure Risk
Understanding that critical software can be maintained by one person changes how we think about risk.
Systemic risk is not just about outages or vulnerabilities. It’s about concentration of responsibility.
If global platforms create dependence through integration, open source creates dependence through adoption without proportional support.
When those maintainers face burnout, withdraw, or cannot respond to threats quickly, the dependency becomes visible — often too late.
The internet feels resilient because many layers rarely fail.
But resilience has human roots.
And behind many of them is one person holding it together.