This is not just a Maven Central story.

Across open source, public package registries are confronting the same uncomfortable reality: Infrastructure built for community-scale software sharing is now production infrastructure for commercial platforms, automated systems, CI/CD pipelines, scanners, AI-era developer tools, and machine-to-machine workflows operating at global scale.

For years, I have written about this shift through the lens of Maven Central. We first saw it most clearly on the consumption side: enormous volumes of repeated downloads, CI systems pulling the same artifacts again and again, scanners rehydrating dependency trees at industrial scale, and platforms treating Maven Central as if it were an unlimited backend service.

But those investigations were never just internal Maven Central exercises. They became part of a broader conversation among package registry operators and open source infrastructure stewards about what it actually costs to run public infrastructure at modern scale. The OpenSSF joint letters grew out of that shared recognition: across ecosystems, the same patterns were emerging. The old assumption that public registries could absorb unlimited commercial-scale demand without corresponding responsibility was no longer credible.

This is already turning into actions. The Eclipse Foundation recently launched Open VSX Managed Registry, a paid managed service for commercial adopters that need production-grade reliability, defined service levels, and predictable scaling, while preserving free access for individual developers and open source projects.

Maven Central is part of that same industry-wide shift.

For most of its history, Maven Central has run on a simple premise: make Java components broadly available, keep publishing open, and let developers build. That model helped make Maven Central one of the most important pieces of public software infrastructure in the world. It supports millions of developers, millions of components, and the quiet, constant machinery behind modern software delivery.

But open does not mean infinite. And free does not mean costless.

On the consumption side, that reality led us to introduce controls and rate limits, not as punishment, but as a signal that the ecosystem needs to change. When the same artifacts are downloaded millions of times by automation that could have cached them, the problem is not open infrastructure. The problem is a design pattern that treats open infrastructure as someone else's backend.

Publishing Has Its Own Version of the Same Problem

The consumption side of Maven Central made one thing impossible to ignore: scale changes the nature of use. Publishing has the same distinction.

A maintainer publishing normal releases for an open source project is one thing. A large commercial entity using Maven Central as the last-mile distribution channel for SDKs, agents, generated clients, integrations, or other commercial software components is another.

There is nothing inherently wrong with that. Maven Central is valuable precisely because it gives the Java ecosystem a trusted, familiar, broadly adopted distribution path. Commercial organizations publishing useful libraries, SDKs, integrations, and developer tools can create real value for the ecosystem.

But when commercial delivery pipelines use that shared path at very high scale, the cost shifts. Storage, validation, indexing, metadata processing, replication, abuse management, and long-term stewardship all become part of the cost of delivering those commercial offerings.

Historically, that cost has been absorbed by the same commons that supports ordinary open source publishing. That is the imbalance publishing limits are meant to address.

Publishing size and frequency are strong indicators of commercial-scale or infrastructure-driven use. They are not perfect measures of intent and are not meant to punish legitimate open source activity. But they are practical signals that a publishing pattern may be serving a very different purpose than a maintainer releasing an open source library.

The largest publishers are often not hobbyists or small open source projects accidentally crossing a line. They are large organizations using Maven Central as part of their software delivery infrastructure. That can be reasonable, and in many cases it is beneficial.

But if Maven Central is part of a commercial distribution model, then the organizations depending on it at that scale need to help support the infrastructure that makes it possible.

This is less radical than it sounds. It is how most infrastructure works once it becomes important enough. The community path remains open. The commercial-scale path becomes explicit.

What Is Changing

Maven Central is adding publishing usage visibility and limits for high-volume publishing activity. This rollout begins with visibility.

Starting June 16, 2026, some publishers may see informational notifications in Maven Central if their organization is approaching or has reached monthly publishing limits. These notifications are part of a soft-limit phase. They are informational only. They will not block, throttle, or prevent publishing.

This does not start with enforcement. The first step is giving publishers a clearer view of their usage so they can understand their publishing patterns, review their workflows, and plan ahead.

Many publishers publish through build and release tooling and may not regularly sign in to the Maven Central UI. That means usage can grow without anyone having a clear operational picture. The new visibility is intended to close that gap before limits are enforced.

Hard enforcement is scheduled to begin on August 11, 2026. Starting then, organizations above the free publishing limits will have publishing activity capped until usage is reduced, an exemption has been approved, or a paid option is in place.

Most publishers will not need to make any changes.

That bears repeating, because infrastructure changes tend to create understandable anxiety: This is not a blanket fee for publishing to Maven Central.

Maven Central remains free for community open source publishing. The change is focused on organizations with unusually large artifacts, very high publishing frequency, or repeated high-volume publishing activity.

For organizations above the free limits, there are three paths.

First, reduce avoidable publishing activity. Maven Central should be used for public distribution of release-ready artifacts, not as the default destination for every intermediate output produced by a software factory. Avoid publishing every CI build. Move internal-only artifacts to private repositories. Review automation for duplicate or unnecessary publish attempts. If something is not intended for public consumption, Maven Central is probably not the right place for it.

Second, legitimate open source projects with unusual publishing patterns may request an exemption for review. Limits are useful for identifying patterns, but they are not a substitute for judgment. Some real open source projects may have unusual release models, unusually large artifacts, or other characteristics that deserve review rather than automatic classification.

Third, organizations with higher-volume, commercial-scale, or infrastructure-driven publishing needs can move to Maven Central Publisher Pro. Maven Central Publisher Pro provides a paid path for publishing at higher scale while helping support the infrastructure those publishing patterns depend on.

The Larger Point

Rather than making open source smaller, these changes ensure the underlying infrastructure is durable enough to support its continued growth and success at machine speed and scale.

For years, the software industry treated public registries as if they were naturally occurring resources. They are not. They are built, operated, defended, scaled, and maintained. Someone handles the storage growth. Someone handles the abuse. Someone pays for bandwidth. Someone keeps the metadata flowing. Someone makes sure the system is still there when the next build runs.

The commons does not fail because people use it. It fails when use and responsibility become permanently disconnected.

We saw this with consumption, we now see it on the publishing side. And it is the pattern package registries across ecosystems are beginning to address in their own ways.

Maven Central will remain open for ordinary open source publishing. That remains core to its purpose. But commercial-scale publishing through Maven Central cannot continue to be treated as indistinguishable from community-scale publishing simply because both use the same upload path.

Open infrastructure works best when it is open by design, not open by exhaustion.

For important dates, guidance on next steps, and further reading, visit the Maven Central Publishing Limits page: http://central.sonatype.org/publish/maven-central-publishing-limits/.

Publishing limits are one step toward reconnecting use with responsibility.

Further reading:

• The AI Race Is Becoming a Remediation Race

• Public Registries Are Not a Free Extension of Your Internal Platform

• Maven Central and the Tragedy of the Commons

• Beyond IPs: Addressing Organizational Overconsumption in Maven Central

• Free Isn't Free: The Hidden Costs of Tooling Decisions in Open Source Infrastructure

• From Abuse to Alignment: Why We Need Sustainable Open Source Infrastructure

• Open Infrastructure Is Not Free: A Joint Statement on Sustainable Stewardship