DEV Community

ke jia
ke jia

Posted on

What 12 Active Days in 90 Told Me About the Library We Almost Adopted

#git #cli #devops #javascript

We were 48 hours from adopting a logging library. It had the right API, good docs, a healthy star count, and a maintainer who answered issues within a day. Everything looked fine.

Then I ran the 30-second check, and the number that stopped me was the one nobody talks about: 12 active days in the last 90.

  Total commits:   312
  Contributors:    5
  Active days:     12
  Files touched:   87

  Recent Activity
    2026-08-30  ######## 4
    2026-08-12  ###### 3
    2026-07-22  #### 2
    2026-06-15  ##### 3
    ...
Enter fullscreen mode Exit fullscreen mode

12 days with a commit, spread across the quarter, in clusters of 2-4 commits. The star count was a monument to the past. The activity graph was a heartbeat monitor, and the heartbeat was a resting one.

Why stars lie (politely)

Stars are cumulative. They measure the peak of interest, which for most libraries is a launch blog post, a conference talk, or a "top 10" list — and they decay none of it. A library can have 8,000 stars and not have had a commit in two years. The stars are true; they're just true about 2019.

Active days is the opposite metric. It's a rate, not a sum. It answers the question that actually matters for a dependency: is someone at the keyboard right now? Because a dependency you adopt is a bet that someone will be at the keyboard when the thing breaks — when Node ships a breaking change, when a transitive dep yanks a version, when your team hits the edge case at 5pm on a Friday.

12 active days in 90 isn't "abandoned." It's "maintained in maintenance mode." The distinction matters: an abandoned library has zero days. A 12-days-in-90 library has a maintainer who lands a fix when poked, triages issues on a slow cycle, and will not be refactoring the core for you this year.

The decision we made

We didn't adopt it. Not because the library was bad — the code was clean and the API was genuinely good — but because the maintenance cadence didn't match our risk:

  1. We would be depending on a slow cycle. Our stack moves weekly. A dependency that moves quarterly means we absorb every ecosystem shift (Node releases, security patches in transitive deps) on our own, with a library that can't keep up.
  2. The "answers issues within a day" was triage, not velocity. Reading the issue history, the maintainer was responsive but the commits were sparse. Responsiveness to issues and responsiveness to the ecosystem are different things; the activity graph measures the second.
  3. Five contributors, one with 70%. The contributor graph showed a bus factor of ~1.5. The 12 active days were mostly one person's.

We picked a library with 40 active days in 90, fewer stars, and a commit cadence that matched ours. It was the right call — three months later, the ecosystem moved (a breaking change in a shared dependency) and the active library shipped a compatible release in a week. The 12-day library's issue about it sat open for three weeks.

How I check now

Before any dependency decision, the check is in the pre-flight list:

git clone --depth 200 <repo> /tmp/check && npx @wuchunjie/gitpulse /tmp/check
Enter fullscreen mode Exit fullscreen mode

Three numbers I read, in order:

  1. Active days in the last 90 — is it alive at a cadence I can depend on?
  2. Contributor concentration — if the top name disappeared, does the repo stop?
  3. Recent activity shape — clusters (spurts) or steady (daily)? A steady pattern is a stronger maintenance signal than the same total.

The tool is gitpulse — zero dependencies, runs against the local clone, nothing uploaded. The whole check, clone included, is under two minutes for a small repo.

The meta-lesson

We almost made a dependency decision on a reputation metric (stars, docs, response time) instead of a maintenance metric (active days, contributor spread). Reputation describes the past. Maintenance describes the present, and the present is what you're actually depending on.

Run the pulse before you sign the contract. It costs two minutes, and it told us the truth the star count was too polite to say.

npx @wuchunjie/gitpulse
Enter fullscreen mode Exit fullscreen mode

More Tools

Tool What it does Command
scaffoldx-cli Production-ready project templates in seconds npx scaffoldx-cli
dotguard Scan .env files for exposed secrets npx @wuchunjie/dotguard
gitpulse Git repo analytics in your terminal npx @wuchunjie/gitpulse
snippetx Terminal code snippet manager npx @wuchunjie/snippetx

If these save you time, consider buying me a coffee. All tools are MIT-licensed, zero-dependency, and run fully offline.

Top comments (0)