GitHub's top 3 repos aren't code. They're bookmarks.

What happened

The three most-starred repositories on GitHub today are, in order: freeCodeCamp/freeCodeCamp (437.9k stars), public-apis/public-apis (411.9k), and EbookFoundation/free-programming-books (384k). Combined: 1.23 million stars. That is more than the combined star counts of React, Vue, Next.js, and TypeScript.

None of these repositories ship code you would ever `import`. freeCodeCamp is a curriculum delivery system — its repo is a learning platform plus thousands of markdown challenges. public-apis is a Markdown table of free HTTP endpoints with categories like "Animals" and "Anime." free-programming-books is, almost literally, a list of links to PDFs.

The three most-starred repos on GitHub are a curriculum, a link directory, and a book index — three things you can't `npm install`. That's not a coincidence. It's what GitHub's star system has been measuring all along, and the leaderboard just made it impossible to ignore.

Why it matters

The star button was introduced in 2012 as a replacement for the older "watch" feature. The original intent was somewhere between a bookmark and a like. Over the next decade, it became the de facto popularity metric for open source — included in README badges, used by VCs to size up dev-tools markets, and cited in conference talks as a proxy for adoption.

It was never a good proxy. Stars measure exactly one thing: how many logged-in GitHub users clicked a button. They don't measure installs, production usage, contributor health, security posture, maintenance velocity, or whether a project is abandoned. A star is a save-to-Pocket with a public counter — and the all-time leaderboard reveals that's how developers have been using it the whole time.

Look at the pattern. The top three are all *reference material that you want to come back to but never quite get around to*. freeCodeCamp: "I should learn this properly." public-apis: "I might need a weather API someday." free-programming-books: "I'll read that SICP PDF eventually." These are the three biggest piles of digital good intentions on the planet.

Compare against the most-used repos — measured by npm downloads, GitHub dependents, or production telemetry. The leaders there are things like `lodash`, `axios`, `express`, `react`, `typescript`. None crack the top 20 by stars. Sindre Sorhus's `is-odd` has more stars than several libraries that genuinely run civilization. Stars and usage have been decoupled for years; the all-time leaderboard is just the cleanest demonstration we've had.

This matters because we use star counts to make decisions. A VC seeing a 40k-star repo thinks "traction." A junior dev picking between two libraries picks the one with more stars. A security team scanning dependencies treats high-star projects as "vetted." Each of those decisions imports an assumption — that stars correlate with quality — that the leaderboard explicitly disproves.

The HN comment sections on these repos (going back years) consistently surface the same complaint: maintenance burden. freeCodeCamp's actual curriculum work happens in a small subset of files; the rest of the repo is enormous and intimidating to contribute to. public-apis has had multiple bus-factor crises where the sole maintainer burned out from the PR firehose. free-programming-books is a perpetual link-rot battle. The thing that makes them star-magnets — "comprehensive reference I might use later" — is exactly the thing that makes them brutal to maintain.

What this means for your stack

First, stop using star counts as a dependency signal. If you're evaluating whether to pull in a library, the useful metrics are: last release date, open-vs-closed issue ratio, number of distinct contributors in the last 90 days, whether the maintainer responds to security advisories, and your own `npm audit` output. Stars tell you the README got shared on Hacker News three years ago. The honest replacement for star-counting is reading the issue tracker for ten minutes — it will tell you in a glance what stars have been hiding for a decade.

Second, recognize what you're actually doing when you star something. If it's a bookmark, treat it as one — and notice you have 4,200 of them and have revisited maybe 30. The star button is a low-friction way to outsource your TODO list to GitHub's UI, and the tax is a homepage cluttered with things you'll never read. A monthly star-prune is more useful than another star.

Third, if you're building or maintaining a dev tool, calibrate expectations. Star velocity is a *marketing* metric — it tells you your launch landed on HN or your README went viral. It tells you nothing about whether anyone is actually shipping with your code. Track installs, weekly active users (if you can), retention. The teams with 8k stars and 50k weekly active installs are healthier than the ones with 80k stars and a graveyard of GitHub Issues.

Looking ahead

The interesting question is whether GitHub does anything about this. They've been quietly rolling out "used by" counts on repository pages — a far better signal than stars, since it counts actual `package.json` dependents. If "used by" becomes the headline metric, the leaderboard changes overnight and the conversation shifts with it. Until then, the three biggest reference piles in software development will sit at the top of the chart, gently reminding us that what we measure isn't what we mean — and that the most-starred repository in history is a list of links to books most of us will never finish.