# Popularity

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


**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](/wiki/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.

| Component | Weight | Saturates around |
| --------- | ------ | ---------------- |
| Stars | 60 | ~5,000 |
| Forks | 25 | ~1,000 |
| Watchers | 15 | ~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](/wiki/growth-authenticity) 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](/wiki/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](/wiki/community-adoption) generally: make the project
easy to discover, adopt, and contribute to, and publish it where its users
already are.

Related: [ecosystem adoption](/wiki/ecosystem-adoption) ·
[community health](/wiki/community-health)