DEV Community

Cover image for GitHub Stars Lied: 3 Tech-Selection Traps Senior Devs Still Walk Into
Ken Imoto
Ken Imoto

Posted on Originally published at kenimoto.dev

GitHub Stars Lied: 3 Tech-Selection Traps Senior Devs Still Walk Into

#opensource #webdev #devops #productivity

In the Stack Overflow Developer Survey 2025, 17.6% of respondents said they had done extensive work in Vue.js over the past year. On W3Techs (checked 2026-10-19), Vue.js runs on 0.6% of all websites. That is a 29x spread.

Angular: 18.2% in the survey, 0.2% of websites. About 90x. React, the safe pick: 44.7% against 6.0%, about 7x.

Neither number is wrong. The survey counts developers who answered a question about frameworks. W3Techs counts every website it can detect, and most of those are not hand-built single-page apps. The spread mostly says that the two denominators have nothing to do with each other.

That is the useful part. Every popularity number answers a question about some population, and in a tech-selection meeting nobody asks which population. GitHub stars are the most quoted popularity number of all, and they have a population problem of their own.

Trap 1: the bandwagon effect, dressed as "community size"

The bandwagon effect is the tendency to judge something as right because many people have adopted it. Part of that is rational. A widely used tool has more documentation, a more mature ecosystem, and a bigger hiring pool. The trouble starts when that advantage outweighs every other axis.

GitHub stars, npm download counts, Stack Overflow answers. All three signal community size. None of them signal fit for your project. As of 2026-10-19 (GitHub API), apache/echarts has 67.5k stars, chartjs/Chart.js has 67.7k, and d3/d3 has 113.8k. ECharts and Chart.js look like twins on a comparison table. D3 looks like the winner. D3 is a low-level toolkit for building visualizations; the other two hand you finished chart types. The star column cannot show that.

Some of the stars are not people

A study by He et al., published at ICSE 2026, built a detector called StarScout and ran it over all GitHub event data from July 2019 to December 2024. It flagged 6.0 million suspected fake stars and 18,617 repositories with fake-star campaigns. Fake stars stayed at or below 1% of all stars in any month, but campaigns grew from 2022 and surged in 2024. Most of them promoted short-lived phishing malware repositories. The rest went mostly to AI/LLM, blockchain, tool, and tutorial repos.

The paper also measured whether buying stars works. The effect on real attention lasts under two months, is about 5x smaller than the effect of real stars, and turns negative over the long term.

So for a big, old project, fake stars are a rounding error. For a young repo in a hyped category, the star count can be partly bought. Either way, stars are a weak input, and the bandwagon effect makes them the loudest one.

When the effect gets stronger

The bandwagon effect strengthens under three conditions, and all three describe a normal tech-selection meeting:

  • Your own expertise in the domain is shallow (so you lean on "what everyone picks")
  • The decision carries visible blame if it fails (so "we picked the popular one" is the safe story)
  • You are under time pressure (so detailed comparison gets compressed into "which has more stars")

Fifty thousand stars on one framework and five hundred on a competitor is the setup that triggers all three, even when the smaller one fits your use case better.

What catches it: a requirements matrix

Telling the room to "be careful about stars" does nothing. Changing the table does.

List the project's requirements before you look at candidates: performance targets, the team's existing skills, licensing, long-term support, learning cost. Then add community size as one more row, weighted like the others. Score every candidate on every row. Stars now contribute one row out of six, and the five rows that actually describe your project get filled in before anyone opens a GitHub tab.

Trap 2: the IKEA effect on "the thing we built ourselves"

The IKEA effect is the tendency to overvalue things you put labor into. Norton, Mochon, and Ariely described it after experiments in which people assembled IKEA boxes, folded origami, and built Lego sets, then valued their own results above equivalent ready-made ones. Code is labor you can see, so the effect carries over:

  • An in-house framework that two engineers wrote in a hackathon five years ago, defended with "it fits our needs exactly"
  • A custom build config that only one person can modify, kept because "replacing it is risky"
  • A fork of a library that has drifted three major versions, maintained because "we invested a lot of time understanding it"

Not Invented Here syndrome is the acute version. The chronic version is quieter: a steady preference for the thing that has your team's hours in it.

Market numbers will not prove the effect for you. npm counted 76.6 million Vitest downloads and 26.0 million Jest downloads in the week of 2026-10-10 to 10-16. Jest is still a very large installed base. Some of those projects stay because Jest fits them; some stay because of years of local config. The download count cannot tell you which, and neither can you, until you ask the question below about your own stack.

The point to hold on to: "we built it" is a fact about past labor. It says nothing about quality. The question is what the next twelve months of maintenance will cost.

The question that defuses it

One line, on a sticky note by the monitor:

If this system did not exist and we were choosing today, would we pick this?

A no does not mean "migrate now". Migration costs are real. A no means the current choice may be held in place by the IKEA effect plus the next trap, and deserves an actual comparison.

Trap 3: sunk cost, also known as the Concorde fallacy

Everyone can define the sunk cost fallacy, and almost nobody applies it. "We have already invested three months in this refactor" is the shape. The three months are gone. They do not come back if you continue, and they do not vanish if you stop. The only live comparison is the cost of continuing from here against the cost of stopping and switching from here.

The nickname comes from Concorde. Britain and France signed the development treaty in 1962, and costs overran the original estimate many times over. The British government privately regarded the project as a commercial disaster that should never have been started, yet both governments kept paying. Political and legal commitments made withdrawal hard, which is a lesson in itself: sunk cost rarely acts alone. Twenty aircraft were built, fourteen entered airline service, and the fleet retired in 2003.

In engineering, sunk cost shows up as:

  • Deferred refactors ("throwing this code away wastes three months of work")
  • A struggling project that keeps going ("we are 60% of the way there")
  • Unused features kept alive ("we went to the trouble of building it")

Each of those sentences is a sunk-cost claim in disguise.

The forward-only decision frame

The frame that works gives "already spent" zero weight. Three questions:

  1. Set all past investment to zero. Looking only at future cost and return, which option wins?
  2. What does staying on this choice cost over the next year (maintenance hours, learning cost for new hires, effect on hiring)?
  3. What is the one-time cost of switching, and how much does it save per year afterward? Does the saving pay back the switch within a horizon that matters?

"Already spent" is the loudest voice in a technical meeting. It is also the one voice that cannot change the future.

The hype cycle chains all three

Gartner's hype cycle describes technology maturity in five phases, and a different bias dominates each part of it:

  • Innovation Trigger to Peak of Inflated Expectations: the bandwagon effect at maximum. "Do not get left behind" overrides every other signal.
  • Trough of Disillusionment: negativity bias takes over, and the technology gets written off below its real value.
  • Slope of Enlightenment to Plateau of Productivity: calm evaluation finally becomes possible, but whatever was adopted at the peak is now defended by sunk cost ("we cannot throw it away now") and the IKEA effect ("we worked hard to make it run").

Whatever you adopted during the current AI tooling peak will meet this chain on schedule. When the plateau arrives, the choice will be defended by two biases at once, and the forward-only frame is the tool for that review.

Three sentences for the wall

  1. GitHub stars are one row out of six in the requirements matrix. Not a tiebreaker.
  2. "If this did not exist, would we pick it today?" Ask it for every stack you maintain, once a quarter.
  3. Money already spent is zero on the future-cost line. The only live comparison is forward.

Tech selection is a judgment you keep revisiting, and the three biases keep running the whole time. The sentences do not switch them off. They make the room notice when a bias is making the decision, and that is usually enough to get the actual comparison onto the whiteboard.

These three traps and the hype-cycle chain are Chapter 5 of Cognitive Bias for Software Engineers. Chapter 6 applies the same lens to debugging, starting with confirmation bias and the habit of holding several hypotheses at once. It is on Kindle in English, Japanese, and Portuguese.

Sources (all checked 2026-10-19):

Top comments (0)