GitHub's three biggest repos ship almost no code

What happened

A snapshot of GitHub Trending today, sorted by all-time stars, returns the same three repositories that have held the top of the leaderboard for years: freeCodeCamp/freeCodeCamp at 437.9k stars, public-apis/public-apis at 411.9k, and EbookFoundation/free-programming-books at 384.0k. Combined, that's roughly 1.23 million stars across three projects.

None of them are software.

freeCodeCamp is a Node/React monorepo, but the star magnet is the curriculum — thousands of Markdown lesson files. public-apis is a single `README.md` and a `db/` directory of categorized JSON entries pointing at third-party REST endpoints. free-programming-books is, almost in its entirety, a directory of Markdown tables of links to PDFs and HTML pages hosted elsewhere. The most-starred artifacts on the world's largest source code host are not source code. They are crowd-curated bookmark files that happen to be version-controlled.

This isn't new — it's been true for a decade. But the gap is widening, and worth naming clearly because of what it implies about every other ranking you read on this platform.

Why it matters

GitHub's star is overloaded. It functions as a bookmark, a thank-you, a vote, a portfolio tag, and a like. The three repos above are optimized — accidentally and then deliberately — for the bookmark axis. You read the README once, you star it because you'll come back, and you never interact again. That single action, repeated by 400,000 people over ten years, beats every actual engineering project on the platform.

For comparison: React (236k), Vue (210k), Next.js (130k), and TypeScript (103k) sum to roughly 679k stars. The top three reference lists outscore the four pillars of modern frontend by almost 2x. No JavaScript framework has ever come within striking distance of a well-maintained list of free PDFs. That's not a knock on the lists; it's a description of what the metric rewards.

The community knows this implicitly. Every senior dev who's ever evaluated a library has internally discounted star count. But the discount is rarely articulated, and the platform's UI still treats stars as the primary social proof — Trending tabs, search rankings, README badges, VC due-diligence slides. When the top of a leaderboard is dominated by artifacts that don't compile, the leaderboard is measuring attention, not engineering.

There's a second-order effect worth flagging. Because these three repos are zero-maintenance (a list never goes out of date in the way a runtime does — links rot, but the index keeps working), they compound. A library written in 2015 ages out of relevance; a list of free books written in 2015 just keeps growing. The star economy rewards artifacts whose half-life is infinite, which means it structurally underrates anything that has to be rewritten when the platform underneath it shifts. Your favorite well-maintained Go HTTP library will never catch a Markdown table.

The community reaction to this state of affairs has been muted, mostly because there's no villain. freeCodeCamp earned its position by teaching millions of people to program for free. public-apis is genuinely useful when you need a weather endpoint at 2am. free-programming-books has probably introduced more people to SICP than any university. The complaint isn't that these repos are bad — it's that they are sitting at the top of a metric that other people use to make build-vs-buy decisions.

What this means for your stack

Stop reading star count as a software signal. Read it as a bookmark signal. A 50k-star CLI is not necessarily fifty times better than a 1k-star CLI; it's been recommended on Hacker News more often. The metrics that actually correlate with software quality are downstream: weekly download counts on the package registry, issue close rate, contributor diversity (not just commit count), and CI green-rate over the last 90 days. If you're evaluating a tool, npm/PyPI download trend over the last 6 months tells you more about real-world adoption than the lifetime star count ever will.

Audit your own README discovery. If you maintain an open-source library and you're stuck at 800 stars, the lesson here isn't "add a curriculum." It's that the bookmark/install ratio for actual software is brutal — most people who try your tool won't star it, and most people who star it won't install it. Optimizing for stars at the expense of docs, install ergonomics, or registry presence is a category error. Spend the energy on the npm page.

Be skeptical of "GitHub Trending" as a discovery surface. Trending surfaces velocity, not stickiness. The repos at the top of all-time are there because they accreted attention slowly across a decade of casual saves. Trending today shows you what got linked from one viral post yesterday. Neither tells you whether the code is good. If you want signal on emerging tools, sort by recent commit activity within a known ecosystem (e.g., `npm:keyword`, `crates.io/categories`) — that filters for projects whose maintainers are still showing up.

Looking ahead

The interesting question isn't whether GitHub will fix the star metric — it won't, because the bookmark behavior is genuinely useful and there's no replacement primitive that captures it as cleanly. The interesting question is which platform builds the first real "engineering quality" leaderboard: weighted by registry downloads, by dependent-repo count, by paid-seat usage, by maintenance velocity. Whoever ships that becomes the new GitHub Trending. Until then, the top of the chart will keep being a Markdown table of free PDFs, and your job is to remember that the chart isn't ranking what you think it's ranking.