The recent monetization strategy for Maven Central has been bizarre.
First it seemed like they want to encourage reducing usage (release sizes and file counts), which is fair. It would still be better focus on improving the default tooling to not producuce 10x checksum files with each artifact, and 6MB+ javadoc bundles that no-one reads, but that's a little beside the point.
Then they started requiring paid plans for _all_ publishers that are not purely community projects. Doesn't matter how open it is, if it's backed by a commercial company, they require a paid plan.
Now, in principle I don't mind paying for usage. But they promised self-serve signups before the limits are applied, which didn't happen - still no self-serve plans available. And the "contact us" pricing is too a large extent based on _popularity_ of the package. And not in a quantifiable way like "x GB downloaded", but rather "within the top 2% of usage" (by whatever hidden metric).
So if they lose half their publishers because they don't want to pay, it means I'll automatically be in a higher bracket next year, even if nothing changed on my side?
And the pricing ends up in a couple thousand $ per year, for something that would have been single-digit dollars when self-hosting on S3. When their main value add over that is that Maven Central is automatically present in user config.
"Now, in principle I don't mind paying for usage. But they promised self-serve signups before the limits are applied, which didn't happen - still no self-serve plans available. And the "contact us" pricing is too a large extent based on _popularity_ of the package. And not in a quantifiable way like "x GB downloaded", but rather "within the top 2% of usage" (by whatever hidden metric)."
-> This too is also factually incorrect. Self service rolled out on 10/1 along side the new updated limits that had a -30 day- grace period reset for everyone. So minimally you had 30 days before anything would be impacted...we are still at day 19 so no one has been impacted at all yet. The actual grace periods don't start until you go over the monthly limits so practically speaking it would take a few months before most things would have any impact.
> The recent monetization strategy for Maven Central has been bizarre.
Well, someone gotta pay the bills and it is not surprising given that they began to squeeze Sonatype Nexus operators for money a few years ago.
The core problem is that sooooo much of the core infrastructure we assume as "given" is in fact not owned and operated by a non-profit NGO (such as e.g. Codeberg is) but by a commercial company.
Sonatype operates Maven Central, NuGet, Github and NPM are run (into the ground) by Microsoft, Gitlab is funded by its commercial arm and, assumedly, a lot of venture capital that eventually wants to be returned to the investors, Sourceforge always was infamous for how they monetized (while the majority of the actual hosting cost was borne by universities LOL). The only major artifact repository I'm aware of that is not backed by either big corporate or NGOs and not tied to some Linux distribution is PHP Composer's Packagist that has a commercial arm, but no venture capital.
And in the end, the real issue at the root is that internet traffic, especially egress traffic, still is absurdly expensive, and the behavior of people like Sam Altman that sent RAM, SSD and even HDD prices through the roof is making the situation even worse.
So, so much negative side effects have been caused by just this one human. Sam Altman is nothing short of Thomas Midgley Jr.
>And in the end, the real issue at the root is that internet traffic, especially egress traffic, still is absurdly expensive, and the behavior of people like Sam Altman that sent RAM, SSD and even HDD prices through the roof is making the situation even worse.
The core problem is that dependencies don't really scale. Find a security issue in one dependency? It has to be updated. All the projects which depended on it need to be updated. Turtles all the way down. AI worsened this further by accelerating the churn with vulnerability scanning. Naturally, they focus on the core projects like apache-commons which fans out to basically everything in the Java universe. Which means maven central becomes overloaded and now needs to make emergency changes to stay solvent.
long-time java dev and did a portion of my startup on dial-up. they've been hostile to any attempt to optimize for bandwidth for a very long time - i had elaborate hoops i jumped through to implement caching that should have been baked in to the tooling
I've been a user of the Java/Maven ecosystem for decades. Maven has had local caching of artifacts for as long as I can remember, and there are several ways to set up a private repository mirror for caching and reproducibility.
The interests of the Maven project (i.e. the Maven community), Sonatype and other actors in the space are not necessarily aligned.
But I do wonder where you had to jump through hoops? A basic Squid caching proxy should be enough at least for a pure pull-through like Maven Central. Once you have to publish stuff, okay, that is messy, you won't get anywhere with just Squid there.
> I would assume they primarily serve static files that can be on a cdn
And someone gotta pay that CDN bill too.
On top of that come all the requests from CI pipelines that don't have a repository proxy at all or have it misconfigured, the AI scrapers and other bots, or DDoS skiddies wanting to take responsibility for taking down a major hoster.
I don't know what Cloudflare's economics are like, but R2 egress is free. You pay for storage and $0.36/million for cache misses, which should be a fairly small percentage.
If I had to build a public artifact repository today, that's what I would use. Apparently Maven Central is built on S3 and Fastly. We don't know the terms, but I'm guessing that is more expensive.
Unless you truly self-host, get your own ASN and do your own peering, you most likely pay egress. But that's not to say this is the only way to operate, if you manage your own ASN and peering, you stop paying per TB transferred and start paying for available bandwidth instead.
Given the technical chops, it wouldn't be impossible to actually run a FOSS non-profit for hosting FOSS packages and libraries.
"Then they started requiring paid plans for _all_ publishers that are not purely community projects. Doesn't matter how open it is, if it's backed by a commercial company, they require a paid plan."
This is factually incorrect and has been documented and discussed many times. The issue at hand is if something is open source vs "open source" but is really a free to paid go to market motion. This includes "open source" sdks that are only really used to build products against a paid commercial service.
We spend great time and care assessing each situation and discussing the results with the companies engaged with us to reach a fair conclusion.
If you think we got something wrong here, all you have to do is reach out and we are happy to walk you through what we see and drive to resolution.
Ugh. Trying to get something running with openRewrite at work.
A private, authenticated repo is going to be a spanner in the works since now it means setting up and maintaining custom stuff in Artifactory, and getting that sponsored.
The recent monetization strategy for Maven Central has been bizarre.
First it seemed like they want to encourage reducing usage (release sizes and file counts), which is fair. It would still be better focus on improving the default tooling to not producuce 10x checksum files with each artifact, and 6MB+ javadoc bundles that no-one reads, but that's a little beside the point.
Then they started requiring paid plans for _all_ publishers that are not purely community projects. Doesn't matter how open it is, if it's backed by a commercial company, they require a paid plan.
Now, in principle I don't mind paying for usage. But they promised self-serve signups before the limits are applied, which didn't happen - still no self-serve plans available. And the "contact us" pricing is too a large extent based on _popularity_ of the package. And not in a quantifiable way like "x GB downloaded", but rather "within the top 2% of usage" (by whatever hidden metric).
So if they lose half their publishers because they don't want to pay, it means I'll automatically be in a higher bracket next year, even if nothing changed on my side?
And the pricing ends up in a couple thousand $ per year, for something that would have been single-digit dollars when self-hosting on S3. When their main value add over that is that Maven Central is automatically present in user config.
"Now, in principle I don't mind paying for usage. But they promised self-serve signups before the limits are applied, which didn't happen - still no self-serve plans available. And the "contact us" pricing is too a large extent based on _popularity_ of the package. And not in a quantifiable way like "x GB downloaded", but rather "within the top 2% of usage" (by whatever hidden metric)."
-> This too is also factually incorrect. Self service rolled out on 10/1 along side the new updated limits that had a -30 day- grace period reset for everyone. So minimally you had 30 days before anything would be impacted...we are still at day 19 so no one has been impacted at all yet. The actual grace periods don't start until you go over the monthly limits so practically speaking it would take a few months before most things would have any impact.
> The recent monetization strategy for Maven Central has been bizarre.
Well, someone gotta pay the bills and it is not surprising given that they began to squeeze Sonatype Nexus operators for money a few years ago.
The core problem is that sooooo much of the core infrastructure we assume as "given" is in fact not owned and operated by a non-profit NGO (such as e.g. Codeberg is) but by a commercial company.
Sonatype operates Maven Central, NuGet, Github and NPM are run (into the ground) by Microsoft, Gitlab is funded by its commercial arm and, assumedly, a lot of venture capital that eventually wants to be returned to the investors, Sourceforge always was infamous for how they monetized (while the majority of the actual hosting cost was borne by universities LOL). The only major artifact repository I'm aware of that is not backed by either big corporate or NGOs and not tied to some Linux distribution is PHP Composer's Packagist that has a commercial arm, but no venture capital.
And in the end, the real issue at the root is that internet traffic, especially egress traffic, still is absurdly expensive, and the behavior of people like Sam Altman that sent RAM, SSD and even HDD prices through the roof is making the situation even worse.
So, so much negative side effects have been caused by just this one human. Sam Altman is nothing short of Thomas Midgley Jr.
I think their point is that there are better options than this, not that Maven Central just shouldn't pay the bills at all
>And in the end, the real issue at the root is that internet traffic, especially egress traffic, still is absurdly expensive, and the behavior of people like Sam Altman that sent RAM, SSD and even HDD prices through the roof is making the situation even worse.
The core problem is that dependencies don't really scale. Find a security issue in one dependency? It has to be updated. All the projects which depended on it need to be updated. Turtles all the way down. AI worsened this further by accelerating the churn with vulnerability scanning. Naturally, they focus on the core projects like apache-commons which fans out to basically everything in the Java universe. Which means maven central becomes overloaded and now needs to make emergency changes to stay solvent.
long-time java dev and did a portion of my startup on dial-up. they've been hostile to any attempt to optimize for bandwidth for a very long time - i had elaborate hoops i jumped through to implement caching that should have been baked in to the tooling
this is just chickens coming home to roost
I've been a user of the Java/Maven ecosystem for decades. Maven has had local caching of artifacts for as long as I can remember, and there are several ways to set up a private repository mirror for caching and reproducibility.
The interests of the Maven project (i.e. the Maven community), Sonatype and other actors in the space are not necessarily aligned.
But I do wonder where you had to jump through hoops? A basic Squid caching proxy should be enough at least for a pure pull-through like Maven Central. Once you have to publish stuff, okay, that is messy, you won't get anywhere with just Squid there.
> internet traffic, especially egress traffic, still is absurdly expensive
Are they paying for significant egress? I would assume they primarily serve static files that can be on a cdn
> I would assume they primarily serve static files that can be on a cdn
And someone gotta pay that CDN bill too.
On top of that come all the requests from CI pipelines that don't have a repository proxy at all or have it misconfigured, the AI scrapers and other bots, or DDoS skiddies wanting to take responsibility for taking down a major hoster.
I don't know what Cloudflare's economics are like, but R2 egress is free. You pay for storage and $0.36/million for cache misses, which should be a fairly small percentage.
If I had to build a public artifact repository today, that's what I would use. Apparently Maven Central is built on S3 and Fastly. We don't know the terms, but I'm guessing that is more expensive.
> I don't know what Cloudflare's economics are like, but R2 egress is free.
Cloudflare is not profitable [1], and has collected about 2 billion $ of external funding [2] in 16 years that eventually wants to be paid back.
I would not trust any business on the assumption Cloudflare keeps their stuff available for free. The enshittification and squeeze part is inevitable.
[1] https://www.wsj.com/market-data/quotes/NET/financials/annual...
[2] https://tracxn.com/d/companies/cloudflare/__IL42hIOXmhTb0V8O...
Hey, what if we had a Maven tax if our repo was in Java, and an NPM tax for repos in NPM, for a centrally-managed repo with vulnerability checks?
Unless you truly self-host, get your own ASN and do your own peering, you most likely pay egress. But that's not to say this is the only way to operate, if you manage your own ASN and peering, you stop paying per TB transferred and start paying for available bandwidth instead.
Given the technical chops, it wouldn't be impossible to actually run a FOSS non-profit for hosting FOSS packages and libraries.
"Then they started requiring paid plans for _all_ publishers that are not purely community projects. Doesn't matter how open it is, if it's backed by a commercial company, they require a paid plan."
This is factually incorrect and has been documented and discussed many times. The issue at hand is if something is open source vs "open source" but is really a free to paid go to market motion. This includes "open source" sdks that are only really used to build products against a paid commercial service.
We spend great time and care assessing each situation and discussing the results with the companies engaged with us to reach a fair conclusion.
If you think we got something wrong here, all you have to do is reach out and we are happy to walk you through what we see and drive to resolution.
--Brian (cofounder/CTO Sonatype)
Ugh. Trying to get something running with openRewrite at work.
A private, authenticated repo is going to be a spanner in the works since now it means setting up and maintaining custom stuff in Artifactory, and getting that sponsored.
The project will publish the artifacts in a private repository now, you need to register in order to get an access token
Uhm... feels a bit like closing down?