The Invisible Workforce: Software Maintenance and the Infrastructure Nobody Wants to Fund

In February 2024, a critical vulnerability was discovered in XZ Utils, a compression library embedded in countless Linux distributions. The story attracted significant attention because of its sophistication—a patient, multi-year social engineering campaign that nearly succeeded in inserting a backdoor into the SSH authentication chain of systems running across hospitals, financial institutions, and government networks. What attracted considerably less attention was the underlying condition that made the attack possible: the library was maintained, essentially alone, by a single developer who had been sustaining it for years under mounting pressure and with no institutional support.

This is not an anomaly. It is a representative sample.

The Prestige Economy of Software

Software development has always operated within a prestige economy, and that economy has a clear hierarchy. At the top sit the builders—the engineers shipping new products, founding startups, and accumulating the kind of résumé entries that command attention at recruiting events and on LinkedIn. At the bottom, performing work that is structurally undervalued and culturally invisible, sit the maintainers: the developers patching decade-old codebases, updating dependency chains, writing regression tests for functionality that has not changed since a different president was in office.

Venture capital, which has functioned as the primary funding mechanism for software development in the United States over the past two decades, is constitutionally uninterested in maintenance. The investment thesis of the VC model requires growth—rapid, demonstrable, preferably exponential. Maintenance produces none of these outcomes. It produces stability, reliability, and the absence of catastrophic failure, none of which generate the kind of returns that justify a fund's existence. The result is a systematic underfunding of the work that keeps existing systems operational.

This is not a criticism of individual investors or firms. It is an observation about structural incentives. When the financial architecture of an industry rewards novelty and penalizes longevity, the industry will orient itself toward novelty. The software industry has done exactly that, and the consequences are accumulating in the places where nobody is looking.

What Maintenance Actually Involves

It is worth being specific about what software maintenance means in practice, because the word tends to evoke images of minor bug fixes and UI polish. The reality is considerably more demanding.

Maintaining a production system of meaningful scale involves tracking and applying security patches across a dependency tree that may contain hundreds of third-party libraries, each with its own release cadence and vulnerability disclosure process. It involves ensuring compatibility with evolving operating system versions, hardware architectures, and regulatory requirements. It involves writing and updating documentation that allows other engineers to understand systems they did not build. It involves responding to incidents at hours that are incompatible with work-life balance, performing forensic analysis on failures that may have no obvious cause, and making conservative decisions under pressure when the alternative is extended downtime.

None of this work produces a launch announcement. None of it generates a product demo. In the current environment, very little of it generates a promotion.

The Cascading Failure Pattern

The maintenance deficit does not announce itself. It accumulates over years, invisible to anyone not actively monitoring the systems in question, until a triggering event converts latent instability into visible failure. The pattern is consistent enough that it has a recognizable shape.

A system is built, performs adequately, and is declared complete. The team that built it disperses—some members move to new projects, others leave the organization. Maintenance responsibility is assigned to whoever is available, typically without the context, documentation, or institutional knowledge that would make the assignment meaningful. Dependency updates are deferred because they carry risk and offer no visible reward. Security patches are applied inconsistently. Technical debt accumulates in silence.

Then something changes in the environment—a new operating system version, a breaking change in a dependency, a newly discovered vulnerability—and the system fails in a way that nobody fully understands, because the people who understood it are gone. The remediation effort is expensive, disruptive, and frequently incomplete, because the organization has no established process for the work and no allocated resources for it.

This pattern is playing out across American infrastructure with a regularity that should be alarming. The 2021 outage at the Social Security Administration's legacy COBOL systems, ongoing maintenance struggles within the IRS's decades-old filing infrastructure, and repeated failures in state unemployment systems during the COVID-19 pandemic all reflect variations of the same underlying condition: critical software running on foundations that nobody has been adequately resourced to maintain.

The Open Source Dimension

The maintenance problem is particularly acute within the open source ecosystem, which provides the foundational components for an extraordinary proportion of commercial and governmental software. The Log4Shell vulnerability, disclosed in late 2021, affected a logging library that was downloaded hundreds of millions of times and embedded in systems operated by organizations ranging from Apple to the United States federal government. The library was maintained by a small group of volunteers.

The economics here are straightforward and uncomfortable. Large enterprises extract enormous value from open source software while contributing, on average, very little to its maintenance. The organizations with the greatest financial capacity to fund maintenance are frequently the ones least motivated to do so, because the benefits of that investment accrue to competitors as readily as to themselves. The result is a commons problem of considerable scale, one that the open source community has recognized for years without arriving at a durable solution.

Toward a Different Accounting

Addressing the maintenance deficit would require changes that cut against the grain of how the software industry currently operates. It would require organizations to treat maintenance as a first-class engineering function with dedicated headcount, explicit career paths, and recognition structures that do not penalize practitioners for choosing unglamorous work. It would require the investment community to develop instruments capable of funding operational sustainability rather than growth alone. It would require government procurement processes that account for long-term maintenance costs rather than optimizing for initial development price.

None of these changes are technically difficult. They are culturally and financially difficult, which in practice means they are unlikely to occur absent a sufficiently visible failure that makes the status quo untenable.

The software industry has built remarkable things. It has built them on foundations that it is not maintaining. The question worth asking is not whether those foundations will show strain—they already are. The question is whether the industry will choose to address the deficit deliberately, or wait to be forced into it by the kind of cascading failure that tends to concentrate the mind wonderfully.