McGrann argues stars function as bookmarks rather than adoption signals — developers tap to save a link and never return, leaving repos with tens of thousands of stars but only hundreds of weekly npm downloads and stale PRs. He frames this as a 'dead economy' where the metric still flows but the underlying activity it represents has evaporated.
By surfacing the post to HN where it hit 416 points and 576 comments, the submitter and upvoting maintainer crowd implicitly endorsed the thesis that star counts no longer correspond to real adoption. The volume of agreement in the thread suggests practitioners recognize the disconnect from their own repos.
The editorial extends McGrann's argument by emphasizing that stars are no longer merely a passive bookmark signal — they are being deliberately manipulated through Discord-coordinated launch pumps, Fiverr star-farm services, and AI-generated repos that accumulate thousands of stars before the README is even read. GitHub's own 2024 transparency report flagging tens of thousands of inauthentic starring accounts is cited as evidence the signal has crossed from noisy to adversarial.
The editorial argues the deeper problem isn't the metric itself but its institutional weight: VC decks lead with star counts, applicants list them on resumes, and employers evaluate maintainers on 'stars per quarter.' A casual bookmark feature is now driving funding rounds and hiring decisions, which makes the gameability catastrophic rather than cosmetic.
The editorial points to npm download curves and dependents counts as comparatively trustworthy signals — not because they're un-gameable, but because gaming them requires persistent infrastructure rather than a one-day Discord raid. The cost asymmetry makes these metrics harder to fake at scale and therefore more aligned with actual usage.
Owen McGrann published 'The Dead Economy Theory' this week, and it hit the HN front page hard — 416 points and a long comment thread of maintainers nodding grimly. The argument is simple and uncomfortable: GitHub stars stopped measuring adoption years ago, and the open-source ecosystem has been running on a metric that no longer corresponds to anything real.
McGrann's framing is that stars function as bookmarks. A developer sees a project on Hacker News, taps the star to find it later, and never returns. Multiply that by a few thousand launches a year and you get repos with 40,000 stars, 200 weekly npm downloads, and four open PRs that haven't been triaged since 2023. The 'economy' is dead in the sense that the signal is still flowing, the leaderboards still update, the trending page still ranks — but the underlying activity it's supposed to represent has evaporated.
The post lands at a particular moment. We've spent the last two years watching star counts get explicitly gamed: launch-day pumps coordinated in Discord servers, paid star-farm services advertised openly on Fiverr, AI-generated repos accumulating thousands of stars before anyone reads the README. GitHub's own 2024 transparency report flagged tens of thousands of accounts in coordinated inauthentic starring rings. The signal isn't just noisy anymore. It's adversarial.
The deeper problem is that stars became load-bearing. VC pitch decks lead with star counts. Job applicants list them on resumes. Open-source maintainers get evaluated by their employers on 'community impact' measured in stars per quarter. A metric that started as a casual bookmark feature is now driving funding rounds, hiring decisions, and roadmap priorities at companies that should know better.
Compare this to what actual adoption looks like. npm download curves are gameable too, but at a much higher cost — you need persistent infrastructure, not a one-day Discord raid. Dependents counts (the number of public repos that depend on a package) are slower to move but harder to fake. Issue-close cadence, PR review latency, and the ratio of external contributors to maintainer commits all tell you something about whether a project is alive. None of these show up on the trending page.
The HN comments add useful texture. Several maintainers reported that their star counts have grown linearly for three years while weekly downloads have flatlined or declined. One commenter from a well-known data tool noted their repo crossed 30K stars last quarter while their actual paying customer count grew 4%. Another pointed out that the 'awesome-lists' phenomenon — those curated README files of links to other repos — creates a structural overcount: every list inclusion is worth a few hundred stars from people who star the list and then star everything on it without reading.
There's a parallel here to what happened with Twitter follower counts circa 2014. The metric was originally meaningful, it got gamed, the platform half-heartedly cracked down, the gaming evolved, and eventually serious people stopped citing follower counts as evidence of anything. Engagement metrics — replies, quote tweets, actual click-throughs — became the real signal, and they remained mostly unfaked because faking them was expensive. GitHub is roughly at the 2014-Twitter moment: the leading metric is broken, the replacement metrics exist but aren't surfaced in the UI, and the institutional users haven't caught up yet.
What McGrann doesn't quite say, but the comment thread does: this is bad for the projects that deserve attention. When stars are uncorrelated with quality, the trending page becomes a coordination game between launch operators rather than a discovery surface for good software. Real projects with steady contributor growth and meaningful download curves get drowned out by repos optimized for the 24-hour launch cycle. The discovery layer of the OSS ecosystem is degrading, and it's degrading in a direction that rewards marketing over engineering.
If you're evaluating a dependency to bring into your codebase, stop looking at the star count. Look at four things instead. First, the npm or PyPI download curve over the last 12 months — not the absolute number, the *shape*. Healthy projects grow steadily or hold a plateau. Dead projects spike on launch and decay. Star-farmed projects look fine on stars and terrible on downloads. Second, the dependents count — how many other public packages actually `require` this thing. GitHub shows this in the Insights → Dependency graph. A project with 50K stars and 12 dependents is a bookmark. A project with 8K stars and 4,000 dependents is infrastructure.
Third, look at issue and PR cadence. Open the Pulse view. Are issues being triaged within a week? Are PRs from outside contributors getting reviewed, or sitting for months? A project where the maintainer is the only person merging code is fragile regardless of star count. Fourth, check the contributor graph. A handful of dominant committers plus a long tail of drive-by fixers is the healthy pattern. A single committer with no external contributors after three years means you're adopting one person's hobby project.
For maintainers, the practical move is to stop reporting stars as a success metric, internally or externally. If your employer or sponsors care about your project's health, give them download counts, dependents, and active-contributor counts. The conversation will be harder because those numbers are usually smaller and less flattering, but they're the numbers that actually predict whether your project will exist in three years. For startups raising on OSS traction: assume sophisticated investors are already discounting your star count by 60-90%, and lead with the metrics that survive scrutiny.
The interesting question is whether GitHub itself moves. There's no incentive for them to — stars drive engagement, trending pages drive sessions, and the gameability is someone else's problem. But the pressure is building from the side. Tools like npm-stat, Sourcegraph's code search, and the various OSS health dashboards (CHAOSS, Scorecard, OpenSSF) are quietly becoming the metrics that serious teams actually consult. The end state is probably not GitHub fixing stars but the industry routing around them — the same way we route around Twitter follower counts, App Store ratings, and Glassdoor reviews. The metric stays on the page. Nobody serious cites it. That's how dead economies end: not with a crash, but with everyone gradually agreeing to look somewhere else.
Not many people see that the end result is that when ordinary people stop earning money, and stop buying products, all the money will be used purely for B2B transactions.Money will still exist, but people will not see hardly any of it. To break out of being just a person and start a business you wil
This article, like Citrini research's scenario before it, misses much of the economics.AI is unlikely to be as revolutionary as is presumed. It's definitely going to lead to increased productivity, and will probably render some jobs redundant, but it's unlikely to have a significant e
This article puts into words a lot of things that had been on my mind as missing in AI discourse. Most significantly, actually considering the _systemic consequences_ of the promised AI future, how it interacts with political economy, an actual critical look (instead of accepting the "Western m
It’s great this debate is happening. The people on hn are some of those that can make a real impact here. There are many parallels with the industrial revolution here but we really don’t want to repeat a over a century of misery that occurred after that era. If we don’t want the world to be run be a
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
The article doesn't seem to take his train of thought quite far enough.If AI suddenly makes it possible for a law firm to be run with a skeleton crew, then what's stopping all those people you fired from starting new law companies, where AI also does most of the work, and competing with yo