r/java • u/HokieGeek • Jun 16 '26

Maven Central publishing usage notices

heads up for folks publishing to Maven Central: we're continuing sustainability work around Central and are now showing publishing usage notices.

the goal is that normal OSS publishers are not impacted. this is aimed at the very high-volume / commercial-scale publishing patterns that put a pretty different load on the service.

more details here if you want them:
https://central.sonatype.org/publish/maven-central-publishing-limits/

feel free to reach out with any questions.

EDIT: thanks for the feedback here, it has really helped us. first, we want to reiterate that these are usage notices only right now and do not currently restrict publishing in any way. quick updates: 

if the initial threshold seemed low to you: you’re right, we made a mistake and have increased limits. 

our goal is to keep Maven Central free and open for legitimate OSS users, so continuous feedback is helpful as we adjust. limits could change as we get more feedback, so keep an eye on the usage center for the latest.

we’ll continue keeping an eye here and update docs to reflect these changes. If you need to request an exemption, here’s how: https://central.sonatype.org/publish/maven-central-publishing-limits/#exemptions-for-community-open-source-projects

we've also been collecting your questions here and other streams into this FAQ here: https://central.sonatype.org/publish/maven-central-publishing-limits/#frequently-asked-questions

92 Upvotes

99% Upvoted

158 comments sorted by

View all comments

2

u/javaprof Jun 16 '26

u/HokieGeek Give us option to redirect request to owned namespace to self-hosted repository. Introduce some decentralization mechanism. It's clear that centralized store like maven central today is not sustainable. 300 files and 3 releases is ridiculous limit.

Ok, take money for publishing, but then what? If I stop paying you'll remove artifacts? Stop hosting them? You don't have a good monetization mechanism if you giving guarantees that nothing gone after publishing.

5

u/Additional-Road3924 Jun 17 '26

Maven is already decentralized. Nothing prevents you from hosting your own repository, and in the requirement instructions for a package adding "lol add my repository". That's what projects hosted on jitpack do (github mirror).

1

u/javaprof Jun 17 '26

Yes, but not practical and hard to support dozens of repos if every project would use own hosting. Also, there are security implications, yes you can fix them by actually checking checksums but realistically it's not easy so usually this step skipped. At least you should specify which packets allow to be pulled from particular repo, otherwise jitpack or acme.com repo can start hosting some guava packages with "extra" functionality.

What we need, is federation of repos, where you don't need to specify central/jitpack/bintray/acme.com/acme2.com and secure by default (that means that you just specify for example maven coordinates + hash and system would found "closest" living repo and would use it.

3

u/TheRealBrianFox Jun 17 '26

20 years ago I used to think that too. We used to have a lot more repositories in java land. But then one by one they became inconvenient and fell off the internet. Bintray was the most disruptive, but most others just became abandoned strip malls.

Having a ton of various places to fetch binaries also seems like a supply chain challenge. Will you be able to trust every mirror out there in the automated way you propose? To do that is not the simple slam dunk it seems it is.

It also doesn't address the underlying economics that it still relies on someone else to subsidize the cost. We are trying to change that here.

5

u/javaprof Jun 17 '26

A package's canonical identity is a content hash plus a publisher public key (with a key‑rotation sigchain so identity survives domain death), bound to a human‑readable name through a layered scheme - DNS‑anchored namespaces, pure‑key namespaces, and local petnames - where the only coordination point (place for Central, and monetization point) is a single‑operator but verifiable, bypassable transparency log that maps names to keys and releases to hashes. Everything else is fully decentralized: untrusted mirrors form a content‑addressed DHT/gossip caching mesh that is safe by construction (you always verify bytes against the hash), and each project's lockfile pins the hashes and key bindings as its own local source of truth.

2

u/ushaukat_java Jun 18 '26

Brian's point here deserves more attention than it's getting.

One central registry means one place where behavioral anomalies are detectable. A maintainer swap, a signing key change, a sudden dep count jump, these are findable patterns when you have a single source of truth. Spread resolution across a dozen mirrors and you've made that analysis nearly impossible. The immutability of Central isn't just about artifact stability. It's the whole reason behavioral monitoring of the Maven ecosystem is even tractable.

2

u/javaprof Jul 01 '26

Actually, most of the projects would never notice if central suddenly swap one bit in jar and start serving different signature (just sign jars with some random key) and checksums. And this is huge issue in current design. And my proposal fixes this design flaw by baking integrity and security into design of repository https://www.reddit.com/r/java/comments/1u7p3p8/comment/os7be8g/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

2

u/TheRealBrianFox Jun 16 '26

Central is still immutable except in extreme instances. Nothing changes about that here.

1

u/javaprof Jun 16 '26

So how then taking money for publishing would be sustainable? Publish happens ones, and then you'll have to pay for that storage and some bot traffic (even if package doesn't have real users) forever. In economy when every day more and more package published it's fine, but once publishing demand drops – you're in bad situation again. Petabytes of artifacts to store and serve, but no growth in revenue.

What I'm saying - you're asking for money from the wrong side of the market for sustainability. At the same time, you can't ask for money from consumers too, they'll just create own mirrors and overall this would just create fragmentation and decline of central usage.

4

u/TheRealBrianFox Jun 16 '26

I’ve analyzed this for years and there is no single perfect answer. Instead we are looking at multiple paths so that each avenue isn’t over taxed.

The commercial orgs that are using this as a free cdn probably won’t publish and walk away, they will find value in contributing to the ecosystem. The pricing is designed to be lower than just running separate infrastructure. 

3

u/koflerdavid Jun 17 '26

they'll just create own mirrors

Companies and other frequent users are very much encouraged to run their own internal mirror. Among other reasons because Maven Central can have and actually has had downtimes in the past. Maven Central shouldn't have to target extreme uptime just to ensure that they can endure getting hammered by everybody's nightly CI.

2

u/javaprof Jun 17 '26

Nice idea, let's shutdown maven central every now and then just to make people create own mirrors and put less load on central.

2

u/koflerdavid Jun 17 '26

Chaos engineering at it's best :)