Methodology

How adoption is estimated

A deterministic statistical model over public download data, with no LLM involved. Every estimate carries an 80% interval; the code is in src/metrics/.

Public data
Reproducible
Intervals

Estimated from public npm, npmmirror and GitHub data

Active installs

Estimated users

New installs / day

Update half-life

The model

Missing days

A day on which every package reads zero on npm is treated as missing; react and similar packages read zero on the same days. The current day is incomplete and is left out.

gap(d) ⇔ Σₚ npm(p, d) = 0

Two registries

Days missing on npm are filled from npmmirror, scaled by the ratio of the two over the surrounding 14 days.

n̂(d) = m(d) · Σ n(j) / Σ m(j), |j − d| ≤ 14

Automated downloads

Each release draws about 136 downloads from mirrors and scanners (Tenable, 2026). Ongoing downloads of old versions are estimated from the median weekly count of stale versions.

noise = 136 × publishes + median(stale weekly) × versions

First-time installs

dsh-mnemon pins 17 sub-packages to exact versions, and pnpm downloads each version once. For a sub-package with no release in 7 days, daily downloads equal first-time installs.

F(d) = median(quiet sub-package downloads − noise)

Active installs

After a sub-package bump, every active install downloads the new version once as it updates. Subtract the fresh-install baseline, accumulate, and fit a saturating curve; its plateau is the number of installs that took the update. This method is our own.

C(t) = A · (1 − e^(−t/τ)), half-life = τ · ln 2

Estimated users

CI, containers and multiple machines per person cannot be observed, so they are adjustable ranges propagated by Monte Carlo. Default automation share: 5–30%, against 10–50% reported on PyPI.

users = A · (1 − automation) / installs per person

Trend and mix

Weekly growth uses the Theil–Sen slope; when its interval spans zero the page shows "no clear trend". Platform mix comes from the CLI's platform packages.

growth = exp(median pairwise slope) − 1

Limitations

Downloads count package stores, not people.
Host upgrades can reinstall plugins; affected waves are flagged.
npmmirror days follow China Standard Time, so single days can be offset from npm by 8 hours.
Updates more than 7 days after a release count as fresh installs.
Automated downloads per release use an outside measurement.
npm only provides per-version counts for the last 7 days.

Reproduce

$ git clone https://github.com/mnemon-dev/mnemon-fe && cd mnemon-fe

$ npm install

$ npm run metrics

$ npm test

References15

Missing daysL. Voss, “Numeric precision matters: how npm download counts work,” npm blog, 2014
Missing daysnpm, download counts API (endpoints, limits, processing)
Two registriescnpmcore (npmmirror), downloads controller
Two registriesW. G. Cochran, Sampling Techniques, 3rd ed., Wiley, 1977 — ch. 6, ratio estimators
Automated downloadsTenable, “How cyberattackers inflate malicious package npm download counts,” 2026
First-time installspnpm, “Motivation” — the content-addressable store downloads each version once
Active installsA. Decan, T. Mens, E. Constantinou, “On the evolution of technical lag in the npm package dependency network,” ICSME 2018
Active installsT. Duebendorfer, S. Frei, browser update adoption 21 days after release, 2009
Active installsB. Efron, “Bootstrap methods: another look at the jackknife,” Annals of Statistics 7(1), 1979
Estimated usersJCGM 101:2008, propagation of distributions using a Monte Carlo method
Estimated usersPython discourse, “PyPI downloads statistics and continuous integration” (CI shares of 10–50%)
Estimated usersTor Metrics, estimating users from directory requests (reproducible metrics)
Estimated usersDask, “Estimating users,” 2020
Trend and mixP. K. Sen, “Estimates of the regression coefficient based on Kendall’s tau,” JASA 63(324), 1968
Trend and mixA. Zerouali et al., “On the diversity of software package popularity metrics: an empirical study of npm,” SANER 2019