Repository metrics

Popularity

How inspect.software measures repository popularity — stars, forks, and watchers on a logarithmic scale. 7.2% of the overall health index.

Methodology v1.13.0Updated 2026-07-21

Popularity measures how much adoption and attention a repository has gathered on GitHub itself: stars, forks, and watchers. Attention is weak evidence compared to real installation data — but it is universal (every repository has it, packaged or not) and correlates with the size of the community that would notice a problem.

  • Category: Community & Adoption (40% within category)
  • Weight in overall index: 7.2%
  • Metric key: popularity

How the value is computed

All three components are logarithmically scaled — each order of magnitude matters roughly equally, so the difference between 50 and 500 stars counts about as much as between 500 and 5,000.

ComponentWeightSaturates around
Stars60~5,000
Forks25~1,000
Watchers15~500

A count of 1 or 2 earns no points — a single star or fork is noise rather than adoption — so each component only begins scoring from 3 upward.

Stars and forks can be bought

They are the only inputs in the model with no issuer, and they are sold openly in bulk. Where a repository's collected day-by-day history shows growth that organic attention does not produce, the Inorganic Growth Policy discounts the stars and forks components — by 40% for one confirmed burst, 70% for more. Watchers are untouched, a clean history never raises the value, and a repository whose history cannot answer the question is not penalized at all.

Why the log scale

A linear scale would make the metric a proxy for fame, dominated by a handful of mega-projects and useless for comparing everything else. The log scale compresses the top and stretches the middle, where most real dependency decisions are made. Saturation points mean that beyond ~5,000 stars, additional attention adds nothing — the metric has answered its question.

Reading the result

  • Popularity is the weakest form of adoption evidence. Stars accumulate and never decay, so old attention lingers. Where the project publishes a package, ecosystem adoption — real download volume — is the stronger signal, and the category weights reflect that hierarchy.
  • Forks carry independent information: they indicate people working with the code, not just bookmarking it.
  • Low popularity is not a defect. Young or niche projects read low here by nature; the metric is 7.2% of the overall precisely so that quality and governance evidence can outweigh fame.

Improving the value

There is no direct lever, and that is by design — attention follows usefulness. The durable path is the same as for Community & Adoption generally: make the project easy to discover, adopt, and contribute to, and publish it where its users already are.

Related: ecosystem adoption · community health