It starts the same way every time. You push a new version of an open-source library. You run the tests. You write the release notes. Then you refresh the page. Nothing. Refresh again. Still nothing. You start to wonder: does anyone actually use this?
That quiet vulnerability is the secret engine of open-source maintenance. We publish into the void, and we refresh hoping for a signal — any signal — that someone out there is running our code. I felt it acutely when I was working on a few projects scattered across PyPI, crates.io, and Homebrew. I wanted to know if anyone was downloading them. So I built Secchi: a terminal tool that pulls package intelligence from every major package manager into one command.
It worked. It showed me download counts, trends, adoption curves. I felt a rush of validation. Then I looked closer, and the rush turned cold.
Most downloads are bots, mirrors, and CI pipelines. The numbers you’re refreshing on are a noise floor, not a signal. A single CI pipeline can rack up a thousand downloads in a day. A mirror sync can flood your stats. When I built Secchi, I was making it easier to see a lie — a prettier dashboard for vanity metrics.
This is the trap we all fall into. Package managers were designed to make distribution standard and easy. They succeeded. But in doing so, they fragmented the usage data that tells maintainers whether their work matters. We had to build a tool to unify that data, but the data itself is broken. Download counts are an incentive structure, not a measure of value. They reward the loudest repo, the one with the most CI pings, the one that gets mirrored on every continent — not the one that solves a real problem for a small, grateful audience.
I’m not saying Secchi is useless. It’s genuinely useful for seeing trends relative to your own past releases, or for spotting sudden spikes that might indicate a breaking change. But the moment you start comparing your download count to another project, you’ve already lost. The easiest number to track is the most dangerous one to optimize for.
Here’s what I wish someone had told me before I started building: the real question isn’t how many people downloaded my package. It’s how many people came back to thank me, file an issue, or contribute a fix. Those are the signals that matter. They’re harder to measure, they don’t fit in a terminal table, and they don’t make you feel good instantly. But they’re the only numbers that represent actual human beings using your work.
Secchi closes a feedback loop that open-source maintainers badly need — but it also reveals how hollow that loop can be. We built a tool to see who’s using our code. What we really wanted was proof that we matter. And that’s a problem no command-line tool can solve.
So go ahead, install Secchi. Run it. Look at your downloads. Then close the terminal and ask yourself: what would it take to get one genuine thank-you message instead of a thousand bot pings? That’s the metric worth optimizing for.
FAQ
Q: Doesn't this tool just give you more data to obsess over?
A: Yes, if you let it. The tool itself is neutral — it's a mirror. If you're prone to refreshing download counts, this will make it easier. But the real value is in using it to spot anomalies, not to compare yourself to others.
Q: Should I still use Secchi as a maintainer?
A: Definitely, but with a clear head. Use it to see trends over time for your own packages, not to measure your worth. It's a diagnostic tool, not a validation machine.
Q: Is ignoring download counts entirely the better approach?
A: Partly. The contrarian take is that the best open-source projects are built by people who don't care about the numbers at all. But that's easier said than done. The healthy middle is to track metrics that reward impact, not just activity — like issue engagement, pull requests, and user testimonials.