← KiCadRoutingTools

KiCadRoutingTools — reach

drandyhaas/KiCadRoutingTools · collected 2026-09-17T11:38:45+00:00 · rebuilt weekly from GitHub's API

Downloads by release

Estimated rate, not a measurement — yet. A release's counter is cumulative and never stops rising, and PCM piles every install onto whichever release it points at, so the raw numbers are three towers and thirty-six stubs. Here each release's lifetime total is spread evenly across the days since it was published and the contributions are summed, which makes a release that gathered 4,000 installs over a month read as ~130/day rather than one spike. Even spread is an assumption, and it is wrong in a known direction: downloads arrive fastest just after a release and taper, so the start of each plateau is understated and the tail overstated. It is temporary — once two weekly snapshots exist, differencing them gives the real per-period rate with no assumption at all. The upward slope is partly an artifact of the method for the same reason: every release ever published keeps contributing to every later day, so the total rises as the catalogue grows even if interest is flat. Read the SHAPE of the plateaus, not the trend. Exact per-release totals are in the table below; the two series are still never added together.

Daily views and clones

Uniques are not additive. GitHub reports a unique count per day, and the same person on two days counts twice in any sum of them — so the card above says “unique-days”, not “people”. Only the daily figures are true uniques.

Weekly activity

The newest week is almost always partial, and a partial week always looks like a collapse — so the day count is shown whenever it is under seven, and the week-over-week column is withheld rather than computed against a stub. Lifetime since collection began (16 days banked): 3,194 clones, 4,626 views. These totals only ever grow from here — the days before the first snapshot are gone from GitHub and cannot be recovered.

Manual vs automated clones

There is no way to count human clones, only to estimate them. GitHub reports a count and a unique count and nothing else — no user agent, no IP, no actor — so any figure here claiming to be “people” would be invented. Unique cloners is the closest proxy, because a person clones once or twice while an automated fetcher clones repeatedly from few addresses; the ratio is therefore an automation index, not a headcount. Ordinary days sit near 1.4–1.9. The peak in this window is 4.26 on 2026-09-04 — a release day, at 528 clones against only 281 views: machines, not readers. This project's own CI is not the explanation and is not subtracted: a release run is seven jobs, so about seven checkouts against a spike of several hundred. The excess is other people's automation — downstream CI, mirrors, release trackers — which no API available here can identify, so it is disclosed rather than adjusted by a correction that would explain about 1% of it.

Downloads per release

PCM and binaries are different audiences and are never summed. KiCad's Plugin and Content Manager fetches the zip from whichever release it currently points at, so PCM installs pile up on that one release and a newer release showing few zip downloads means PCM has not been pointed at it — not that interest collapsed. The grid_router-* binaries are fetched by build_router.py, so they count from-source installs, including this project's own CI: every Modal image build downloads the Linux binary, which makes Linux an upper bound rather than a user count.

New downloads between snapshots

Platform mix

Where visitors come from

What this cannot tell you

A download is not a run. Nothing here distinguishes one person routing daily from a hundred who installed once and never opened it again, and nothing here reports a crash, a failed route, or which KiCad or Python version anyone is on. This project collects no telemetry, so those questions stay unanswered by design. What these numbers are good for is reach, platform mix, release adoption and trend — and for noticing when a week goes unexpectedly quiet.