open source · supply chain · maintainers
The open-source library holding up your stack might have one maintainer
Almost every application you run depends on open-source libraries, and those libraries depend on others, several layers deep. What is easy to forget is how many of those layers are maintained by one or two unpaid volunteers. When a project like that is critical and under-resourced, it becomes a single point of failure - for reliability and, as recent history shows, for security.
The picture xkcd got exactly right
In 2020, xkcd comic 2347, titled "Dependency", drew modern digital infrastructure as a precarious tower of blocks, with the whole structure resting on one small piece labelled as a project "some random person in Nebraska has been thanklessly maintaining since 2003". It became an instant classic among developers because it is not a joke so much as an accurate diagram. The dependency tree of a typical project really does narrow down, in places, to a single person's spare-time effort.
When the tower actually wobbled
These are not hypothetical risks. A few widely documented incidents make the pattern concrete:
- Heartbleed (2014). A serious flaw in OpenSSL, the library securing much of the web's HTTPS traffic, exposed memory that could leak keys and passwords. At the time, OpenSSL was maintained by a tiny group with minimal funding. The scare directly prompted industry funding efforts for critical open-source infrastructure.
- Log4Shell (December 2021). A critical remote-code-execution flaw in Log4j, a logging library embedded in countless Java applications, was rated the maximum severity. Log4j was maintained by a small team of volunteers, who then spent an exhausting period patching a problem that affected a huge share of enterprise software.
- The xz-utils backdoor (2024). This is the clearest warning of all. According to the public record (CVE-2024-3094, rated CVSS 10.0), a contributor using the name "Jia Tan" spent roughly two years building trust on the xz compression project, gaining commit and then release-manager rights, while the long-time solo maintainer, Lasse Collin, was under pressure and reportedly burned out. Malicious code was slipped into xz 5.6.0 and 5.6.1 that backdoored the library used by SSH on some Linux distributions. It was caught almost by accident, before wide deployment, by an engineer investigating why logins were slightly slow.
Why one maintainer is a structural risk
A single-maintainer project concentrates several risks in one place. If the maintainer loses interest, gets ill, or simply burns out, updates and security fixes stall - the "abandonware" problem. If they are overworked, pressure to hand over control creates an opening for a bad actor, which is exactly what the xz-utils case exploited. And because so many downstream projects pull the library in transitively, a problem at the root propagates to everything built on top, often without those downstream teams even knowing the dependency was there.
The uncomfortable truth is that open-source sustainability is an economic problem wearing a technical costume. The code is free; the human attention that keeps it safe is not, and it is frequently unpaid.
What teams can actually do
You cannot personally maintain every dependency, but you can stop treating them as free infrastructure that maintains itself:
- Know your dependency tree. Generate a software bill of materials (SBOM) so you actually know what you ship, including the transitive dependencies you never chose directly.
- Watch the bus factor. For the libraries you rely on most, check how many active maintainers there are. A critical dependency with one contributor is a risk to log, not to ignore.
- Pin and review updates. Pin versions and review changes rather than auto-pulling the latest release blindly; the xz backdoor arrived in a normal-looking release.
- Give back where it counts. Sponsoring, funding or contributing maintenance time to the projects you depend on is not charity - it is buying down your own risk. Industry funds and foundations now exist partly for this reason.
None of this removes the risk entirely, but it turns an invisible dependency into a managed one. The projects holding up your stack are worth knowing by name.
FAQ
Is open source less secure than closed source? Not inherently - open code can be audited by anyone, which is a genuine advantage. The risk discussed here is about resourcing and maintenance, not openness itself. Under-funded software of any kind is a risk.
What is the "bus factor"? It is the number of people who would have to be hit by a bus (or just leave) before a project is in serious trouble. A bus factor of one means a single person is the project.
What was the xz-utils backdoor? A deliberately planted backdoor (CVE-2024-3094) inserted by a contributor who had earned maintainer trust over time, caught in 2024 before it reached most production systems. It is the reference example of social-engineering a single-maintainer project.
How do I find single-maintainer dependencies? Start with an SBOM of your project, then look at the repositories of your most critical libraries: recent commit activity and the number of active maintainers tell you a lot.