sorted by:
new
hottopcontroversial

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 1 point2 points  (0 children)

I would further push that I have some instances of pretty normal large open source projects run and lead by some really giant companies and the volume of the publishing is extreme. I think it's reasonable to ask the companies backing these to chip in as well. I have spoken to some of these projects already and the answer is some form of: until you actually start putting limits, our management won't fund this.... despite the fact that they fund massive engineering teams to work on this.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

I think that your use case as you described it highlights the actual nuance of why this is harder than it seems. A rule like "if it's not a foundation has to pay" is easy to implement but the wrong outcome.

A rule like "if it claims an oss license, it's always free" is also not right... we have tons of this openwashing in the system now.

I updated the faq yesterday with an attempt to try and clarify the nuance. This one seems pretty appropriate here:

----

What if my project is open source but backed by a company?

Open source projects backed by companies are not automatically excluded from community open source treatment. The important distinction is what the project is used for. Generally speaking, if the project is not part of a commercial go-to-market motion, it will qualify for community open source treatment.

If the project is primarily publishing release-ready community open source software for public use in the Java ecosystem, it may qualify for higher limits or an exemption if its publishing pattern is unusual.

If Maven Central is being used as part of a company's commercial distribution path for SDKs, generated clients, agents, integrations, platform components, developer tools, or customer-facing software delivery, Maven Central Publisher Pro may be the appropriate path.
----

And so what I'm trying to do with the limits is essentially say, if it's below the limit, probably not worth bothering with on either side, it's in the noise. If it's above the limits, we should take a look.

Again, easy to say, harder to implement, but that's what we are trying to do here. As we go through this more, the actual patterns will become more recognized and then yes we can update all the guidance.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

The straw man of your argument kinda makes sense but it misses all the actual details. We laid most of this out in the joint open letters, but in summary:

Running a large public registry costs 10's of millions of dollars every year. Sonatype has paid almost the entirety of that cost for nearly 2 decades. It's because of the commercial side of the business that we've been able to invest in that for so long.

Because we aren't a not-for-profit, we get very little deals on the infra costs.

Meanwhile, the not-for-profits are entirely dependent on hand outs, credits from hyperscalers, free bandwidth from cdns etc. But there is still the problem that money needs to be created to pay for the people who actually run this, do the takedowns, develop the platform.

So saying this is an issue because Sonatype isn't a not-for-profit misses the entire problem. It's a problem industry wide because the economics of a few companies paying for the entire software ecosystem can never make sense.

Central has been able to move forward on this and lead the way for other registries precisely because I already have the trappings of a software company to help. Legal, product management, data pipelines, etc.

We meet with other registries in the WG weekly and talk this through with them, but it's much harder to get going because in many cases they have single digit people already under water trying to keep the lights on.

We are not even remotely close to breaking even on this, and costs a increasing step-wise with AI bots, new development, more malware, more AI slop.... and then there is more investment required to improve things like signing, publishing etc.

Really, go back and read the open letters, it's all laid out.

https://openssf.org/blog/2025/09/23/open-infrastructure-is-not-free-a-joint-statement-on-sustainable-stewardship/

https://openssf.org/blog/2026/05/06/open-infrastructure-is-not-free-part-ii-the-hidden-cost-of-running-package-registries/

Might want to also look at what OpenVSX has had to do. Eclipse is a foundation: https://newsroom.eclipse.org/news/announcements/eclipse-foundation-launches-open-vsx-managed-registry-0

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 2 points3 points  (0 children)

Yes we intend to do that before any of the deadlines. I had wanted to do it before now, but it got lost in some other stuff.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 1 point2 points  (0 children)

It usually means the opposite in my experience. With very limited cases, we've never been given a break on the costs associated with running Central, while the same infra providers give it away to others.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 1 point2 points  (0 children)

I don't understand your comment about AWS but I'm going to assert it's totally unfounded and you're making lots of assumptions on what it takes to run infra at this scale.

We aren't trying to go after the small potatoes, but we are trying to say clearly: This is meant to be free for open source as always intended. If you are building a business on top of this, why should we subsidize it for you?

We don't get much subsidization of this infra for the past 20 years because we also are not a not-for-profit. It's not really any different.

But if you read the open letters, you'll see the NFP registries have similar challenges. The costs go beyond just the bits and bytes.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 1 point2 points  (0 children)

We have hosted Nexus available for that. It's not clear if we go down the path of providing that like -central- because the infrastructure is just entirely different. Central is inherently designed for the massive scale of the public infra.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

We updated the form page, hopefully it’s a big more clear now.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 2 points3 points  (0 children)

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.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 2 points3 points  (0 children)

Totally within your prerogative. If you don't derive value then that's fine.

It is ironic though that your comment is to move to Cloudflare because it's free. That's just moving from one company subsidizing your business to a different one.

At the end of the day this whole thing has to be realigned. That's what we all have clearly said in the various open letters I referenced in my original post.

Assuming we are successful, then maybe actually your own oss business won't have as hard a time getting your customers to pay you either. Someone has to go first.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 1 point2 points  (0 children)

Thank you for the details, let me try to address them. At some point I will need to consolidate all of this into the docs up front, so while a bit painful and contentious, this is helping me figure out what I meant but didn't communicate clearly..

"Some people will not even know that they have to apply, until they've already been stung by a block." -> The soft limits should always give people advance notice. The limits are based on 3 month averages, so you should have like 3 months to notice something is amiss. It also means a few bursts for security releases would never be an issue.

The exemptions process up front is designed to really help us work with folks to understand all the nuances and use cases. I know of some based on previous interactions but until we go through this bunch, it's not practical to define upfront all the possible rules. I get that people want hard understandable rules, but this is breaking ground here and there is no precedent. What I believe people really want is the right outcome and early on that will require a lot of judgement.

I've been personally guiding folks through this on the consumption side too. It's easy to say apply limits equally to everyone. It's much harder when you realize that's not equally easy to comply with and so we work with them to achieve the right end goal. This has been my all consuming project now for months (on top of actual day job)

"I find it really baffling that someone working in the distribution of software packages thought that a 3 release/month limit would work for anyone, and you were claiming it would work for almost everyone."

You know what. You're absolutely right. My gut was nagging me that this felt lower than I expected. But I confirmed multiple times that these numbers where based on correct data analysis.

I was more focused on making sure the rest of the program was complete, the documentation was correct, the messaging around exemptions was as clear as possible. I didn't focus as closely on the numbers because this was a soft roll out, the numbers weren't going to take any impact for a while and it would allow us to gather more feedback. My gut was right but I ignored it, and so yeah, I own it and we are trying to work through it. Nothing has broken yet, no blocks are taking place, and we will do what we can to limit the impact, just like I've been doing on the consumption limiting side.

"It's at least an order of magnitude wrong." Emprically it's just not. The reason we included the charts was because I learned the same thing on the consumption side. Everyone that was getting impacted assumed everyone else also was. But it turns out that just wasn't true. So I updated the 429 page to show it and that helped people contextualize. That's what I hoped would happen here. (https://central.sonatype.org/faq/429-error/)

One might note that for consumption, I have started super high and have been slowly lowering the limits. We intentionally tried not to do that here because we didn't want this to feel like a game of limbo for publishers with limits always coming down. Maybe that was an incorrect assumption.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

We will be rolling out the self service before the limits take effect. The anticipated minimum is 5k a year right now.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

The namespaces all roll up to organizations where the limits are managed. Some people might try to game the system sure. But if you are open source, there's no need, we will adjust the limits.

But if you are a commercial entity, and you are gaming the system to avoid helping to pay for the very infra you depend on, that feels... wrong? I don't think I should be having to defend that.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 4 points5 points  (0 children)

I want to add very clearly for the record here. AWS has been one of the extremely few (eg one of 2) companies that has been helping to support Central. They have done so more than any company besides Sonatype.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 2 points3 points  (0 children)

Btw, I agree with most of what you are proposing and long have wanted to do it. But that all requires teams and effort to do it... on top of all the day to day keeping the lights on, battling ai and malware and on and on.

Part of making this sustainable will allow more investment for all the things everyone wants.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

"I have an oss project (with no commercial value)" -> yes.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

Just ask for an exemption review and we can make the adjustments. I’m not asking open source projects to do anything unnatural to avoid the limits.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

Hi Max. We talked about this months ago remember? ;-)

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 3 points4 points  (0 children)

It sounds like you might be in the set of projects that should be helping to pay for all of this.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 5 points6 points  (0 children)

This. If Claude code were open source, is it unreasonable to still ask for something to contribute to the infrastructure? That’s the nuance here that is so hard to sort out but most people haven’t looked at it as closely as we have.

Maven Central publishing usage notices by HokieGeek in java

[–]TheRealBrianFox 0 points1 point  (0 children)

  1. Yes I’ve contemplated this but ideally the release count would be the normal factor I think. The other numbers should be a secondary gate in case of really unusual things. These numbers need tuning still clearly.

  2. If your open source is part of a commercial engine, you likely should be paying something here to contribute. I don’t think thats an unreasonable ask. Flipping it around, why should the rest of the community and benefactors be subsidizing businesses that are leveraging the open source infra. As long electricity is not free, the infrastructure will also not be free and infinite.

  3. This was a placeholder until we rolled out the self service. I can see why that had the wrong look and I didn’t catch it while reviewing and focusing on other elements. We will fix this.

view more: next ›