You’ve Been Selling Open Source Wrong
Most Australian technology leaders have spent the last decade selling open source to their boards as a cost play. Lower licensing fees. Less vendor lock-in. Faster iteration. The pitch worked, and now open source is everywhere in your stack — in your cloud infrastructure, your container orchestration, your data pipelines, your security tooling. It got in through the budget conversation, and it stayed because nobody asked hard questions about what came with it.
Europe just asked the hard questions. The European Commission’s proposed tech sovereignty package, covered in detail by Risky Business, includes an Open Source Strategy that reframes open source not as a procurement efficiency but as sovereignty infrastructure. The intent is to reduce European dependence on the US tech stack by institutionalising open source adoption across government, reforming procurement rules, and directing grants to open source projects. This isn’t a CIO cutting a software budget. This is a geopolitical bloc deciding it needs to control its own digital foundation.
The uncomfortable implication for Australian technology leaders is this: Europe is building a governance model for open source. Most Australian enterprises don’t have one.
Open Source Governance Is Not the Same as Open Source Adoption
There’s a meaningful difference between using open source and governing it, and most organisations have confused the two for years.
Adoption is easy. You pull a library, a framework, a runtime. You deploy it. It works. Nobody files a procurement request and nobody updates a risk register. That’s not governance — that’s convenience dressed up as strategy.
Governance means you know what’s in your stack, who maintains it, under what licence, with what dependencies, and what happens to your operations if that project is abandoned, compromised, or forked into irrelevance. It means you have a Software Bill of Materials. It means someone in your organisation has assessed whether the maintainers of your critical components are a one-person volunteer project running on GitHub donations, or a well-funded foundation with enterprise backing.
Most Australian enterprises cannot answer those questions for their production systems. This is not speculation — it’s the consistent finding when organisations go through a serious supply chain security review, which most haven’t done until a regulator, an insurer, or an incident forces it.
The XZ Utils backdoor in 2024 was a clean demonstration of the problem. A sophisticated, patient actor spent years building trust with a critical open source project’s maintainer, then inserted a backdoor into a widely-distributed compression library. It was caught by accident. The reason it almost wasn’t caught is the same reason most boards don’t understand their open source exposure: nobody was watching, because nobody thought watching was their job.
The Sovereignty Reframe Changes the Governance Calculus
When open source is a cost strategy, governance looks like overhead. Why spend money managing something that was supposed to save you money?
When open source is a sovereignty strategy, governance becomes essential. You don’t deploy critical national infrastructure and then neglect to ask who built it, who maintains it, and who could compromise it. That framing is obvious when you apply it to physical infrastructure. It should be equally obvious when applied to software.
Europe’s move forces a rethink that most technology leaders have been quietly avoiding. If the EU is treating open source dependency as a matter of national control, then the question for Australian organisations — particularly those in critical infrastructure, financial services, and government — is whether they understand their own dependency position well enough to make informed decisions about it.
APRA CPS 234 requires regulated entities to manage information security risks in their supply chain. The SOCI Act imposes obligations on critical infrastructure operators around their systems’ resilience and security. Neither framework explicitly mandates SBOM practices, but both create liability for organisations that cannot demonstrate they understand the components of their own critical systems. Open source governance is not a niche technical practice — it is increasingly a compliance obligation in all but name.
The Vendor-Aligned Advice You’re Not Getting
Here’s what vendor-aligned advisors won’t tell you: the commercial software vendors who sit on your preferred supplier list have a direct interest in your open source posture remaining ungoverned.
If you don’t know what open source is in your stack, you can’t make a meaningful comparison between it and commercial alternatives. You can’t weigh the total cost of ownership honestly. You can’t assess dependency risk across the board. This suits vendors who benefit from the perception that commercial software is the safer, more accountable choice — even when the commercial product is itself built substantially on open source components, which most are.
The other thing vendor-aligned advisors won’t say plainly: open source has a genuine accountability problem that governance can address but procurement cannot solve. When you buy commercial software, you have a contract. When something goes wrong, you have someone to call. When a critical open source project is abandoned or compromised, you have a mailing list and a GitHub issue. That asymmetry is real, and the answer isn’t to avoid open source — it’s to govern it like it matters, because in most enterprise stacks, it does.
What Australian Technology Leaders Should Do Differently
The EU’s sovereignty package probably won’t reshape global technology supply chains in the short term. Risky Business is right about that. But the strategic reframe it represents is already underway, and Australian organisations that are still treating open source as a cost line are going to find themselves behind the conversation.
Three things need to change.
First, stop selling open source to your board as a cost strategy. Reframe it honestly as a control and dependency position. The question is not what you’re saving on licences. The question is what you depend on, who controls it, and what your exposure is if that control shifts. That is a board-level risk question, and it belongs in the boardroom.
Second, build a Software Bill of Materials for your critical systems. Not because a regulator has explicitly required it yet, but because you cannot govern what you cannot see. An SBOM is not a technical deliverable — it is the precondition for any serious conversation about supply chain risk. If you don’t have one, you are operating blind in an area that regulators, auditors, and insurers are increasingly scrutinising.
Third, assess your critical open source dependencies the same way you assess any other third-party risk. Who maintains this project? Is it funded? Is it a single point of failure? What is your contingency if it becomes compromised or unsupported? These are not difficult questions. They are the same questions your procurement team asks about any significant vendor. Apply them consistently.
The Governance Debt Is Already Accruing
Europe’s open source strategy is a signal, not an instruction. Australian organisations are not bound by it and won’t be compelled by it. But the underlying logic is sound, and the governance gap it exposes is real.
Your open source posture is not a feature of your technology strategy. It is, right now, governance debt. It accumulated quietly because the cost conversation was easier than the control conversation. The longer it goes unaddressed, the more expensive it becomes to unwind — not in licensing terms, but in risk exposure, regulatory scrutiny, and the very dependency on external actors’ decisions that Europe is now trying to escape.
The question is not whether to take open source seriously as a governance matter. The question is whether you get ahead of it on your own terms, or wait until someone else sets the terms for you.