GitHub's top 3 repos have 1.3M stars and zero production code

What happened

As of this week, the three most-starred repositories on GitHub are, in order: sindresorhus/awesome at 444.0k stars, freeCodeCamp/freeCodeCamp at 437.9k, and public-apis/public-apis at 411.9k. That's roughly 1.29 million stars across the top three slots.

None of them are code you can install. `sindresorhus/awesome` is a markdown file linking to other markdown files. `public-apis` is a table of URLs with a column for whether they need auth. freeCodeCamp is the closest thing to a codebase in the group, but its stars are for the curriculum — the actual JavaScript that runs the platform is a footnote to what people actually engage with, which is the lessons.

The number-one repository on the world's largest source control platform is a list of lists. The number-three repository is a directory of APIs the maintainers didn't write. This is not new — sindresorhus has held or shared the top slot for years — but the composition of the leaderboard has now fully inverted from what stars were originally supposed to measure.

Why it matters

Stars started as a bookmark. On a platform full of actual libraries, the aggregate signal worked: React, Vue, TensorFlow, Linux — the top of the board matched the top of the ecosystem. Over the last five years that mapping broke. The mechanism is simple: reference material has directory-scale network effects, and libraries don't.

A library gets one star per user who found it useful. A curated list gets one star from every user who might *eventually* find one of its links useful — plus every user who wants to signal-boost the concept, plus every user who wants to find it again later, plus every AI agent trained on GitHub metadata that treats stars as a quality signal. The two artifacts are being measured with the same yardstick, but one of them has a target population an order of magnitude larger.

The result is that the leaderboard now selects for canonicity, not utility. A useful React component library might have 5,000 stars. `awesome-react`, which links to it and 300 others, has 65k. Neither is doing the other's job, but from a distance the star gap suggests the directory is 13x more valuable than the code — which is nonsense if you're a practitioner and completely rational if you're a crawler.

Compare this to npm's download counts, which measure something you can't fake with a bookmark: an install, in a build, that succeeded. npm's top packages are `chalk`, `lodash`, `react`, `express` — all libraries, all imported by things that actually run. The two rankings barely overlap. That divergence is the story. Two platforms that supposedly measure open-source popularity have completely different top-tens because they measure completely different things.

The community reaction on Hacker News to similar trend data has been split along familiar lines. One camp calls it "GitHub becoming a bulletin board" and treats it as decline. The other points out that discovery has always been the hard part of open source, and that these lists solve a real problem — which is why they get stars in the first place. Both sides are right. The lists are genuinely useful *and* they are structurally impossible to compare to code on the same axis.

What this means for your stack

First, stop using stars as a proxy for anything except attention. If you're evaluating whether a library is maintained, look at commits in the last 90 days, open issue response time, and the ratio of open to closed PRs. If you're evaluating whether a library is used, look at npm/PyPI/crates.io downloads or the dependents graph. A 50k-star repo with two commits this year and 400 open issues is a museum piece, and a 3k-star repo with weekly releases and 30 dependents in production is probably what you want.

Second, if you ship a library, understand what you're actually competing with for attention. You are not competing with other libraries. You are competing with the awesome-list entry for your category. Getting into the right curated list is often worth more distribution than a thousand direct stars, because the list is the thing agents and juniors read first. The maintainers of these lists have effectively become distribution gatekeepers, and their PR queues are the real onboarding funnel for a lot of tools.

Third, if you build tools that consume GitHub metadata — dependency scanners, security tools, LLM-powered code search, agent frameworks that rank repos — you need to filter reference-material repos out of your "popular code" heuristics or you'll waste tokens explaining that `sindresorhus/awesome` is not, in fact, a package. This sounds obvious. It is not what most of the current wave of code-context tools do.

Looking ahead

The long-run direction is that GitHub becomes two products stapled together: a code host, and a directory layer that indexes the code host. The star system was designed for the first and has been captured by the second. Nobody is going to fix this — the incentives point the other way, and the lists are legitimately useful — so the practical move is to stop treating the leaderboard as a code ranking and start reading it as what it is: the index at the front of the encyclopedia, telling you where the real content lives.