GitHub's Top Three Repos Are All Markdown. None Is Code.

What happened

Look at GitHub's all-time star leaderboard in June 2026. The top three repositories are sindresorhus/awesome at 444,000 stars, freeCodeCamp/freeCodeCamp at 437,900 stars, and public-apis/public-apis at 411,900 stars. Combined, that's nearly 1.3 million stars sitting on top of the entire platform.

None of them ships software you can install. The most-starred artifact on the world's largest code host is a list of lists. sindresorhus/awesome is a README pointing to other READMEs. public-apis is a markdown table of HTTP endpoints, many of them dead. freeCodeCamp is the closest thing to actual code in that trio, and it's primarily a curriculum platform — a Node.js monorepo whose purpose is to serve lessons, not to be used as a dependency.

The fourth and fifth slots aren't much better. EbookFoundation/free-programming-books and codecrafters-io/build-your-own-x are also curated lists. You have to scroll into the high six figures of rank before you hit something a senior engineer would actually `npm install` or `pip install` against.

Why it matters

Stars are an append-only counter. Once you star a repo, you almost never unstar it — which means star counts measure cumulative attention since 2008, not current relevance. That accounting bias rewards two things disproportionately: (1) repos that hit the front page of Hacker News in their first month and were starred reflexively, and (2) repos that function as personal bookmarks. "Awesome-X" lists are pure bookmark fuel. You see one, you star it, you never open it again. The star is doing the work of a browser bookmark folder, with the social-proof side effect that it inflates a number on a leaderboard.

The community has been complaining about this for a decade. A 2019 paper from the University of Zurich looked at star-vs.-fork ratios and found that high-star, low-fork repos are overwhelmingly documentation, lists, or one-off demos rather than actively-used libraries. public-apis itself is the textbook case: a recent audit by a Reddit thread found roughly 40% of the listed endpoints return 4xx or 5xx, and a non-trivial fraction have had their domains parked or sold. The list has 411,900 stars and is, in measurable terms, decaying.

The meta-problem is that GitHub's own ranking surfaces — Explore, Trending, the search default sort — lean on stars. So do downstream consumers: package-of-the-week newsletters, VC sourcing tools, and the LLM training corpora that increasingly seed code assistants' "recommended library" answers. When your model's idea of "popular Python HTTP client" is derived from star counts, you get answers biased toward whatever was viral in 2017, not whatever is maintained in 2026. This is how `requests` continues to dominate suggestions even after years of `httpx` being the better default for async work.

There's also a structural reason curated lists win the star race. They are zero-cost to bookmark and have effectively infinite surface area — every developer in every niche finds *something* relevant in awesome-python or public-apis. Tools, by contrast, only earn stars from the subset of developers actually working in that domain. A Rust web framework will never out-star a list that contains every Rust web framework. The list is the meta-tool, and meta-tools have meta-audiences.

What this means for your stack

Stop using raw star counts as a quality or adoption signal. The most useful adoption metric on GitHub is the dependents graph — the count of repositories that actually `import` or `require` your library — which GitHub exposes via the Dependency Graph tab and via the API. A library with 8,000 stars and 60,000 dependents is in your supply chain. A library with 80,000 stars and 200 dependents is a demo somebody saw on Twitter.

The second-best signal is maintenance velocity over a rolling 90-day window: median time to first response on issues, percentage of PRs that get reviewed within seven days, and frequency of releases. Both are queryable through the GitHub GraphQL API and trivially scriptable. We run this exact query for top10.dev's own tool rankings — source weight × engagement × recency, where recency is heavily decayed. It's not a coincidence that our weights converge on different leaders than the star leaderboard does.

For anyone running curated discovery internally — internal devtool registries, platform engineering catalogs, AI-assisted code search — the lesson is the same: treat "awesome" lists as starting points for human review, never as oracles. The half-life of an entry in public-apis is shorter than the half-life of a star. Wire your registry to a link-check job and an activity check, or you'll be recommending dead endpoints and abandoned forks to engineers who trust the registry.

Looking ahead

GitHub knows the star metric is broken. They've quietly shipped richer signals over the last few years — the dependency graph, the contributor activity sparkline, the "used by" widget — but the leaderboard hasn't been re-sorted around any of them, because doing so would unseat a politically convenient set of repos near the top. (Imagine the discourse if freeCodeCamp dropped out of the top ten.) Until that changes, the practitioner's job is to ignore the top of the leaderboard and look one layer deeper. Trending is downstream of stars; stars are downstream of bookmarks; bookmarks are downstream of "I should look at this later." Most of the time, nobody ever looks at it later.