Support and Care

That is how I finally understood the name Support and Care.

The work that brought me there was Maven Support & Care issue #224. It is almost aggressively forward-looking: the Cyber Resilience Act is coming, software projects need better information about their dependencies, and Maven should have a plugin that can inspect dependencies and build plugins for things like public SBOMs and OpenSSF Scorecard evidence. The proposal specifically called for a new Maven plugin, configurable enough to support different levels of enforcement and open enough to add more checks later.

So I built it.

The Supply Chain Verification Maven Plugin now runs inside Maven and inspects the software a build actually resolves. It records dependencies and build plugins, follows Maven Resolver repository provenance, looks for SBOM sidecars in the repository context Maven used, resolves source repositories for OpenSSF Scorecard, hashes the consumed artifacts and POMs, preserves uncertainty instead of guessing, and writes deterministic evidence that can be reviewed or enforced later.

What this changes about the funding

Issue #224 is not just a wishlist item. It is tagged STF-2.0, part of the second round of ideas assembled by Maven Support & Care for potential Sovereign Tech Fund support. In January, the Maven development list described the first STF round as successful and opened community review on a second group of proposals. By February, Support & Care was compiling the next funding request. The final note on #224 is unusually direct: request funding for a new Maven plugin.

That context matters. Public-interest funding creates something mature open source is usually short of: developer time. Open Elements says the first STF-backed Support & Care round brought three additional Maven maintainers into funded work during 2025. The point is not that Maven lacks capable people. It is that capable people have a finite number of hours, while a project this old has an effectively infinite supply of useful work.

I want to be precise about what “done” means here. This is an independent reference implementation, not an Apache Maven or Support & Care project, and it is not yet published to Maven Central. There are deliberate follow-on gaps documented in the current scope: validating SBOM contents, cryptographically binding an SBOM to the artifact, artifact-to-source provenance, vulnerability providers, attestation verification and persistent evidence caching, among others.

But the first implementation slice is done enough to change the economics of the proposal. Funding no longer has to start by paying someone to discover the basic architecture from a blank page. It can be concentrated on upstream review, hardening, the next evidence providers and the parts that require sustained maintainer attention. Or the people allocating the funding can decide that another item in the Support & Care backlog now deserves those hours more.

Either outcome is useful. The scarce resource in foundational open source is not ideas. It is focused maintainer time. Retiring implementation risk on one item creates room for the next one.

That last part became more important than I expected. Security systems love binary answers. CI wants green or red. Dashboards want a score. People want PASS or FAIL. But a supply chain has another state that matters just as much: UNKNOWN.

If the plugin cannot safely establish whether evidence exists, it does not turn that uncertainty into a clean answer. A timeout is not proof of absence. Repository ambiguity is not proof of safety. A current Scorecard result is not silently presented as historical provenance for an artifact built years ago. The evidence layer says what it knows and what it does not. Policy comes afterward.

A bank can reject UNKNOWN. A developer can tolerate it locally. A federal release process can impose a different threshold. The evidence does not need to change because the judge changes.

That was the future-facing part of the work.

Then Maven sent me twenty years in the other direction.

MNG-1378 was opened on October 31, 2005. The bug is deceptively simple. A project can publish its test classes as a separate test-jar. Those test classes can themselves depend on libraries declared with test scope. But when another project consumes the test JAR, those test-scoped dependencies are dropped. The downstream project gets the test classes without the classpath those classes actually require.

People had been running into that behavior for years. They worked around it by duplicating dependencies or restructuring projects. The issue collected votes, related bugs, proposed alternatives, and the kind of comments an old issue accumulates as one generation of users hands it to another.

I now have a Maven 4 patch for it. The fix is deliberately narrow. It does not make test scope generally transitive. It teaches Maven's dependency selection that while it is collecting the children of a test-jar, that artifact's direct test-scoped dependencies are part of the classpath the consumer actually asked for. Ordinary JAR behavior stays ordinary. Maven 3 compatibility stays intact.

At first, the plugin and MNG-1378 felt like two completely different projects. One was about SBOMs, Scorecard, artifact identity, modern supply-chain assurance and regulations that are only now arriving. The other was about understanding dependency semantics written when GitHub did not exist.

They are actually the same job.

Support and care for foundational software means being able to look five years forward and twenty years backward at the same time.

Maven is a particularly good place to learn that lesson because a Maven build is not just a list of libraries. Plugins execute code. Parent POMs alter behavior. Profiles change builds. Repositories determine what gets resolved. Transitive dependencies arrive because something else in the graph asked for them. Twenty-year-old semantics can sit directly underneath a 2026 assurance mechanism.

That is why I no longer think of maintenance as the work that happens after the interesting engineering is finished. In mature open source, maintenance is often where the hardest engineering lives. You inherit decades of compatibility promises, assumptions nobody remembers making, bugs old enough to vote, and users whose builds you will never see. Then you try to make the system better without destroying the reasons people trusted it in the first place.

Sometimes that means building something new. Sometimes it means finally fixing something old. Usually it means doing both without pretending they are separate.

That is support.

And that is care.