GitHub trending is broken, and your star count is the proof

What happened

GitHub's trending page this week surfaces three repos with star counts that, taken together, tell you exactly how useless the metric has become. freeCodeCamp sits at 437.9k stars — a 12-year-old curriculum with thousands of contributors and millions of learners. public-apis sits at 411.9k — a markdown list. And openclaw, a self-described 'personal AI assistant, the lobster way 🦞' that surfaces almost no commit history and reads like a Claude Code knockoff, sits at 283.1k.

Three repos, one trending page, and the only thing they share is a number that has stopped meaning what developers think it means. freeCodeCamp earned its stars one bookmark at a time over a decade. public-apis earned its stars by being the link everyone shares when a junior asks 'where do I find a free weather API.' openclaw earned its stars in a way that, at minimum, deserves an asterisk: gray-market star panels, coordinated promotional drops, or both.

This isn't a new problem. Dagster's 2023 analysis flagged star-farming services openly advertising on Telegram. GitHub's own trust-and-safety team has [purged star rings before](https://github.blog) — including a high-profile takedown in 2024 that wiped millions of stars across hundreds of repos. The arms race continues because the incentive structure hasn't changed.

Why it matters

Stars were always a weak proxy. They measure 'I might want to find this again' more than 'I use this in production.' But the proxy used to be roughly directionally correct: at a given moment in time, a repo with 10× the stars of another repo in the same niche was probably more popular. That directional correctness is what's eroding, and once a signal stops being directionally correct, it's worse than no signal at all — because people still trust it.

The economics now favor inflation. A typical gray-market star panel quotes between $3 and $8 per 1,000 stars from real-looking accounts with commit history, profile photos, and contribution graphs designed to survive GitHub's heuristic sweeps. At $0.005 a star, getting onto trending in a competitive language tag costs a few hundred dollars; pushing past 100k stars costs less than a single conference booth. Compare that to the cost of building an actual community, and the ROI calculation writes itself for anyone willing to cheat.

The second-order effect is more interesting than the inflation itself. VC associates use stars in dealflow filters. Engineering managers screen libraries by 'minimum 1k stars' policies. Cloud vendors negotiate marketplace placement using star counts as proof of demand. None of these workflows have an obvious fallback, which is why everyone keeps pretending the metric works.

Community reactions split along predictable lines. The 'GitHub should do more' camp wants automated detection: behavioral fingerprints, account-age weighting, anti-Sybil checks similar to what npm did for download counts in 2018. The 'this is unfixable' camp points out that any detectable heuristic becomes a target for the next generation of farms, and that the underlying problem is using a single scalar to compress a multidimensional question.

The right read is that stars belong in the same bucket as Twitter follower counts and Medium claps — a vanity metric that occasionally correlates with quality but should never gate a decision.

What this means for your stack

If you maintain a dependency evaluation process — formal or informal — replace the star check with a small basket of signals that are harder to fake. Commit cadence over the last 90 days tells you whether the project is alive. Distinct contributor count over the last 12 months tells you whether it's a bus-factor-of-one. Issue close rate tells you whether maintainers are engaged. Downstream import counts from ecosystem.ms or libraries.io tell you whether real software depends on it. None of these are perfect, but a forger has to fake all four convincingly, and the cost curve gets steep fast.

For anyone shipping an open-source project, the implication cuts the other way: stop optimizing for stars. The marginal hour spent on a launch HN post, a clean README hero image, or a useful 'awesome-X' inclusion does more for actual adoption than any star pump. The repos with sticky users — Postgres, ffmpeg, sqlite — have unremarkable star counts relative to their utility. Nobody picks Postgres because of its 14k stars.

For VC and corp-dev workflows, the practical move is to weight stars at zero in any model where dependency choice is the outcome, and to treat 'unexplained star spike' as a yellow flag rather than a green one. A repo that went from 1k to 100k in 60 days without a corresponding GitHub Issues, PR, or HN-visible event is almost always astroturf, and the diligence cost of confirming this is roughly one Grep.

Looking ahead

GitHub will keep purging the worst offenders, the farms will keep adapting, and the metric will keep degrading. The most likely endpoint is a quiet bifurcation: serious engineers will stop quoting star counts the way serious investors stopped quoting Klout scores around 2014, and stars will live on as a marketing artifact for a different audience. The interesting question isn't whether GitHub fixes trending — it almost certainly can't — but whether something replaces it. A reputation-weighted star system, an 'install count' equivalent for libraries, or a curated trending board with editorial standards would all be improvements. Until one of those exists, the trending tab is best read as entertainment.