ZDNet's report on roughly 10 trillion open-source downloads last year is a reminder that package repositories have become core internet infrastructure, and Sonatype CTO Brian Fox says the real pressure is not from ordinary developers but from commercial-scale automated pulls that turn registries like Maven Central into an unpaid CDN for the largest companies.
The scale is hard to absorb until you put the numbers next to each other. Sonatype's research says yearly open-source downloads surpassed 9.8 trillion in 2026, while Fox's analysis of Maven Central found that 82% of consumption came from less than 1% of IPs. That is not normal developer usage. That is industrial-scale traffic created by CI/CD pipelines, security scanners, cloud build systems, dependency refresh jobs, and AI-assisted coding tools that repeatedly pull the same artifacts over and over. Once you see it that way, package repositories stop looking like a free utility and start looking like a subsidized infrastructure layer that the biggest users have treated as someone else's bandwidth bill.
Fox's framing is blunt because the underlying problem is blunt. Maven Central was built as a commons for software distribution, not as a substitute for a content delivery network. But many companies have been using it exactly that way. The logic is easy to understand in the moment. If a build system can reach the registry directly, why bother paying to mirror artifacts, cache them locally, or tune your dependency flow? The answer is that the cost gets externalized to everyone else. The repository has to absorb the repeated pulls, the bandwidth spikes, the operational wear, and the security burden that comes with being a critical public dependency source. Fox has described the pattern as a tragedy of the commons, and that is exactly what this is. The shared resource is being consumed by users who are large enough to engineer around it, but not motivated enough to pay for the load they create.
The AI layer makes the situation more acute. AI coding tools tend to be chatty with build systems and repositories because they generate more scaffolding, more tests, more temporary branches, and more dependency churn than a human developer working manually. Security scanners and automated remediation bots also multiply traffic because they recheck the same packages across multiple environments. In a modern cloud-native organization, one code change can trigger a cascade of builds, scans, and artifact lookups across different services and regions. Each of those events might be small on its own, but at enterprise scale they compound into the kind of load that shows up in the statistics Fox is citing. The open-source ecosystem is now carrying the hidden cost of AI acceleration, whether or not the users generating that traffic are consciously thinking about it.
That is why the pricing question matters. One obvious model is to keep downloads free for individual developers while charging heavy commercial users for large-scale or repeated retrievals. That sounds fair because it preserves the open-source bargain for people using the commons as intended, while asking the largest automated consumers to pay for the infrastructure they are effectively monopolizing. It also aligns with how most real-world utilities work. Small users subsidized by broad access, large users paying for volume. The objection is that package repositories are not simple SaaS products, and any form of throttling or tiered pricing risks breaking existing build pipelines if implementation is clumsy. But the alternative is that maintainers and repository operators keep absorbing the cost until service quality degrades for everyone.
For founders, the practical response is not philosophical. It is operational. If your company depends on open-source registries for every build, you should already be budgeting for repository mirroring, dependency caching, and artifact governance. That means using internal proxies or local caches so that repeated builds do not keep hitting the public registry. It means cleaning up dependency sprawl, reducing redundant scanners, and controlling which tools are allowed to pull directly from upstream. It also means asking a very unsexy question during planning: what happens if the registry slows down or starts charging? Teams that cannot answer that question are already vulnerable. Their build systems are only cheap because someone else is still paying the bill.
The bigger implication for San Francisco readers is that software supply chains are no longer just a security problem. They are an economics problem. When every AI coding assistant, every CI pipeline, and every cloud-native build increases dependency traffic, the hidden commons becomes part of startup burn. That matters for margins, for reliability, and for strategic independence from the major labs and cloud providers whose tools now drive so much of the traffic. It also means the next generation of infrastructure startups has an opening. Anything that improves artifact caching, dependency policy, internal distribution, or build efficiency is no longer a nice-to-have. It is a direct answer to the economics of modern software development. The companies that treat open-source consumption as free will eventually pay for that assumption in throttling, outages, or surprise infrastructure costs. The companies that plan now will keep shipping when the commons finally decides to stop being free for everyone all the time.
Also read: 2.5x faster local inference on 48GB of VRAM is starting to make the case for replacing hosted APIs • Hut 8's $9.8 billion Texas lease shows ex-bitcoin miners are becoming AI landlords • Bristol Myers Squibb shows why pharmaceutical factories are ahead of the rest of American manufacturing on AI
