GitHub Stars Are Bookmarks, Not Votes: Reading the Trending Board

What happened

GitHub Trending this week is topped by three repos that, taken together, expose a measurement problem the ecosystem has lived with for years. freeCodeCamp sits at 437.9k stars. EbookFoundation/free-programming-books is at 384.0k. openclaw — the 'personal AI assistant, the lobster way 🦞' — is at 283.1k. For comparison, facebook/react is at 243.9k and torvalds/linux is at 221.6k.

Two of the three repos at the top contain zero executable code. freeCodeCamp is curriculum and a learning platform's source. free-programming-books is a markdown index of PDFs. openclaw is the only one of the three that you could plausibly `git clone && run`, and even there the audience is hobbyist desktops, not server fleets. None of them appear in a `package.json` you ship to production. None of them are in your container images. The most-starred work on GitHub is, increasingly, things developers want to read, not things they run.

The pattern isn't new — sindresorhus/awesome has been gaming the leaderboard since 2015 — but the gap has widened. Of the top 10 most-starred repositories on GitHub today, six are curricula, awesome-lists, or 'how to become an X' guides. The remaining four are split between runtimes that actually power infrastructure (Linux, React, VS Code) and aspirational AI side-projects.

Why it matters

The star button was designed in 2012 to replace the watch/unwatch confusion. It was never intended to mean 'I depend on this' or 'I have audited this code.' It means 'save for later' — closer to a Twitter bookmark than a Reddit upvote. And yet star counts have leaked into procurement decks, OSS funding pitches, hiring signals, and dependency selection.

This matters because the proxy is broken in a specific, measurable direction. Educational and aspirational content benefits from massive top-of-funnel exposure: every bootcamp student, every 'learn to code' YouTube viewer, every Hacker News reader who's ever thought 'I should brush up on systems' lands on freeCodeCamp or free-programming-books and clicks star. Production libraries — pg, esbuild, undici, sharp — get starred by the much smaller pool of developers who actually integrated them and remembered to come back.

The asymmetry is roughly an order of magnitude. pg, the PostgreSQL driver underneath a meaningful fraction of Node.js production traffic, has about 12,800 stars. freeCodeCamp has 437,900. If stars correlated with importance, pg would be a rounding error. It is, instead, in nearly every Node.js Dockerfile shipped this year.

The community has known this for a while. Evan You has noted that Vue star counts tracked 'hype cycle' more than installation. Kent C. Dodds wrote in 2020 that he stopped using stars as a signal entirely. The npm Registry's download API and GitHub's own Dependents graph (`/network/dependents`) expose far better numbers — actual `require()` and `import` counts across public code. But neither is surfaced on the repo page above the fold. The star count is. The UI is doing the lying; the data is fine if you look for it.

openclaw is the interesting case in the middle of this. It's a working program — not curriculum, not a markdown list — and it's tracking 283k stars largely on the back of the 'personal AI on your laptop' narrative. But check `/network/dependents` and the count is dominated by forks of itself and tutorial repos. There is no production stack that has 'openclaw' as a critical-path service. It's running on developer laptops as a chat client, the way Alfred or Raycast does. That's a real thing, but it is not the same kind of thing as Linux being at 221.6k stars while running every cloud server openclaw queries.

What this means for your stack

If you evaluate dependencies by star count, you are systematically overweighting projects that are good at marketing and underweighting projects that are good at uptime. The fix is a 30-second habit: before starring or adopting, open the Dependents tab and the npm/PyPI weekly downloads page. A library with 4,000 stars and 8 million weekly downloads is a load-bearing piece of infrastructure. A library with 40,000 stars and 12,000 weekly downloads is a blog post.

For hiring and resume signals, the inversion is sharper. A candidate with a repo that has 2,000 stars but 600 production dependents has shipped something the world uses. A candidate with a repo that has 80,000 stars but two dependents (themselves) has shipped something the world bookmarked. Both are legitimate accomplishments — bookmarking 80,000 people's attention is hard — but they are accomplishments of different kinds, and conflating them produces bad hiring decisions.

For funding (OpenCollective, GitHub Sponsors, sovereign open-source grants), the implication is that the projects most likely to be quietly load-bearing are also the projects most likely to be invisible on a leaderboard. The XKCD 2347 phenomenon — 'all modern digital infrastructure depending on a project some random person in Nebraska has been thanklessly maintaining' — is a direct consequence of using stars instead of dependents as the funding-allocation signal.

Looking ahead

GitHub has the data to fix this. The Dependents graph, npm/PyPI download counts, and even container-image pull telemetry are all sitting in either GitHub's or its parent Microsoft's datastores. A 'production reach' badge — installs, dependents, container pulls — surfaced next to the star count would change procurement and hiring conversations overnight. There is no sign that ship is sailing. Until it does, the most-starred repo on GitHub will continue to be something that compiles to nothing, and the libraries running your stack will continue to be ranked somewhere below the latest 'awesome-' list. Treat the leaderboard as a reading list. Treat the dependents graph as the credit rating.