GitHub Trending Is Survivorship Bias With a Star Counter

What happened

GitHub's trending surface today reads like a museum guide. freeCodeCamp's curriculum repo sits at 437,900 stars. Kamran Ahmed's developer-roadmap clocks 350,500. A relatively new project called openclaw — a cross-platform personal AI assistant whose tagline is, deadpan, "The lobster way 🦞" — is up to 283,100. A combined 1.07 million stars across three repositories that have approximately zero technical, organizational, or product overlap.

One is a non-profit teaching JavaScript to beginners. One is a directory of PNG roadmaps maintained by a single person plus contributors. One is an Electron-style AI assistant wrapper. The only thing GitHub's algorithm sees they share is that a lot of humans have clicked a star icon next to them recently.

This is the trending tab's recurring trick: it conflates "famous" with "momentum" and ships the result to your homepage as if it were a recommendation.

Why it matters

Star count is the most abused metric in our industry, and it's abused because it's the only one GitHub puts in 24-point font. The trending tab inherits that distortion and compounds it. Repos that already have hundreds of thousands of stars get more stars because they appear on trending; they appear on trending because they got more stars. It's a recommender loop with no grounding in whether the code is alive, maintained, or used in production.

Compare three honest signals you could use instead. Commits in the last 30 days: freeCodeCamp logs dozens daily because it's a working CMS for the curriculum; developer-roadmap commits are sporadic because it's primarily SVG diagrams; a hot new tool should be in the hundreds. Contributors in the last 90 days: a healthy infra project (Postgres, Tokio, Kubernetes) routinely hits triple digits; a vanity-star repo will show single digits no matter the star count. Releases per quarter: anything load-bearing in production ships patches; abandoned star-magnets do not.

Look at what isn't on trending and you see the inversion. The actual workhorses of modern software — postgres/postgres (~17k stars), tokio-rs/tokio (~28k), psf/requests (~52k) — sit far below the freeCodeCamps and awesome-lists of the world despite being installed billions of times. Stars correlate with the size of the audience that recognizes the name, not with how many production systems would break if the repo disappeared tomorrow.

The community has known this for years. Evan You has griped about it. Substrate Sasha Levin has written about Linux kernel contributors who'll never crack 1k stars. Even GitHub's own staff engineers have acknowledged the dynamic in conference talks. Nothing changes because stars are the easiest thing to count, and "trending" makes for a sticky tab.

openclaw is the cleanest example in today's batch. A 283k-star "personal AI assistant" with a crustacean mascot and a slogan that reads like a joke. Maybe it's great. Maybe it's a wrapper around llama.cpp with a nice installer. The star count tells you literally nothing about which. What would tell you: how many issues are open vs. closed, who's filing them, whether the maintainer responds to security reports, whether there's a CHANGELOG, whether `npm install` or the binary actually works on the OS you run.

What this means for your stack

If you're evaluating dependencies, retire stars from your shortlist. Replace the star check with a four-line checklist: last commit within 30 days, more than five contributors in the last quarter, a release within 90 days, and a download trend that isn't collapsing on npm/PyPI/crates.io.

The download-trend piece is the most underused. `npm-stat` and `pypistats` will tell you whether real installs are climbing or in freefall — a much better lagging indicator of "people are actually using this" than stars, which mostly measure "people heard about this on Hacker News." For Go and Rust, deps.dev and lib.rs publish reverse-dependency counts; a library with 500 dependents is load-bearing whether or not it ever hits trending.

For educational content specifically — the freeCodeCamp/developer-roadmap category — the right signal is recency of curriculum updates, not stars accumulated since 2014. A roadmap repo with 350k stars but a last-substantive-update of 18 months ago is teaching you the 2024 stack in 2026. Cross-check the README's "last updated" claim against the actual diff history. The half-life of a frontend recommendation is shorter than the half-life of a star.

For AI-assistant-style projects (openclaw, and the dozens like it), demand a benchmark before a star count. Does it run locally? What's the latency? Which models? What's the memory floor? "283k stars" answers none of those.

Looking ahead

GitHub won't fix trending because trending isn't broken from GitHub's perspective — it drives engagement, which is the only metric the surface actually optimizes for. The fix has to come from us. Build the habit of opening Insights → Contributors before opening the README. Treat star counts the way you treat LinkedIn follower counts: a measure of reach, not of substance. And when you see three unrelated mega-repos bundled together on the trending tab, read it as what it is — an artifact of the algorithm, not a signal about what's worth your afternoon.