Recipes Are Moving from Maven Central to the Code Genome Project
docs.openrewrite.org
docs.openrewrite.org
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.
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.
Are they paying for significant egress? 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.
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.
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...
Given the technical chops, it wouldn't be impossible to actually run a FOSS non-profit for hosting FOSS packages and libraries.
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.
this is just chickens coming home to roost
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.
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)
-> 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.
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.