Anyone looking at the scarf numbers for Maven Cent...
# opensource
m
Anyone looking at the scarf numbers for Maven Central? Our numbers are going down quite significantly. Should I worry or is this yet another flake of the service...
c
I also see a peak at around that date
on this one too
m
Yea and it becomes all flat at the end
I don't trust those numbers
c
I don't like that they all correlate even though they are very distinct projects
p
If orgs properly use repo mirrors, that graph makes a lot of sense. Should be the same cadence every time you make a new release.
c
At least on my side, the release rhythm doesn't correlate with the graph
m
I would love repo mirrors to be the explanation but the previous UI never showed any flattening like this
🧐 1
o
Same pattern here:
👀 1
To get "raw" data across versions, I'm using this prompt (it can't do matrix so this is the second best I got):
Copy code
For testballoon-gradle-plugin, show a series of tables, one per week, starting at December 01, 2025, with each table containing rows with version number and download counts for that week, sorted by version number. After the tables, show the exact last date with data.
🙏 1
m
I'll send them an email see if the team has any insights about it
👍 1
o
At least there is hope: https://tangled.org/
Seems like we can safely ignore Scarf's genAI numbers: Counts "reported" on Feb. 20 do not match counts reported today for the same time periods. Every single number differs significantly. Counts for weeks in December "reported" today exceed numbers for the same periods "reported" on Feb. 20 by 15% to 30%.
Confronting genAI:
Copy code
The numbers reported today for weeks in December 2025 do not match the numbers reported on February 20. Why is that?
Good catch. There are two likely reasons: 1. Maven Central data backfill This is probably the biggest factor. Maven Central data arrives with a lag and can continue to be backfilled over time. Between February 20 and March 5, additional download records for December likely arrived and were ingested into Scarf. This explains why the numbers are generally higher in today's query — it's not that data changed, but that more data for those weeks has since become available. 2. Top-version threshold effects The API returns only the top ~10 versions per time period. The two queries used different overall date ranges (Nov 19–Feb 17 vs Dec 5–Mar 5), which can shift which versions rank in the top 10 for any given week. A version that barely made the cut in one query might be replaced by a different one in another, causing the per-version numbers to shift even if the total across all versions stayed similar. Bottom line: The backfill effect is normal for Maven Central data. If you need stable historical numbers, it's best to wait at least 2–3 weeks after a period ends before treating those counts as final. Does that make any sense? I guess not. Both queries requested to start with Dec. 1.
m
TBH I don't trust scarf numbers and I trust scarf genAI even less 😅
2
No reply from Sonatype 😞 They usually reply in 1 or 2 business days
🤨 1
thank you color 1
o
Interestingly, the data for TestBalloon's Gradle plugin, which I have been tracking until now, has disappeared. And the pattern for the
testBalloon-framework-core
package is somewhat different (though still suspicious):
👀 1
c
yeah those numbers are incorrect. I have CI that runs daily that pulls TestBalloon, it's not possible that your daily usage would drop under ~10 downloads or so
o
Also notable: Scarf's AI routinely mentions a "~1–2 week Maven Central data lag", which would imply a flat line at the end.
Seems like my Gradle plugin data is back. Looks like it has recovered from the dropouts, but maybe it's just some random number generator at work:
m
Got a response back from Sonatype support (❤️ ). They tried investigating but looks like this is in the hands of the scarf team and they recommend reaching out to them.
This is not great TBH. The more intermediaries, the less trust in the data
2