GitHub stars or npm downloads: which is the better signal?

A star is one human clicking one button. A bookmark. It costs nothing, it takes a second, and it never expires. It means a person saw your repo and wanted to find it again later.

That is the whole signal. Attention. Intent to remember. It does not mean they installed it, ran it, or will ever open the tab again. A star is the developer version of I will get to this later, and you know exactly how many of those you have gotten to.

So stars measure mindshare, not usage. They tell you who noticed. Useful, but do not confuse noticing with using. For the longer argument on what a star is worth, see do GitHub stars matter.

A download is an install event. Someone, or something, pulled the package from the registry. That is closer to real use than a bookmark. It is also where the trouble starts.

The something is doing heavy lifting. Every CI run downloads the package again. Every Docker image rebuild. Mirrors, corporate caches, proxies, bots. A green pipeline that runs forty times a day is forty downloads, and not one of them is a person.

So the number is real installs plus a large, invisible tax of machines. A download is not a user. It is a fetch. Treat it as directional, never as a headcount.

Because they measure different halves of the funnel. Stars measure the pitch. Downloads measure the habit.

A slick demo with a clever README can rack up stars and near-zero installs. Everyone admired it, nobody shipped it. That is all stars, no adoption.

A boring, load-bearing utility goes the other way. A date parser, a lockfile tool, something nobody bookmarks because they use it every day without thinking. Millions of weekly downloads, a modest star count. All habit, little applause.

When the two disagree, the gap is not an error. It is information. A wide gap between stars and installs is telling you which one you actually have.

Depends what you are asking. Then read the number correctly instead of at face value.

• For adoption, trust downloads. But weekly, not all-time. All-time counts every CI run since the package was born and tells you nothing about now. Weekly plus a trend line tells you whether use is growing, flat, or quietly bleeding out.
• For mindshare, trust stars. But read the shape, not the total. A repo with 8,000 stars on a flat line got them in one Hacker News spike two years ago and has been coasting on the corpse ever since. Pull the star history and check whether stars still arrive today or stopped arriving in 2024.
• Always compare rivals. A number alone is a number. acme/rocketdb at 40k weekly downloads means one thing next to a competitor at 4k and something very different next to one at 4 million. Context is the whole read.

Do this and you stop getting fooled by an old spike or a padded lifetime total. For the deeper version, see GitHub star history.

The people.

Stars and downloads are both aggregate. How many. A count, a chart, a line going up or, more honestly, sideways. Fine for a slide. Useless for a conversation. You cannot email a number, and a download graph will not tell you what it was trying to build when it installed your package.

The value is the named human on the other end. dev-priya starred your repo at 2am on a Tuesday. That is a person with a problem you might already solve. The count will never say her name.

This is the owner-first move, and it is the only one worth making. Your stars are your stars. WarmStars turns a repo owner's own stargazers into a list of named people, from public data only, with a public email for many of them, so your first users stop being a badge number and start being people you can talk to. Begin with the ones who already raised a hand: the developers who starred you. See who starred your repo.