The OSS dependency that was unmaintained for two years before we noticed

A production service at a client’s shop had a dependency whose last commit was 2019. The library worked fine — no CVEs, no errors, no alerts. It just hadn’t been touched in four years.

We noticed when a Node.js LTS upgrade broke it. The library used an API that had been deprecated in Node 16 and removed in Node 18. It had been in the codebase for so long nobody remembered putting it there.

The maintainer’s last activity on GitHub was a comment in 2021: “I don’t have time for this project anymore. PRs welcome.”

Nobody had seen that comment.

The two failure modes of OSS dependency monitoring

The first failure mode is the obvious one: a CVE drops and you don’t know you’re vulnerable. This is what Dependabot, Snyk, and GitHub’s built-in security alerts handle. They’re good at it.

The second failure mode is quieter: a library you depend on slowly stops being maintained. No CVE, no alert, no drama. The maintainer just moves on. You’re fine until you’re not — until a language runtime upgrade, a security audit, or a compliance review reveals that you’ve been building on something abandoned.

This second mode is what no one monitors. It’s a supply chain risk, not a vulnerability.

What “unmaintained” looks like

A library can be functionally broken before you notice:

• The maintainer’s commit cadence drops from weekly to monthly to yearly to never
• PRs accumulate without review — a dozen reasonable ones that would have fixed things
• Issues go unanswered until contributors give up asking
• A new major version of a runtime changes something, and the library can’t follow
• A fork appears on GitHub with better support — but the original is still in your lock file

None of these produce a CVE. None trigger a Dependabot alert. Your CI still goes green. Everything looks fine.

The signals that exist but nobody watches

GitHub’s API surfaces most of what you’d want to know:

• Days since last commit
• Number of open PRs without response
• Maintainer count (how many people can push)
• License (has it changed?)
• Last release date vs last commit date

These are all public, all accessible, and almost nobody is systematically watching them for their dependencies.

What I built

I built OSS Pulse to watch these signals. For each repo in your watchlist:

• Weekly check on commit activity, open issue response time, maintainer count
• Health score (0–100) based on these signals
• Alert if the score drops significantly week-over-week
• Immediate alert if a CVE is found
• License change detection

One email per week if anything’s worth knowing about. No email if nothing changed.

The use case isn’t replacing Dependabot or Snyk. It’s the thing that sits alongside them and watches for the slower-moving supply chain risk — the library that’s about to go dark, or already has.

The Node 18 incident cost two days: one to diagnose, one to find and vet an alternative library, one to ship the fix. The library had 40,000 weekly downloads on npm. Every team using it was in the same position. Most of them probably still are.

OSS Pulse free tier is 10 repos, no credit card. Start with the libraries you’d be most surprised to find abandoned.