I've been maintaining open-source tools for years.
For most of that time, I had no idea if anyone was actually using them.
Few stars. Not forks. Downloads — the thing that tells you someone ran your binary at least once.
The problem
GitHub shows download counts per release asset — but only the current total. No history.
- Was there a spike after that blog post you wrote?
- Did your last release get picked up faster than the one before?
- Is your project quietly dying, or just slow to spread?
Stars are worse: people star repos they never use. A project with 500 stars might have 3 regular users.
npm/crates.io/PyPI have their own dashboards — they are nice for libraries and source downloads, but don't show packaged/pre-built release trends and miss the GitHub release binary entirely.
As an OSS maintainer of binary (not library), you're flying blind on actual adoption.
What I wanted
- Historical view: downloads over time, per release
- Trend detection: growing, stagnating, or declining?
- Cross-release comparison: did v0.5.0 get picked up faster than v0.4.0?
- Event correlation: Did that announcement actually move the needle?
- Embeddable: something I can drop into a README
What I built
download-history — polls the GitHub API every few hours, stores daily snapshots, and visualizes trends across releases. Type owner/repo, get charts.
Charts are interactive in the browser. Also available as static SVGs for README embeds — updated daily:
Works for both public and private repositories (requires an access token for private repositories).
14-day free trial, no credit card, no account needed. Then 5€/year for up to 2 repositories.
What I actually learned from my own data
kubectl-view-allocations — my most popular project. Unexplained spike in December 2025 / January 2026. No new release. No announcement. Something spread it — a newsletter, someone's blog post, a company's internal tooling. I have no idea what. Without the historical chart, I'd never have noticed it happened at all. ("All time" starts with data capture)
ffizer — the opposite story. Nearly zero downloads even after new releases. That's not a product problem. That's an awareness problem. Different diagnosis, different
fix.
jdx/mise (not mine, used as reference and because I use it daily) — releases every 1–5 days, used on CI & desktop. Downloads don't spike around releases because users pull it continuously.
Context shapes how you read the charts.
The data doesn't always give you answers. But it gives you better questions.
Closing
If you maintain an OSS project that ships binaries, you probably have the same blind spot.
download-history.cdviz.dev — free 14-day trial, no sign-up. I built it for myself; if it's useful to you too, great.
Next: tracking GitHub Packages (containers, npm, Maven) and possibly GitLab — let me know if that matters to you.
What metrics do you track for your OSS projects? I'm curious what signals actually matter to other maintainers.
Top comments (1)
Actually, download-history is not open-sourced (maybe it will be in the future). It's written in Rust and uses a bucket (object store to store metrics. It can take time to load charts/metrics the first time (browser and server cache are enabled)