Go count how many of your dependencies have one maintainer

Here’s an exercise that takes an hour and changes how you think about your stack.

Take your dependency lockfile — the real one, with transitive dependencies resolved. Count the entries. For a mid-size application in most modern ecosystems that number is somewhere between four hundred and fifteen hundred.

Now, for each one, answer: how many people committed to it in the last twelve months?

You will not finish. But you’ll get far enough to find twenty or thirty where the answer is one, and several where the answer is zero — the last release was three years ago, it works fine, and nothing has needed to change.

Those are not edge cases. They are load-bearing.

Zero is not automatically bad

I want to be careful here, because the standard version of this article treats “unmaintained” as a synonym for “dangerous” and that’s lazy.

A small, focused library that does one thing correctly and hasn’t needed a commit since 2021 is not neglected. It’s finished. Software can be finished. A left-pad-shaped function has no roadmap and needs no roadmap, and a maintainer who resists the urge to keep adding to it is doing better work than one who ships breaking changes quarterly to look active.

Commit frequency is a terrible proxy for health. It measures churn. Some of the best code in your tree hasn’t changed in a decade because it was right the first time.

What actually matters

Two questions, and neither is about commit graphs:

If this needed an urgent security fix tomorrow, who would write it? Not “could someone fork it” — everyone can fork everything, that’s not a plan. Who, specifically, has the context to make a correct fix under time pressure, and what’s their availability? For a lot of your tree the honest answer is one named individual with a day job, in a timezone you don’t share, who owes you nothing.

How much of your surface does it touch? A library that parses untrusted input, handles crypto, or does anything with deserialization is in a completely different risk class than one that formats dates. Rank by blast radius, not by download count.

Those two questions turn an unusable list of nine hundred packages into a usable list of maybe fifteen. That list is worth having and almost nobody has one.

The argument I lost

For years I argued the answer was fewer dependencies. Write it yourself. The standard library is right there. Every package you don’t add is a package that can’t betray you.

I still believe that for the trivial cases — if you’re pulling a package to check whether a number is even, the problem is you. But I’ve had to concede the general version, and here’s what changed my mind.

The alternative to a widely-used library with one maintainer is your own implementation with one maintainer, and that maintainer is going to leave your company in three years. The shared library has more eyes than your internal one, gets more fuzzing, gets CVEs filed against it by strangers, and has been run against inputs your test suite will never generate. Rolling your own crypto is the famous case, but it’s true far past crypto — date/time handling, character encoding, URL parsing, anything with a specification longer than a page.

“Write it yourself” trades a dependency risk you can see for a maintenance risk you’ll stop being able to see the moment the person who wrote it moves on. That’s usually a worse trade, and I spent too long insisting otherwise.

What to actually do

Inventory the fifteen. Blast radius × bus factor. One page. Review it twice a year. This is the entire exercise and it’s worth more than any scanner you can buy.

Vendor the critical ones. Not as a permanent fork — as a checked-in copy you can patch on an afternoon’s notice without waiting for an upstream release, a maintainer’s availability, or a registry to be up. The cost is having to re-apply your diff on upgrades. The benefit is that “upstream is unreachable and we need a fix today” stops being an outage.

Fund the ones you can name. Not as charity, as risk reduction — it’s cheaper than the incident, and it buys the thing that actually helps, which is a second maintainer. A project with three active people is dramatically harder to abandon, and harder to socially engineer, than a project with one exhausted person.

Stop adding dependencies you haven’t read. Not all of them — read the ones handling untrusted input. If a package is small enough that reading it is feasible and you can’t be bothered, you’ve learned something about how much you actually needed it.

The uncomfortable arithmetic

Your organisation has a vendor management process. It has security reviews, contract terms, SLAs, and someone whose job is to escalate when a supplier misses one.

It also has nine hundred software suppliers with no contract, no SLA, no contact, and no obligation to you whatsoever. Most of them are one person. You have never sent any of them a cent, and the process that governs adding another one is a developer typing an install command.

That’s the actual supply chain. Everything else is documentation about it.