The Open Source Debt Nobody Talks About

Pick any production software system built in the last fifteen years. Pull up its dependency tree. Count the packages. In a typical web application you will find somewhere between two hundred and two thousand distinct pieces of software your system depends on to function.

Now ask a harder question: how many of those packages are maintained by a single person, working in their spare time, for free?

The answer, for most systems, is a significant fraction. Not the big-name packages at the top of the dependency tree. Those tend to have corporate backing or large contributor communities. The packages in the middle and the bottom of the tree, the ones that do one specific thing and do it quietly and reliably, those are often maintained by one person who built them because they needed them, published them because someone else might too, and has been keeping them working ever since through a sense of obligation that was never formally agreed to.

This is the open source debt. Not technical debt in the code. The debt the software industry owes to the people it has built its entire infrastructure on while systematically failing to support them.

What the stack actually rests on

The famous parable in open source is the XKCD comic from 2020 about a critical piece of internet infrastructure maintained by a random person in Nebraska. It was funny when it was published. It is a documentary now.

The Log4Shell vulnerability in late 2021 demonstrated this at scale. A critical security flaw in a Java logging library called Log4j, used by hundreds of millions of systems worldwide, required emergency patching across virtually every organisation with a Java application. The library was maintained by a small number of volunteers at the Apache Software Foundation. The organisations scrambling to patch it had collectively contributed almost nothing to its development or maintenance. They had taken the work for free and were now dependent on the same unpaid volunteers to fix it at emergency speed.

Yan Cui, a developer and writer, calculated at the time that if Log4j were a commercial product and the organisations using it paid a reasonable licensing fee proportional to their usage, the project would be funded to the tune of hundreds of millions of dollars per year. Instead the maintainers were working evenings and weekends, absorbing the stress and the criticism of a global emergency, for free.

This is not an isolated example. It is the normal operating condition of the open source ecosystem. Most of the software most production systems depend on is maintained by people who are not compensated for the work, who maintain it alongside full-time jobs, who cannot scale their effort when security issues require rapid response, and who have no obligation to continue when the work becomes too much.

The maintainer who burned out last Tuesday

The open source ecosystem loses maintainers constantly and quietly. There is rarely an announcement. The project simply stops. Issues go unanswered. Pull requests sit unreviewed. Security vulnerabilities remain unpatched. The last commit was fourteen months ago.

Sometimes the maintainer posts a note explaining what happened. These notes are worth reading because they tell a consistent story.

The work expanded beyond what one person could manage. The expectation of users grew while the support did not. Issues arrived from people who were frustrated that free software they depended on was not working the way they needed it to, and the frustration was directed at the person maintaining it as if they had a professional obligation to fix it immediately. The maintainer absorbed months or years of this before reaching the point where the cost to their health and their other relationships was no longer worth it.

What happened then? In the best cases, another developer stepped in. The project was forked or transferred. The work continued. In many cases it did not. The package exists. It is still in use. Nobody is maintaining it.

The organisations that depend on it have no idea this has happened. Their dependency audit shows the package as a dependency. They assume someone is in charge of it. They will discover that assumption is wrong when a security vulnerability is disclosed and there is nobody to fix it.

Why companies do not pay

The economics of open source dependency are strange. A company pays significant amounts for cloud hosting, for SaaS tools, for commercial software licences. The same company pays nothing for open source packages it depends on just as critically as the commercial tools.

Part of this is structural. Open source software does not come with an invoice. There is no sales process, no renewal negotiation, no account manager following up. The friction of paying is entirely on the payer, and most organisations are not set up to proactively send money to individuals or small foundations without a formal commercial relationship.

Part of it is the free rider problem. Every company that does not pay benefits from the companies that do, and every company knows this, which creates a race to the bottom where the rational individual choice is to not pay and the collective outcome is a chronically underfunded ecosystem.

Part of it is that the dependency is invisible. The engineering team knows about it. The finance team does not. The security team does not. The people who make budget decisions do not have a clear picture of what the organisation’s software infrastructure actually depends on at the level of specific maintained packages, so they cannot make rational decisions about supporting those packages.

And part of it is that companies have become very good at treating open source as infrastructure in the way that roads are infrastructure: something that exists, that they benefit from, and that they feel no particular responsibility for maintaining. The road analogy breaks down immediately, because roads are maintained by governments with tax revenue, while open source packages are maintained by individuals with goodwill.

What a serious response looks like

There are companies that take this seriously. They are not the majority but they exist and they provide a model.

Some allocate engineering time to contributing to open source projects the company depends on. Not to the high-profile projects where a contribution generates good press. To the projects in the middle of the dependency tree that need the most help and receive the least attention. The engineers who do this work are doing something that benefits the company directly: the packages they contribute to are better maintained, more secure, and more likely to continue existing.

Some contribute financially through platforms like GitHub Sponsors, Open Collective, or the Open Source Pledge. The amounts required to make a meaningful difference to an individual maintainer are small relative to typical software budgets. A maintainer who is receiving two thousand dollars a month from a collection of companies using their work is a maintainer who can spend time on the project rather than spending evenings doing it after their real job.

The Open Source Security Foundation, formed after a series of high- profile supply chain attacks, provides a framework for companies to pool resources for security auditing of critical infrastructure. This is a more structural response than individual donations. It addresses the collective action problem by creating an institution that aggregates the contributions.

None of these are adequate to the scale of the problem. They are better than nothing.

The supply chain risk hiding in the dependency tree

Security teams in most organisations have become sophisticated about certain kinds of supply chain risk. They track CVEs. They run dependency scanners. They have processes for emergency patching when critical vulnerabilities are disclosed.

What they do not systematically track is maintainer health. Whether the package has active maintainers. Whether the response time to issues has increased. Whether the project has shown signs of being abandoned. Whether the organisation’s contribution to the project’s sustainability is proportional to its dependence on the project.

This is a meaningful gap. A package with a known CVE and an active maintainer is a risk that can be managed. A package with an unknown future CVE and no active maintainer is a risk that cannot be managed after the fact. By the time the vulnerability is disclosed, the organisation’s options are limited and expensive. Questions a security-conscious organisation should be asking about their open source dependencies, but mostly is not: For each critical dependency:

Who maintains this? Name, not just project name. A person or a foundation with resources. Not “the community”, which is not an answer. How active is maintenance? Last commit. Last security update. Response time to issues. Open issues count and trend. These are observable signals of maintainer engagement. What happens if maintenance stops? Is there an alternative? Can the organisation maintain it internally if needed? Is there a commercial fork with support? Not having an answer to this question is a risk position. What is our contribution to its continued existence? Financial sponsorship? Engineering contributions? Nothing? “Nothing” is a legitimate answer but it should be a deliberate choice, not an omission. If this package disappeared tomorrow, what would break and how quickly could we recover? This question makes the dependency concrete in a way that abstract discussions about open source health do not.

The engineers who maintain things you use

There is a person, probably several people, who have written and maintained software that runs in your production system right now. They have fixed bugs you encountered without knowing they were there. They have reviewed security reports and released patches on evenings they would rather have spent differently. They have answered questions from users who were frustrated that free software did not work exactly the way they wanted.

Most of them have never heard of the company their software is running in. They have no relationship with the engineering team that integrated their work. The only signals they receive from the organisations depending on them are bug reports and feature requests, which arrive as demands, rarely as thanks.

This is not sustainable and it is not sustainable in a way that is eventually going to cause expensive problems for the organisations that have built on this foundation without examining it.

The examination is not complicated. A dependency audit that includes maintainer health rather than just version currency. A budget line for open source sustainability that is proportional to the value extracted. An engineering contribution policy that allocates time to the projects in the dependency tree that need it most. These are not large investments relative to what most engineering organisations spend on commercial software.

They are also investments with a direct return. A maintained package is more secure than an abandoned one. A maintainer who is compensated is more likely to continue than one who is not. A dependency tree that is actively supported is a dependency tree that will not produce a Log4Shell-scale emergency on a Friday afternoon.

The debt is real. It is owed to specific people doing specific work. It is not discharged by using the software for free and being grateful in the abstract.

Pay it, or be prepared for what happens when the people it is owed to decide they have given enough.