Digital Sovereignty in Government IT: Why Open Source Is Now a Strategy
The Moment I Stopped Treating Open Source as a Budget Question
Early in my SAP consulting days at Accenture, the conversation about software in public sector projects was almost always the same: licences, support contracts, vendor roadmaps. Open source came up occasionally, usually as a way to shave costs on peripheral tooling. Nobody called it a sovereignty question. Nobody needed to.
That framing has changed completely. When I look at the EU's Interoperable Europe Act, the European Commission's own Open Source Programme Office, and national strategies from Germany's Sovereign Tech Fund to France's plan for a socle interministériel de logiciels libres, I see governments making a fundamentally different argument. The question is no longer just whether open source is cheaper. It is whether depending on a handful of proprietary platforms — most of them headquartered outside the EU — is an acceptable risk for critical public infrastructure.
Having worked both sides — large vendor-driven ERP rollouts across fifteen countries at Puig, and building my own AI platform with a deliberately small, auditable stack at CVChatly — I have a view on what this shift actually demands from people who have to deliver.
What Digital Sovereignty Actually Means in Practice
The term gets used loosely, so let me be specific about what I mean. Digital sovereignty in government IT is the ability to understand, control, audit, modify, and — if necessary — replace the technology that runs public services, without being locked into a single vendor's commercial decisions or geopolitical exposure.
That definition has three practical dimensions that matter for delivery teams.
Control over data and infrastructure
If a government cannot inspect how its data is processed, stored, and shared by a vendor's platform, it cannot make credible GDPR commitments to citizens, it cannot respond properly to a security incident, and it cannot comply with the Data Governance Act's requirements around public sector data sharing. Proprietary black boxes make all three harder. Open source does not automatically solve this — you can run open source badly — but it removes the contractual and technical barriers to looking inside.
Continuity independent of vendor decisions
I have seen this problem up close. A vendor discontinues a module. A support contract expires and renewal costs triple. A US-headquartered company changes its data residency policy following a regulatory change in its home market. None of these scenarios are hypothetical; they have happened to public sector clients I have worked with. With a proprietary stack, your options are limited to whatever the vendor allows. With open source under a recognised licence, you can fork, self-host, or commission a third party to maintain the codebase. That optionality has real monetary value that almost never appears in a procurement business case.
Auditability and trustworthy AI
This third dimension is the one gaining the most urgency right now. The EU AI Act requires high-risk AI systems used in public administration to be transparent, explainable, and subject to human oversight. If the AI system is a proprietary model accessed via an API, the public body deploying it has very limited ability to inspect training data, fine-tuning choices, or model behaviour under edge cases. Open source models — or at minimum open-weights models — give technical teams the ability to evaluate, red-team, and document the system in the way the Act demands. This is not an abstract compliance point. It is an architectural decision you have to make before you sign a procurement contract.
Where the Resistance Comes From — and Why Some of It Is Legitimate
I want to be honest about the counterarguments, because I have made some of them myself.
Support and accountability. When a proprietary system breaks at 2 a.m., you call a number and someone answers. With open source, support is a separate contract, an internal team, or a community forum. For small public bodies without mature internal engineering capability, that is a genuine risk. The answer is not to abandon open source; it is to fund the support model properly, which European frameworks like the Interoperable Europe Act are starting to encourage by promoting shared services across member states.
Security through obscurity is not real security, but obscurity still matters. Published source code can be audited by anyone — including adversaries. This is a real concern for certain components. The response is not to make everything proprietary but to be deliberate about what you open-source and how you manage vulnerability disclosure. Germany's BSI and ENISA both publish guidance on this.
Procurement inertia. Most public sector procurement frameworks were designed around commercial software licences. Evaluating open source solutions — where the software is free but implementation, hosting, and support are not — requires procurement officers to assess value differently. This is a skills and process gap, not a reason to stick with proprietary defaults. The EU's Public Procurement Directives allow for open source procurement; the problem is usually internal capability, not legal constraint.
The third objection is the one I find hardest to dismiss in the short term. Changing procurement culture is slow. I have watched technically sound open source proposals lose to proprietary alternatives simply because the evaluation committee did not know how to score a TCO model that separates licence cost from support cost. That is a training problem and a governance problem, and fixing it takes longer than a project cycle.
What Delivery Teams Need to Do Differently
If you are a product manager, project manager, or technical lead working on a public sector digital service, here is how I would translate the sovereignty agenda into concrete decisions.
Make the build-vs-buy-vs-open-source question explicit at the architecture stage
Do not let it default to whatever the incumbent vendor already has on contract. Document the options, the trade-offs, and the sovereignty implications. The PM² methodology's Business Case and Project Initiation Request phases are the right moment for this conversation — not after you have already committed to a platform.
Assess vendor lock-in risk as a project risk
In your risk register, add a line for proprietary dependency. What is the exit cost if this vendor raises prices, changes terms, or exits the market? What data portability does the contract guarantee? I have seen projects where nobody asked these questions until the vendor's acquisition by a US private equity firm made them suddenly urgent.
Prefer open standards and open APIs even when the software is proprietary
Not every component needs to be open source. But every interface should use open standards — REST, OpenAPI, SAML, OAuth, the semantic interoperability specifications in the European Interoperability Framework. Open standards are the floor. Open source is the ceiling. You can move between them incrementally.
Build internal capability, not just vendor management capability
Sovereignty is not just a procurement decision; it is an organisational one. A public body that has no engineers who can read a pull request is dependent on vendors by default, regardless of what the licence says. Investing in internal technical capability — even a small team that can evaluate, configure, and audit open source components — changes the power balance in every vendor negotiation.
Document your AI components with sovereignty in mind
For any AI feature, record: the model or service used, whether it is open or proprietary, where inference runs, what data leaves your perimeter, and what the exit path is if the provider changes terms. This is good EU AI Act hygiene and good sovereignty practice simultaneously. At CVChatly, I maintain this as a living document precisely because the LLM landscape changes fast enough that last quarter's decision may not be next quarter's right answer.
The Practical Takeaway
Digital sovereignty is not an ideology. It is risk management at national scale, applied to the technology that runs public services. For delivery teams, it translates into a set of concrete decisions: what you procure, how you write contracts, which standards you mandate, and whether you build enough internal capability to remain in control of your own systems.
The European frameworks — Interoperable Europe Act, EU AI Act, Data Governance Act, the Commission's open source strategy — are pushing in the same direction. They are not asking governments to reject commercial software wholesale. They are asking for intentionality: know what you depend on, understand the risk, and have a credible alternative if that dependency fails you.
That is not a new principle. It is the same thing I would tell any product team about third-party dependencies in a production system. The scale is different. The political stakes are higher. But the discipline is the same.