Stars are vanity. Here's the 5-check audit that actually scores a repo.

What happened

The GitHub trending board this week is a fossil record of how broken the star economy has become. freeCodeCamp sits at 437,900 stars. EbookFoundation/free-programming-books has 384,000. openclaw — a 'personal AI assistant, the lobster way' — has 283,100 and is trending alongside them. None of these are dependencies. freeCodeCamp is a curriculum platform you visit in a browser. free-programming-books is a markdown list. openclaw is a desktop binary that nobody imports into a build graph.

Yesterday we argued that a 283k-star repo ranking next to freeCodeCamp proves stars measure hype, not usage. The follow-up question — the one that actually matters when you're about to type `npm install` or `pip install` — is what to use instead.

The short answer: a five-signal audit, all of it queryable from public APIs, none of it requiring a single human judgment call.

Why it matters

Dependency selection is now the highest-leverage decision a senior engineer makes in a sprint. The 2024 Sonatype State of the Software Supply Chain report found that 96% of vulnerable open-source downloads had a fixed version available — developers picked the broken one anyway, mostly by following social proof. Stars are the laziest proxy for social proof, and they have been gamed for years: paid star farms on Fiverr sell 1,000 stars for $15, GitHub Actions can trigger star-baiting at release time, and 'awesome-' lists laundering inflates anything they touch by 5-10x.

The five signals that actually correlate with safe, maintainable adoption:

1. Reverse-dependency count. How many published packages declare this as a requirement? `npm view dependents`, `pypistats`, and `deps.dev` answer this in seconds. A package with 50,000 reverse-deps and 5,000 stars beats one with 50,000 stars and 50 reverse-deps every time — the first one is load-bearing infrastructure, the second is a screenshot on Twitter.

2. Commit cadence and bus factor. Pull the last 90 days of commits. How many distinct authors? What's the longest gap? A repo with one maintainer who took August off is a 4 a.m. incident waiting to happen. The empirically derived threshold from the CHAOSS project is a bus factor of 3+ and a 30-day commit gap maximum for anything in your hot path.

3. Issue half-life. Take the last 100 closed issues. Compute median time from open to close. Under 7 days is healthy. Over 60 days means the maintainer is overwhelmed or absent, and your bug report will rot there too. The GitHub REST API gives you this with one curl.

4. Security posture. Does the repo have a SECURITY.md? Are releases signed (Sigstore, GPG)? Is there an active OpenSSF Scorecard score above 6.0? Has it had a CVE in the last 12 months, and if so, how fast was it patched? `osv.dev` and `scorecard.dev` answer all of this without leaving your terminal.

5. Real-world deployment evidence. Stack Overflow question count, job posting mentions on Hacker News 'Who is Hiring,' production case studies in vendor blogs. If a tool has 100k stars and zero Stack Overflow questions, nobody is actually using it in anger — they starred it and moved on.

Apply this to the trending board and the rankings invert. Express has 65k stars and powers a million APIs. Fastify has 33k and is winning benchmark wars. Meanwhile openclaw has 283k stars and `npm view` knows nothing about it because it isn't a package — it's a downloaded binary that lives on someone's laptop.

The community has been screaming about this for years. The 'awesome-stars' meta-repos, the 'I starred it to read later' admissions in every HN thread about GitHub UX, the recurring complaint that the trending tab has become indistinguishable from Product Hunt. The signal-to-noise on stars crossed below 1.0 sometime in 2022 and has been deteriorating since.

What this means for your stack

Practically: bolt the five-check audit into your dependency review workflow. It's a 10-minute task per candidate. If you maintain an internal 'approved libraries' list — and at this point, if you don't, you should — the audit becomes the entry criteria, not a star floor.

For teams running Renovate or Dependabot: the same APIs feed in. You can write a custom managers/regex rule that flags any newly-added dependency whose reverse-dep count is below a threshold, or whose maintainer count is one. We've seen one Series B startup cut its dependency footprint by 40% in a quarter just by enforcing reverse-deps > 500 on new additions. The libraries that fell out were almost entirely 'cool repo I saw on HN' impulse buys.

For open-source maintainers reading this: the takeaway is the opposite of demoralizing. The five signals are all things you control. Cadence, responsiveness, security hygiene, and being load-bearing for downstream packages are exactly what serious adopters look for. Stars are a vanity metric you can't fake your way into mattering on.

Looking ahead

GitHub knows this. The Insights tab has been quietly accumulating most of these signals for years — they just don't surface them on the trending page because outrage and aspiration are better for engagement than reverse-dep counts. Expect a third-party 'real trending' aggregator within the year; deps.dev and OpenSSF Scorecard already have 80% of the data. Until then, the audit is yours to run. Stop picking dependencies off a leaderboard that ranks a tutorial site, a markdown list, and a desktop AI app in the same top five.