GitHub's top three repos have zero executable code between them

What happened

Nothing happened, and that's the story. The GitHub trending board today looks identical to the GitHub trending board from 2019, 2021, and 2023. The top three repos by absolute star count are still:

1. freeCodeCamp/freeCodeCamp — 437.9k stars. A learn-to-code curriculum. 2. public-apis/public-apis — 411.9k stars. A markdown table of free APIs. 3. EbookFoundation/free-programming-books — 384.0k stars. A list of free PDFs.

Combined, these three repos contain zero lines of code that anyone runs in production. One is a teaching platform (the actual platform code is a tiny fraction of what gets starred — most stars are aspirational), and the other two are curated markdown files. They have outpaced Linux, Kubernetes, TensorFlow, React, and VS Code — software that, between them, runs most of the internet.

This is not a glitch in the algorithm. It's what the algorithm measures.

Why it matters

GitHub stars are the closest thing the industry has to a universal popularity signal for code. They show up in funding decks, in vendor pitches, in Hacker News headlines ("X just hit 10k stars"), in framework comparisons, and increasingly in AI-generated tool recommendations that scrape repo metadata. The problem is that a star isn't a vote for code quality, adoption, or even use — it's a one-click bookmark, and the things people bookmark most are things they intend to read later.

Look at the gradient. freeCodeCamp has 437k stars. The Linux kernel mirror sits around 180k. React is around 230k. Kubernetes hovers near 110k. The ratio between "things developers might learn from someday" and "things developers actually run" is roughly 2:1 in favor of the bookmarks. If stars correlated with engineering value, the leaderboard would be inverted.

The community has known this for years. Sindre Sorhus's awesome-lists were the original exploit — a single curated README can clear 300k stars without shipping a binary. Trending pages amplify the effect: high-star repos appear in "related" sidebars and recommendations, which gets them more stars, which keeps them on the trending page. The top of GitHub isn't a leaderboard of software; it's a self-reinforcing reading list.

There's a second-order problem that's worse than the measurement issue. When LLMs and code-recommendation tools train on or query GitHub metadata, they inherit this bias. Ask a model "what's the best library for X" and the ranking signal in its training data is dominated by star count. A README-only "awesome-X" list outranks the actual library it links to. The misallocation compounds: developers cite the list, the model trains on the citation, the next developer asks the model, the model returns the list. The actual code — the maintained, audited, production-tested code — sits two clicks deeper in a ranking it earned through use rather than saves.

This isn't an argument against freeCodeCamp or public-apis. Both are genuinely useful. freeCodeCamp has shipped certifications to millions of learners; public-apis has saved every junior engineer at least one hour of Googling. The argument is about what the leaderboard claims to measure versus what it actually measures, and what downstream systems do with that confusion.

What this means for your stack

If you're making a tooling decision based on star counts, stop. Use install counts (npm, PyPI, crates), commit cadence on the last 90 days, issue close ratio, and the median age of open PRs — those measure use, not intent. Stars tell you a repo got enough attention to surface in someone's feed. They don't tell you whether anything depends on it.

For framework comparisons in particular, the meaningful signals are: weekly downloads, contributors in the last six months, the ratio of issues opened to issues closed, and the presence of a release cadence (versus a single v1.0 that hasn't moved). If you find yourself reading a vendor pitch that leads with star count, treat it the way you'd treat a SaaS pitch that leads with logo count — it's a vanity metric dressed up as social proof.

For hiring and personal projects, recognize that contributing to a high-star awesome-list is roughly as technically demanding as contributing to a Wikipedia article. It's a fine thing to do. It is not a code contribution, and a candidate whose top-starred work is a markdown PR to public-apis hasn't demonstrated the engineering skills you might infer from "contributor to 400k-star repo." Read the actual commits.

For your internal tooling: if you index or rank open-source projects anywhere in your stack — for security scanning, for dependency review, for LLM context — exclude README-only repos or weight them at zero. The signal-to-noise improvement is dramatic. A well-tuned filter that drops repos with no source files in compiled languages will surface the actual tool ecosystem in roughly the order practitioners would rank it by hand.

Looking ahead

GitHub itself has experimented with replacing stars as the headline metric — the "trending" page now weights recent activity, and the Explore section leans on "For you" recommendations. Neither has displaced the raw star count as the number every engineer quotes. Until the platform deprecates stars as the headline number or LLM tooling stops treating them as a quality signal, the top of GitHub will remain a library catalog wearing a code repository's uniform. That's fine as long as you read it that way. The danger is in the second-order systems — funding decisions, vendor evaluations, AI recommendations — that don't.