GitHub Trending's top 3: two textbooks and a lobster

What happened

This morning's GitHub Trending lineup, sorted by score, opens with three repos: freeCodeCamp/freeCodeCamp at 437.9k stars, EbookFoundation/free-programming-books at 384k stars, and openclaw/openclaw at 283.1k stars, pitching itself as "Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞"

The first two are the unkillable evergreens of GitHub. freeCodeCamp has been the single largest open-source curriculum on the platform for the better part of a decade; free-programming-books is a curated index that's been mirrored, forked, and submitted to roughly every "awesome" list ever written. Neither trends because anything happened today. They trend because their star velocity, normalized across a multi-million-developer audience, never really stops.

Then there is openclaw. Same trending page, one slot down, 283,100 stars, branded with a lobster emoji and a tagline that reads like it was generated to rhyme with "the unix way." The repo doesn't link to a meaningful release history, doesn't appear in any of the standard agent-framework comparisons, and has a description that could be the output of asking a model to clone OpenInterpreter's positioning.

Why it matters

This is the second time this week the Trending tab has surfaced something that doesn't pass a 30-second sniff test. The earlier case — three coordinated repos with accounts under three days old climbing in lockstep — was a clean astroturf pattern: new accounts, identical climb curves, suspicious cross-starring. This one is subtler and more interesting, because openclaw is sitting next to the two most legitimate repos on the entire platform, and the algorithm is treating all three as the same kind of signal.

GitHub Trending was designed in an era when the assumption was that star count, given enough time, was a reasonable proxy for quality. That assumption breaks the moment stars become cheap. They are now cheap. There are public services that will deliver thousands of stars for tens of dollars, paid in crypto, with delivery windows measured in days. Detection on GitHub's side has not visibly kept pace — accounts created in batches, repos that climb without any corresponding commit activity, and stars from accounts with no other footprint all still count toward Trending position.

The community reaction to the earlier coordinated-repo incident on Hacker News was mostly resignation. The top comment was a variant of "Trending has been broken for years; the only signal I trust is whether someone I follow has starred it." That's a real shift in how senior developers use the platform: Trending used to be a discovery mechanism, and is now closer to a leaderboard that has to be cross-checked against your own social graph before you'd act on anything it shows you.

The deeper problem is that GitHub doesn't actually have a stated definition of what Trending is supposed to optimize for. Is it "projects gaining attention right now"? Then evergreens shouldn't dominate. Is it "absolute star velocity"? Then a gamed repo and a real one look identical. Is it "projects relevant to your interests"? Then the personalization layer is invisible from the public page. The product has been quietly under-specified for long enough that the algorithm's behavior has become the spec, and right now the behavior is: surface whatever has high star velocity, regardless of whether the stars came from people who looked at the code.

The consequences fan out beyond the Trending tab itself. Recruiters use star counts to evaluate candidates. VCs use them as early traction signals. Conference CFP committees weigh "trending project" credentials. Every one of those downstream consumers is operating on a primitive that GitHub no longer effectively defends.

What this means for your stack

If you're using GitHub Trending as a discovery feed — and a lot of senior developers still are, even after years of complaining about it — the practical correction is to add three checks before you star, fork, or recommend anything from it.

Check the commit graph, not the star count. Insights → Contributors shows you whether one person committed 800 times or whether 40 people committed 20 times each. A repo with 283k stars and three contributors who all joined this quarter is a different artifact than a repo with 280k stars and 4,000 contributors over six years.

Check the issue tracker for engagement, not volume. Spam issues and AI-generated questions inflate counts. What matters is whether maintainers are answering, whether PRs are getting merged, and whether the discussion looks like people actually using the software. A trending repo with 200 open issues and zero responses in the last month is a museum exhibit.

Check who starred it, not how many. GitHub exposes the stargazer list. If the first 50 names are accounts with no other repos, no followers, and identically formatted usernames, you have your answer. This sounds tedious; in practice it takes about 90 seconds and is the single most reliable filter available.

For teams: if your hiring loop or your tech-radar process treats "trending on GitHub" as a positive signal, it's worth writing down what that signal is actually supposed to mean and what the failure modes are. "Candidate's side project has 5,000 stars" is information; it is not, on its own, evidence of code quality, taste, or sustained effort.

Looking ahead

GitHub has the data to fix this — stargazer account age, cross-starring patterns, commit-to-star ratios, the works — and has chosen, so far, not to spend it. Whether that changes probably depends on whether enough of the platform's professional users start treating Trending as actively misleading rather than just noisy. Until then, the working assumption for anyone using it as a discovery surface should be: two of the top three are real, one of them is a lobster, and the algorithm cannot tell you which is which.