Most software is not built on software.
It is built on people maintaining software.
That distinction is easy to miss because everything appears stable on the surface. Packages install. Dependencies resolve. Systems run. From the outside, it looks like infrastructure. But underneath, much of it depends on a small number of individuals quietly keeping things alive.
Open source made modern software possible, but it also introduced a kind of structural assumption: that critical parts of the ecosystem will continue to be maintained indefinitely, often without direct compensation or formal responsibility.
That assumption is rarely examined until it breaks.
There have been enough incidents over the years to make the pattern visible. A widely used library changes hands, a maintainer steps away, or a project becomes unexpectedly central to systems far beyond what its original author ever intended.
The left pad incident is often cited as an early example of how fragile this dependency chain can be.
What matters is not the scale of any individual event, but what it reveals about how software is assembled. Large systems often depend on extremely small components maintained by very few people, sometimes with very little formal support.
We tend to treat this as an operational detail rather than a structural one.
There is also a quieter dynamic at play. The more successful open source becomes, the more invisible the maintenance burden becomes. Usage scales faster than support, and responsibility becomes distributed in ways that are not always intentional.
It creates a situation where critical infrastructure depends on goodwill, interest, and personal capacity.
That works surprisingly well until it doesn’t.
From a product perspective, this is an unusual inversion. Most systems assume that critical dependencies are either owned internally or contracted formally. In open source ecosystems, critical dependencies are often neither.
They exist in a space between voluntary contribution and systemic reliance.
The interesting question is not whether this model is good or bad. It is that it quietly assumes stability in places where stability is not guaranteed.
And because it usually works, it becomes easy to forget that it is fragile at all.
Software inherits this pattern without always acknowledging it. Systems are designed as if dependencies are stable, even when their stability depends entirely on human continuity rather than technical design.
Which means fragility is not an exception in these systems.
It is a structural property.