To anyone who has Open Source artifacts hosted on Maven Central and who accesses the (awful) Sonatype UI through the https://oss.sonatype.org/ portal. We've been unable to gather download statistics for any of our packages for the entire of last week. I am unable to raise a support ticket with Sonatype because I am not a paying customer 🙄 ( ... which doesn't seem particularly reasonable since they they host the vast majority of JVM OSS ecosystem projects). I want to check if this issue just affects our packages or if it is a more generalised problem for everyone - can people please log in and see if they can see their stats?

Seems to work for me

That's very useful to know. Thanks @CLOVIS 🙃

Works for me too (using s01)

@mbonnin sorry - what's S01?

The “newest” host that is already “kindof” deprecated 😅

ah - ok. we're stuck on the original. I can't even log into s01.

Yea, you have to explicitely request the migration (but these days s01 is deprecated too and portal is the new way)

ah wow - that email would be amazing. It's been an entire week - I've already tried all the other fallbacks (and that's with both of us users 🙂

I’ve had troubles in the past because creating the portal password kindof reset my oss and s01.oss ones

are the stats available on the portal? we've been depending on them for any kind of visibility..

Now I use the password from https://central.sonatype.com/ everywhere and everything works well. central-support@sonatype.com was very helpful debugging this

I'm kind of scared to ask for migration in case things go wrong TBH

Same, I migrated my personnal hobby account but Apollo is still s01

thanks for the help both - have sent an email to central-support@sonatype.com so we'll see where we get to I guess. 🙃

I asked central-support@sonatype.com about the download statistics, and got this reply:

In the process of sunsetting we are stopping support for stats until we are able to migrate the feature over to portal. We are unable to provide an accurate date on when this feature will arrive but we will be making it a priority shortly after the sunset date. we apologize for any inconvenience not having the statistics may cause.

So it looks like there will be a period when nobody has any statistics at all.

Yup, same response I got

> We are unable to provide an accurate date on when this feature will arrive but we will be making it a priority shortly after the sunset date.

I didn't get this bit - which is encouraging. 🙂

One year later, does anyone know if there is something planned for stats or if it’s still unknown? Cannot find anything relevant on the internet…

Take a look at https://kotlinlang.slack.com/archives/C8C4JTXR7/p1763731938945659

Sonatype are partnering with a company called Scarf to provide the stats on an ongoing basis. A few maintainers have been onboarded onto the Scarf platform to check out the stats - we are one of them. Traditionally, Scarf hasn't supported Java packages but this seems to be the first integration point between the 2 worlds.

You can find a few screenshots of what it offers (and our struggling to make sense of it) here: https://kotlinlang.slack.com/archives/C078Z1QRHL3/p1764016873044559

Ohh I’ll have a look at that, thank you!

@Nathan Fallet it's not overly spectacular. The things that we have noticed: • "events" (maybe download numbers?) are higher than the recorded Maven Central numbers • "unique IPs" by contrast seem to be much lower than the recorded Maven Central numbers It's all very spiky and overall I don't really trust it because trying to interpret the numbers is 🤷. The "companies" data especially seems to be highly suspect...

The idea is to follow the growth of some of my open source packages. It’s not about the exact numbers but about the shape of them over time

yes - the general trends are there (or at least were over the period of time where the data overlaps), but it's so ridiculously spiky in a way that we never had with the MC stats.

Vibes 😅

thanks. did they give you pricing for the other plans? And I could only find data going back to may 2024. Did they account for the massive difference in numbers between MC and them? pixels did not exist then... suspect

did they give you pricing for the other plans?

It's quite expensive. The "basic" is at 15k

yes - truly for the open source world

best I can do is 10€

The basic plan still gives you the download data

For that I'm going to continue to harvest and store the data myself

Ah yes, forgot to mention the "companies" you see is sampled based on "first come"

I think they need a bit of a readjustment of expectations - they're asking over 1k a month for some shonky data which they haven't even shown to anyone?

The feeling I got is they are typically designing for marketing teams where I guess those kinds of budgets are maybe more ok-ish and where you track your usage company-wise with pixels, etc...

Sure, but I don't think that's the average Central deployer

Yup

Which is shame, because I'm pretty sure there is no other target in this partnership

So it seems like this a move to make contributors pay on top of their contribution instead of making the high-volume consumers of such contributions pay.

Agreed - this is NOT supporting small open source teams to be able to monetise/support their work

I wouldn't read too much into the why of this partnership. One potential reason is just that scarf has a UI and sonatype outsources to them because it's less work for them.

I'd guess so. Why should Sonatype provide a free lunch to another company selling that lunch? > 83% of the total bandwidth of Maven Central is being consumed by just 1% of the IP addresses. Further, many of those IPs originate from some of the world's largest companies. This needs to be addressed, but definitely in a fair fashion and not by further weakening those whose balance is already negative.

Agreed

> I wouldn't read too much into the why of this partnership. One potential reason is just that scarf has a UI and sonatype outsources to them because it's less work for them. Oh I would not be surprised to learn that Scarf is paying Sonatype a lot for exclusivity on this data, and Sonatype has decided that it's an acceptable tradeoff to getting funds for Central

The people doing that 83% of the downloads are NOT the ones who are producing the software. If I'm a megacorp who doesn't want to pay for a caching layer, why the hell do I care who is downloading all the software that I leach?

getting funds for Central

That's not how it works. They have no incentive to stop there, and a lot of incentive to extract whatever they can from whoever they can. So we should be prepared if this goes south. It doesn't have to stay that way if a sufficient number of maintainers agree.

Everyone is free to self host. The trust that Maven Central provides is hard to replicate

Sure. I'm just not going to be paying for Scarf, no matter the price. I now have analytics on the docs website, and I think these are much more useful than download numbers (which will be dominated by CI anyway)

It's not just trust. It's also gatekeepers like Gradle making access to some repos easier than others.

Yea, it's always the same thing with centralized internet. There is some convenience to it.

I mean, I geniunely don't see a reason why MavenCentral couldn't be torrent-based

Yea, probably some integrity reason. We need to add the checksum to the coordinates

Main issues I see: • Maybe it's too slow • Maybe some people don't want to publicly say what they're downloading, but I'm sure there's a fix for that (e.g. local-net default)

Yea, just no one is using them 😅

For example, I know that 80%+ of my usage of Central is from my CI servers, which is completely pointless, but I don't have an easy way to avoid it

I think these are already good ideas. Centralized infra would also be OK if it were governed in a democratic way by those who contribute. Once there are network effects and a natural monopoly, we cannot afford to yield control to a small group, whatever their initial motivation might have been.

Sure, but none of us have the money for that. Even JB decided it wasn't worth it

governed in a democratic way by those who contribute

this is NP hard

IMO decentralized/IPFS-based/whatever is the only way this can be sustainable long term. Imagine if all the CI servers on earth were seeding Central, we'd have unlimited resources But that requires Gradle/Maven/etc changes, which won't happen

Governance is harder than naming and caching 🙃

First, there's always the chicken and egg problem (funding). But who says crowdfunding could not be a way to produce the initial spark? And yes, maybe decentralized would be the way to go. P2P music "sharing" did that once illegally. Here, we have all the legitimacy we could ask for.

Governance is harder than naming and caching

Yes - the hosting needs to be split from the attestation of the assets.

the only reason that Maven Central is trusted by default is because they control the attestation.

I don't know. Maybe they were the first to provide stable download performance?

in banks etc, they couldn't give 2 shits about the download performance. They block everything else not -MC primarily because anyone and their dog can publish

Let banks do what banks do. Would they ever pay or contribute?

We could have a per-domain repo.

com.example.foo:foo:0.0.0

at

<http://example.com/m2|example.com/m2>

would be trusted by default.

Why should anyone trust me, just because I can publish on MC?

your groupId matches your domain

OK, so I can buy a domain...

yep - because you have purchased a domain. and that's the low bar!

That's ATProto-central eheh

All of this would also require changing the way maven/gradle is downloading dependencies on client side right?

I need to jump through more hoops just to get a bank account.

it's just another artifact resolver

That's ATProto-central eheh

Let's do this!

I need to jump through more hoops just to get a bank account.

domains aren't free- you also need a payment source! 🙃

Domains are cheap!

the money doesn't matter - it's the chain of "trust" which does - note you can't buy a domain with BTC

(that I know of anyway!)

another business opportunity 😂

But seriously: Never underestimate the power of maintainers. Take out a small number of widely used projects which would be difficult to maintain for others. If folks would just stop to keep them fresh on MC, and maybe even re-license their products to exclude central mirroring, that once powerful central repo would quickly become a desert and consumers would get scared about possible vulnerabilities or their world breaking apart at the next dependency update cycle.

All of this would also require changing the way maven/gradle is downloading dependencies on client side right?

Not sure. If each node exposes a central-like file structure and processes requests by transmitting to the network, you could add one node as a regular maven repo and that's it

I mean the safe part (validating domain); you can always configure the repo to only include some group ids on the client side 🤷‍♂️

you'd need to do discovery - but you could probably just 302 that and let the (hopefully correctly configured) HTTP clients in gradle/maven handle the redirect

The problem with Gradle is: You'd have to add another repo, which has to be done per project. That's what made Sonatype introduce rate limiting as system-level repo redirection was hard to implement even for the big tech high-volume consumers.

Alternatively: download the POM from Central and the hash files, and only download the actual contents from the mirrors. Not fully decentralized, but I'd bet that would help Central a lot already

Really curious to know more about how JB does it

JB has their own mirror btw, the Kotlin project pulls from it. I wonder how they handle access rights on it, or if any of us could just use it instead of Central

@CLOVIS cache-redirector shouldn't be used externally, it's just to help JetBrain's CI stability and speed

It could. We’ll have to add an extra step on client side for verification though.