Open-source software is moving deeper into government infrastructure. Public agencies increasingly use shared code, open standards and reusable platforms to reduce dependence on individual vendors, improve interoperability and give institutions greater control over critical digital systems.
But making software open does not make it self-sustaining.
As governments begin treating open source as part of digital sovereignty, a harder engineering and economic problem is emerging: who pays the people responsible for maintaining, securing and updating the code once public services depend on it?
The OECD’s 2026 Digital Government Outlook argues that open source can reduce dependence on single suppliers, support interoperability and allow critical systems to be independently inspected. But the same report warns that adopting it without plans for maintenance, sustainable funding and clearly assigned security responsibility can create new problems rather than solving old ones.
That distinction is becoming central to the future of digital government.
Open source is becoming part of the government stack
Government software is no longer limited to websites and administrative databases. Modern public infrastructure increasingly includes digital identity systems, data-sharing platforms, notification services, cloud environments and components shared across multiple agencies.
The OECD describes these shared systems as foundations of digital public infrastructure and says they can reduce duplication and allow institutions to operate more coherently. Yet its latest assessment found that, on average, only 63% of public institutions are connected to their national data interoperability systems across OECD countries.
Open-source software offers governments another route to interoperability because the underlying code can be distributed, modified and reused rather than remaining controlled by one vendor.
Europe is now explicitly connecting that model to technological sovereignty.
In June 2026, the European Commission adopted a new Open Source Strategy designed to expand open-source alternatives in priority areas and increase their use across public administrations.
The Commission says its approach rests on three pillars: trusted assets, empowered communities and strong governance. Crucially, it describes a resilient public-sector ecosystem as depending on secure and well-maintained open digital assets rather than merely publishing more government code.
That changes the policy question. Governments are moving from asking whether they can use open source toward asking how they can keep it healthy for years.
Free software still has an economic cost
Open-source licenses remove licensing barriers. They do not remove engineering costs.
Maintainers still review patches, respond to vulnerability reports, manage dependencies, publish releases, write documentation and make architectural decisions. When a widely used project lacks enough people to do that work, every organization depending on it inherits some of the risk.
Research from GitHub, Harvard University and the Linux Foundation provides a useful picture of how the ecosystem is financed.
A survey covering 501 organizations estimated that organizations contribute roughly $7.7 billion in annual value to open-source software. But 86% of that investment comes through employee and contractor labor, while only 14% takes the form of direct financial contributions.
The imbalance matters because open-source consumption is much easier to measure than open-source responsibility.
The same research found that only 21% of surveyed organizations contributed to projects, even though far more depended on open software, while just 6% identified comprehensive security audits as a priority.
In economic terms, popular open-source components can start to resemble public infrastructure: thousands of organizations benefit from them, but individual users have limited incentives to fund their upkeep proportionally.
That works until something breaks.
Security turns maintenance into infrastructure work
Maintenance is not only about adding features or fixing ordinary bugs. For foundational software, it is increasingly cybersecurity work.
Linux Foundation research surveying 539 open-source maintainers and core contributors found gaps in organizational security policies and dependency management. The study concluded that open-source supply chains remain exposed partly because security practices vary significantly between projects. Policies requiring security protocols were in short supply, while dependencies were not effectively managed.
More recent global research shows the problem persists on the user side.
Among organizations surveyed for the 2025 State of Global Open Source report, only 31% used automated security testing before adopting an open-source component, while 28% manually inspected source code and 36% evaluated direct dependencies.
Government procurement therefore cannot treat an open repository as proof that software is secure.
NIST’s Secure Software Development Framework makes the broader engineering requirement explicit. Secure practices need to be integrated into the software development lifecycle so organizations can reduce vulnerabilities, mitigate the consequences of undiscovered flaws and address their root causes.
Its 2026 DevSecOps work similarly emphasizes continuous security monitoring and improvement as modern software development grows more complex.
For governments using open source, that means procurement cannot end when software is installed. Someone must remain responsible for vulnerability disclosure, updates, dependency changes and long-term technical stewardship.
Europe is experimenting with paying for the invisible layer
Some governments are beginning to treat maintainers more like infrastructure providers.
Germany’s Sovereign Tech Agency says it has already invested more than €41 million across 112 critical open-source infrastructure projects. Its Sovereign Tech Fund specifically finances open software components that underpin economic activity, including deeply embedded libraries, standards and development tools.
The model goes beyond grants to projects.
Its expanded 2026 fellowship programme supports 14 maintainers, community managers and technical writers, recognizing that sustainable infrastructure requires not only code but documentation, contributor onboarding and healthy communities.
The European Union is experimenting with similar intervention. Its FOSSEPS programme has funded security work on projects including Nextcloud, Keycloak, BIND, Jenkins, FFmpeg and ImageMagick, using bug bounties to strengthen software already relied upon by European public administrations. The programme explicitly links those investments to the resilience of public digital infrastructure.
These efforts point toward a different way of thinking about government technology spending.
Instead of purchasing only finished products, governments may increasingly need to finance the shared technical foundations underneath them.
Digital sovereignty requires stewardship, not just ownership
Open source can reduce vendor lock-in, but sovereignty cannot simply mean replacing a proprietary dependency with an underfunded open one.
A government may possess the source code and still lack engineers capable of maintaining it. It may be legally free to modify software but operationally dependent on a handful of external maintainers who understand the system. It may also discover that forking an abandoned project transfers the entire maintenance burden to the public sector.
The OECD therefore emphasizes active stewardship and sustained funding, not openness alone.
That is the deeper lesson for builders, public-sector technology leaders and investors.
Open source has succeeded partly because organizations can reuse enormous amounts of engineering work without negotiating a commercial license for every component. But as that code becomes embedded in identity systems, cloud platforms, cybersecurity tooling and public services, maintaining it starts to resemble infrastructure management.
The next stage of government open source may therefore be less about publishing repositories and more about building institutions around them: dedicated engineering teams, open-source programme offices, security processes, procurement rules and predictable funding for upstream maintainers.
Digital sovereignty is not achieved when governments can see the code. It is achieved when they have the people, funding and technical capacity to keep that code working when everyone depends on it.
