GitHub stars are not a metric

Somewhere in your last tooling debate, someone said "it has 40k stars" and the room nodded. This page is for the next time that happens.

A star is a bookmark with social features. It costs one click, expires never, and is handed out overwhelmingly during launch-week traffic spikes, which means star counts measure one thing with precision: how well a project's announcement performed on aggregator sites, years ago. Nothing about that number decays when maintainers burn out, when issues pile up unanswered, or when the last release was eleven months before your production incident.

What we actually count when a repo has to carry weight, in the ten minutes the star count was pretending to save:

1. Time-to-response on recent issues. Not resolution; response. It measures whether anyone is home.
2. Release cadence against the project's own stated rhythm. A quarterly project shipping quarterly is healthy. A weekly project silent for six months is news.
3. The bus factor, eyeballed: what share of recent commits came from one person, and does that person have an employer with a reason to keep paying them?
4. Open pull requests from outsiders, and their age. A wall of stale community PRs is a maintainer saying no politely.
5. The issue tracker's tone in the hard threads. Projects reveal their future in how they handle the bug they cannot fix this month.

None of this needs tooling. It is ten minutes of reading, which is why nobody does it: the star count is one glance, and it flatters whatever the room already wanted.

Skip the number. Read the repo. The repo has never once lied to us, and the stars, on our scorecard, have never once paid for a single 3 a.m. page.