1 SEP 2026 — Broadcom has announced TrueSource, an offering of curated, scanned and patched builds of open-source libraries, covering Spring and RabbitMQ plus components across Java, Python and Node.js. Broadcom already maintains Spring and RabbitMQ. No price has been stated for any of it.
What was announced
TrueSource by Broadcom was announced on 31 August, ahead of the VMware Explore conference. Purnima Padmanabhan, a vice president in Broadcom's Tanzu division, said the aim was to provide clean and secure artefacts.
The artefacts are described as curated libraries that conform to a reference architecture and are supportable by the maintainers of record, produced through a process of scanning, fixing and contributing back upstream. A VMware spokesperson said the company will work with and support maintainers on open-source software and provide fixes upstream for active projects.
Two very different promises in one announcement
Spring and RabbitMQ are Broadcom's own. It acquired them with VMware, it employs the maintainers, and it decides what ships. Promising secure artefacts for those projects is a promise to do its existing job to a stated standard, which is worth something and is not what the headline suggests.
The Java, Python and Node.js components are a different proposition. Broadcom does not maintain the long tail of libraries in those ecosystems and cannot commit their maintainers. It can take upstream code, scan it, patch it and republish the result — a distribution and support business, not a stewardship one.
The phrase supportable by the maintainers of record conflates the two. For Spring, that maintainer is Broadcom. For a Python package it might be three volunteers who have made no undertaking to anybody.
Nothing has been said about price
No pricing was disclosed. For this company, that omission carries weight.
Broadcom's post-acquisition record with VMware licensing is the context here. The company restructured VMware's product bundles and raised costs for many customers. That was a commercial decision it was entitled to make, and it shaped how its announcements are now received.
Free artefacts would be a contribution to the commons and a reasonable way to make Tanzu more attractive. Artefacts behind a Tanzu subscription would mean something else: the hardened build of a public library becomes a paid product, and the public build becomes the lesser option. Broadcom has not said which of those it is building.
Curated builds are a real answer to a real problem
The underlying idea is sound, and the problem it addresses is getting worse.
A modern Java or Node application pulls in hundreds of transitive dependencies, most maintained by people with no obligation to anyone, some effectively abandoned. Enterprises need to know that what they deploy has been reviewed, that fixes will arrive, and that somebody answers the phone. Commercial curation of open source is one of the few workable answers, and Red Hat built a large business on exactly that model.
Hold them to the contributing-back half. Scanning and patching for paying customers is a support product; sending those fixes upstream so everyone benefits is what separates curation from extraction, and Broadcom has committed to the second for active projects.
What should arrive with a trusted artefact
The word trusted implies evidence, and the announcement does not say what evidence accompanies the build.
The established answers exist and are not exotic. A software bill of materials listing every component and version. A signed attestation of how the artefact was built and by which pipeline, so a consumer can verify it came from where it claims. A published diff against upstream, so anyone can see exactly what was patched and what was left alone. And a stated policy on when a divergence from upstream is acceptable.
Without those, a curated artefact is a binary a customer is asked to trust because of who produced it. With them, it is a claim a customer can check. The difference matters most in exactly the scenario this product exists for, which is an auditor asking what is actually running in production and why it differs from the public release.
Who ends up bearing the cost
There is an asymmetry built into this model.
The maintainers of the Python and Node libraries being curated are not party to the arrangement and receive nothing from it. Their work becomes the input to a commercial product, and the fixes flow back only where the vendor chooses. That is entirely lawful under permissive licences and it is how the ecosystem has always worked.
It is also the pattern this site has been tracking from several directions. AWS bought DuckDB's maintainers rather than DuckDB, and ten individuals put US$1m each into a foundation whose remit includes funding the upstream projects it depends on. Each is an answer to the question of who pays the people who write the code, and only the foundation actually sends money to maintainers.
What to check before relying on it
Any vendor offering hardened open-source builds should answer three questions.
What is the patch commitment in time: how quickly after a published advisory does a fixed artefact appear, and is that contractual or aspirational. A curated build that lags upstream is worse than upstream.
What happens when the vendor drops a component. Coverage lists change, and a dependency that was curated last year may not be this year, which is a supply-chain risk created by the curation itself.
And whether the fixes reach upstream. If they do, the ecosystem is better off whatever the pricing. If they do not, an organisation paying for the artefact is paying for a private fork of public code, and should know that is what it is buying.
View author profile → · Editorial policy
