Three list-repos own the top of GitHub. None ship runnable code.

What happened

Three repositories sit at the top of GitHub's trending board this week, all carrying star counts that dwarf the platform's flagship engineering projects. freeCodeCamp/freeCodeCamp holds 437,900 stars on its open-source curriculum for learning math, programming, and computer science. public-apis/public-apis carries 411,900 stars on a curated list of free APIs. EbookFoundation/free-programming-books clocks 384,000 stars on a catalog of freely available programming books.

Combined, they hold 1.23 million stars — more than the Linux kernel and React put together — and none of the three ships software that runs in production anywhere.

freeCodeCamp is the closest of the three to actual running code: it's a Node.js platform serving an interactive curriculum, but the star count attaches to the curriculum, not the runtime. The other two are pure markdown directories in the awesome-list format: README-first, with PRs that add bulleted entries to long alphabetized lists. There is no install command. There is no binary. There is no deploy target. They are repositories in the same way Wikipedia articles are repositories — git happens to be the substrate, but the artifact is text.

Look one rung down and the pattern holds: kamranahmedse/developer-roadmap (350.5k), vinta/awesome-python (286.7k), awesome-selfhosted/awesome-selfhosted (281.2k), f/prompts.chat (151.0k). Seven of the top twenty repositories by star count on GitHub are reference material, not code. The top of the leaderboard is a public library wearing a version-control hoodie.

How GitHub's discovery actually surfaces this

GitHub's discovery surfaces — Trending, Explore, the default sort on search-by-language, the "Used by" suggestions — all consume star count as a primary feature. The Trending page explicitly ranks by star growth over a window. Repository search has a `sort:stars` parameter that the UI offers as the first sort option. Stars are the default ranking signal on the surfaces developers use to find new code, and they remain so in 2026 despite a decade of community grumbling.

The consequence is structural. When a junior developer in 2026 searches GitHub for "python web framework," awesome-python ranks above any actual framework. When they search for "api," public-apis ranks above any actual API client. The reference catalogs win the ranking competition because the cost of giving them a star is identical to the cost of starring a real library — one click — but the addressable audience is everyone learning to code, not just the smaller cohort evaluating dependencies for a project.

This is the search-ranking version of the long tail collapsing on itself. The most-bookmarked repository on a topic outranks the most-used repository on the same topic, and GitHub's algorithm can't tell the difference because it never asked.

Stars as vanity vs. utility

The incentive structure underneath is the part worth looking at directly. A star costs nothing to give and accrues nothing to the giver — it's a pure signaling primitive with no skin in the game. That makes it a vanity metric in the literal economic sense: a unit of attention that is cheap to mint and cheap to consume.

The utility signals — the ones that correlate with whether a repository actually ships code that other people run — all carry cost or commitment:

- npm downloads / PyPI installs: requires the user to have a build pipeline and a real reason to depend on the package. - Dependents graph: someone wrote a `package.json` entry. That's a contract, not a click. - Commit cadence over six months: requires maintainers to keep showing up. - Issue close rate: requires triage and code review labor. - Releases tagged in the last 90 days: requires the project to still have a heartbeat.

A list-repo can rack up 400,000 stars while having a commit cadence of one merged PR per week — and that PR is adding a row to a markdown table. A library like React commits dozens of times per week from a paid maintainer team, gets installed 25 million times per week from npm, and sits at 243.9k stars. By the only metrics that measure shipping, React is an order of magnitude more consequential than public-apis. By the metric GitHub ranks on, public-apis wins.

This isn't an accident of measurement — it's a feature of how attention scales versus how engineering effort scales. Attention is exponential and cheap; engineering effort is linear and expensive. Any ranking system that doesn't price that asymmetry into its signal will, given enough time, sort attention to the top.

Are list-repos crowding out maintained projects?

Probably, yes, on the surfaces where it matters for discovery. Trending and language search are where new projects get their first thousand users. If those surfaces sort by stars and the star pool is dominated by reference material, a newly-released maintained library has to fight uphill against repos that aren't even in the same product category.

The counterargument: experienced developers don't find libraries through GitHub Trending — they find them through Hacker News, X, work Slack, and "what does the framework I'm already using recommend." That's true, but it's a generational handoff problem. Developers entering the field in 2026 are using LLM-mediated search and GitHub's own surfaces as their default discovery layer, because that's what loads fastest in their workflow. Both of those layers consume star count as a quality proxy. The bias propagates.

GitHub has tools to fix this without breaking anyone's workflow. A repository "kind" field — distinguishing `library`, `application`, `curriculum`, `awesome-list`, `documentation` — would let Trending and search optionally filter by kind. The data is already inferable: a repo with no source files and a README full of bulleted links is mechanically detectable. Star-weighting by repository kind, or simply offering kind as a search filter, would let developers searching for runnable code see runnable code first.

Until GitHub ships that taxonomy, the leaderboard will keep measuring bookmarking volume, the discovery surfaces will keep ranking by it, and the gap between the most-starred repos and the most-shipped repos will keep widening. The artifact at the top of GitHub is no longer code — it's a reading list, ranked by who clicked the star button on it. That's a fine thing to exist. It's a bad thing to be the default sort.

What to do about it as a practitioner

Ignore stars when evaluating a dependency. Look at weekly download count on npm/PyPI, the dependents graph (`github.com//network/dependents`), commits in the last 90 days, and the date of the most recent release. If you're shipping code that imports it, those four signals tell you whether the project will still be alive in eighteen months. Stars tell you how many people thought it sounded interesting once.