Open source or proprietary? How governments should choose software for public infrastructure

Analysis · Published 2026-10-16

Close-up of a monitor showing lines of colour-highlighted source code — Photo: Ilya Pavlov, CC0, via Wikimedia Commons.

Few debates in government technology generate as much heat as open source versus proprietary software. Advocates of open source point to sovereignty, transparency and reuse; vendors point to support, accountability and maturity. For digital public infrastructure, the right answer is rarely ideological. It depends on what is being bought, for how long, and what the state can manage itself.

First, separate three questions

Discussions often blur three distinct choices:

Standards: are the interfaces and data formats open? This is usually the most important question for interoperability and exit, and it applies whatever the software licence. See interoperability and open standards.
Licence: is the code published under an open-source licence that allows use, study, modification and redistribution?
Delivery: who builds, hosts, operates and supports the system: in-house teams, a system integrator, or a software vendor?

Open-source software is often delivered by commercial integrators, and proprietary software can implement open standards. The worst combination for public infrastructure is a proprietary product with proprietary interfaces and data formats, operated by the vendor with little in-house understanding.

What public policies say

Several governments have formalised a preference for openness, with different degrees of force:

European Commission. Its Open Source Software Strategy 2020–2023, "Think Open", committed the Commission to favour open source in its own IT and to share code. The 2024 Interoperable Europe Act encourages administrations to share and reuse solutions, including open-source software.
France. The 2016 Law for a Digital Republic treats source code developed by administrations as an administrative document, subject to access rights, and the government maintains a public catalogue of its open-source code at code.gouv.fr.
Italy. The Digital Administration Code requires administrations to carry out a comparative assessment before acquiring software, giving preference to reuse and open-source solutions, and to make software they own available for reuse.
United Kingdom. The government's Service Standard asks teams to make new source code open, with exceptions for sensitive code.
United States. The 2016 Federal Source Code Policy required agencies to make custom code reusable across government and set a pilot target for releasing a share of new custom code as open source.
Germany. The federal government set up ZenDiS, a centre for digital sovereignty, in 2022, which develops the openDesk office and collaboration suite for administrations. The state of Schleswig-Holstein announced in 2024 a move of its administration to open-source office software.

Civil society campaigns such as the Free Software Foundation Europe's "Public Money? Public Code!" (launched in 2017) argue that publicly funded software should be published under free licences by default.

The case for open source in public infrastructure

Exit and bargaining power. If the state holds the code and the rights, it can change integrators without rebuilding. MOSIP's standard interfaces for biometric components are a deliberate response to decades of vendor lock-in in identity systems. See the MOSIP case study.
Reuse across governments. Estonia and Finland co-develop the X-Road core through a joint institute rather than each paying for its own. See the X-Road case study.
Transparency. Published code can be reviewed by researchers, auditors and civil society, which matters for systems that make decisions about people.
Longevity. Infrastructure lives for decades; open code and open standards reduce the risk of a vendor discontinuing a product.

The case for proprietary or commercial products

Maturity for commodity functions. For generic needs (office tools, databases, cloud infrastructure), established products may be cheaper and more reliable than custom builds, open or not.
Accountability. A contract with service levels and liability can be easier to enforce than reliance on a community.
Skills reality. Open source shifts dependency from licences to skills. A government without capacity to manage code may end up dependent on a single integrator anyway, now without the vendor's product support.
Specialised components. In fields such as biometric matching, the best-performing algorithms have often been proprietary. A pragmatic design, as in MOSIP, puts them behind standard interfaces so they can be swapped.

Cost: compare totals, not licences

"Open source is free" is the weakest argument for it. The cost of a public system is dominated by design, integration, hosting, operations, security, training and support over ten years or more. Open source removes licence fees and can reduce long-term costs through reuse and competition between suppliers; it does not remove the need to fund maintenance. The Log4Shell vulnerability in December 2021, in a widely used open-source logging library, showed how much critical infrastructure depends on under-resourced projects. Germany's Sovereign Tech Fund, created in 2022 to invest in open-source maintenance, is one response.

Security: neither model is automatically safer

Open code allows more people to find vulnerabilities, but only if someone looks. Closed code hides vulnerabilities from attackers and defenders alike. Security depends on practices: secure development, independent audits, rapid patching, dependency management and incident response. Contracts and procurement rules should require these, whatever the licence.

A decision framework

Component	Default	Why
Core public rails (identity, exchange, registries)	Open standards, state-owned or open-source code, rights to data and documentation	Long life, high lock-in risk, public accountability.
Specialised components (biometric matching, HSMs)	Best available product behind standard interfaces	Performance matters; interfaces preserve exit.
Commodity IT (office, email, cloud)	Competitive procurement, open formats, portability clauses	Mature markets; avoid format and data lock-in.
Custom applications built for the state	Publish code unless there is a specific security reason not to	Paid for by the public; reuse by others.

Whatever the choice, three contract clauses do more than any licence debate: the state's right to its data in open formats, rights to the source code and documentation it needs to change supplier, and a funded exit plan.