Recipes Are Moving from Maven Central to the Code Genome Project

matharmin 7 hours ago | parent | next [-]

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.

▲

mschuster91 5 hours ago | parent [-]

> 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.

▲

onionisafruit 5 hours ago | parent | next [-]

> 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

▲

mschuster91 4 hours ago | parent [-]

> 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.

▲

stickfigure 3 hours ago | parent [-]

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.

	▲	eastbound 2 hours ago \| parent [-]
		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?

▲

LoganDark an hour ago | parent | prev | next [-]

I think their point is that there are better options than this, not that Maven Central just shouldn't pay the bills at all

▲

panny 2 hours ago | parent | prev [-]

>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.

	▲	nqzero an hour ago \| parent [-]
		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

▲

andylynch 38 minutes ago | parent | prev | next [-]

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.

▲

javahippie 2 days ago | parent | prev [-]

The project will publish the artifacts in a private repository now, you need to register in order to get an access token