When good infrastructure works, most people do not think about it. They might even forget. But when it stops working, everyone notices.
Builds, scanners, CI systems, dependency resolution, automated publishing, ephemeral environments, and machine-to-machine workflows all depend on it being available, fast, trustworthy, and, ideally, boring.
Brian Fox, CTO and Co-founder of Sonatype CTO and Steward of Maven Central, has written a lot recently about the sustainability of open source infrastructure, and those posts have helped frame the broader problem:
This is the first post in what will become a more regular series from the Central team. Brian has already laid plain the case for sustainable open source infrastructure. With this series, we will share more of the day-to-day thinking, learning, trade-offs, and nuance we are working through as we help make Central sustainable for the long term.
That means sharing updates when there is progress, but also explaining some of the less obvious things we are discovering along the way. It also means being clear from the outset that Maven Central remains free for community open source.
At its simplest, Central exists to make Java ecosystem components broadly available, and that model has worked extraordinarily well. A maintainer publishes a release. A developer consumes it. Build tools know where to find it. The ecosystem benefits from a shared, trusted distribution point.
As that trusted distribution point, Maven Central has become one of the most important software ecosystems in the world by reducing friction for both publishers and consumers. But the world around Central has changed. The same infrastructure that supports a maintainer publishing a library from a spare room is also used by large organizations distributing SDKs, agents, generated clients, connectors, frameworks, internal-adjacent tooling, and integration layers for commercial services.
Some of those artifacts are unquestionably useful. Many are open source. Some are widely adopted. Some make developers' lives easier. The issue is not whether they should exist, or whether they are welcome. The more interesting question is whether every kind of open source publishing creates the same relationship with the commons it depends on.
I do not think it does.
One of the traps in this conversation is that we often use "open source" as if it describes a single thing. It does not.
A project can be open source in the licensing sense. The source may be available. The license may be OSI-approved. Contributions may be possible. All of that matters. But it does not automatically tell us why the project exists, who primarily benefits from it, or what kind of infrastructure responsibility should sit around it.
An SDK for a paid service is a useful example. The SDK may be open source, and that is generally a good thing. Developers can inspect it, debug it, fork it, improve it, and understand how it interacts with the service. Those are real benefits. But the SDK may also exist primarily to make it easier to consume a commercial platform. None of this makes it "not open source" or any less valuable to developers.
It does, however, place it in a slightly different part of the map from a community-maintained library created to solve a general problem for the ecosystem.
Both may use the same license. Both may publish to Central. Both may be useful. But they are not identical from the perspective of infrastructure stewardship.
A lot of the work ahead is about avoiding overly simple categories. "Open source good, commercial bad" is not a useful framing, and it is not one we should adopt. Commercial organizations contribute a huge amount to open source, and many commercially backed projects provide significant value to the wider ecosystem.
Equally, "the license is open source, therefore all other context is irrelevant" is too narrow. It ignores the operational reality of running shared infrastructure at the scale Central now operates.
The reality is more nuanced:
A community project may have unusual publishing patterns without abusing the service.
A commercial SDK may provide enormous value.
Automated publishing may make sense locally while creating global infrastructure costs.
A component may be open source, useful, and part of a commercial distribution strategy all at the same time.
None of that is contradictory. It just means we need to look at patterns and context, not just labels.
One of the clearest boundaries is also one of the most practical: Central is for public distribution of release-ready artifacts.
It is not intended to be the default destination for every build output, every CI run, every internal-only component, or every generated artifact that happens to be technically publishable. That distinction matters because publishing is not free in the operational sense. Every artifact has to be stored. Metadata has to be processed. Indexes have to be updated. Abuse has to be managed. Replication has to happen. Support questions have to be answered. The system has to remain reliable for everyone else.
At a small scale, many of these costs are barely visible. At global scale, they become the work.
That is one of the recurring themes we expect to come back to in this series. Many of the behaviours that create strain are not malicious. They are often the result of reasonable decisions made locally, repeated automatically, and then scaled globally. The challenge is that shared infrastructure experiences those decisions in aggregate.
The Central team will be sharing more about how we think through these issues. Some of that will be technical. Some of it will be operational. Some of it will be about policy, limits, exemptions, tooling, workflows, and the patterns that create disproportionate load.
We will try to be transparent without being alarmist, and practical without being reductive. Most importantly, we will try to explain the "why," not just the "what." Infrastructure changes can create understandable anxiety, particularly when people rely on that infrastructure every day. The best way to address that is not vague reassurance, but clear communication about intent, impact, and what we are learning.
The principle we are working from is straightforward: Central should remain open and free for community open source, while becoming more explicit and sustainable for usage patterns that operate at commercial or infrastructure scale.
That is not about making open source smaller. It is about keeping the infrastructure behind it healthy enough to keep supporting the ecosystem we all rely on.
Sustainable infrastructure is what allows open source to remain open. But someone is always thinking about it. Someone is keeping the lights on, handling abuse, watching growth curves, responding when automation behaves badly, and trying to make sure the next build still works.
The work ahead is about making that stewardship visible enough to be sustainable, without turning Central into something it was never meant to be.
Community open source should continue to have a home. Developers should continue to build. Maintainers should continue to publish. And where Central is being used as part of a commercial-scale software delivery model, that usage needs to be understood as a real dependency on shared infrastructure.
Open source is nuanced, and open infrastructure is too. This series is our attempt to work through that nuance in public, share what we are learning, and help keep Central sustainable for the communities that depend on it.