Imagining different: The state and open source
Recently I attended a House of Lords session on government technology reform and AI adoption. The discussion followed familiar patterns. Procurement constraints, talent development, modernisation imperatives, until one leader cut through with a simple challenge: “We must imagine what ‘different’ could look like.”
The phrase stuck with me because days later, two articles arrived that attempt exactly that.
Claudia Chiurlia, from GDS, used her broken washing machine as a brilliant analogy. When manufacturers don’t supply parts, appliances become disposable. When critical government system vendors dramatically increase their prices or withdraw support, the consequences escalate far beyond inconvenience. Her case for an open source strategy centres on resilience. Government needs the manual, not just the product.
Martha Dacombe, from The Startup Coalition, made an argument about institutions that also aligned with open source strategy. New bodies like ARIA and the AI Safety Institute prove world-class state capacity is achievable at pace. But they’re also workarounds that demonstrate Whitehall, as currently structured, cannot deliver what’s needed. Each new institution built to bypass existing dysfunction is a concession that we’ve stopped trying to fix the core.
Both diagnose the same underlying problem. We’re confusing activity with infrastructure.
What would genuinely different look like? A state that acts as steward, not merely consumer, of the code that underpins public services.
Government has some excellent examples of reuse. The Ministry of Justice built the GOV Reuse Library to catalogue components. LocalGov Drupal demonstrates that councils can collaborate on common platforms, and over 60 councils now share development of the same website infrastructure rather than each procuring separately.
These are successes. But they’re isolated examples. How can we translate them into systematic practice?
At the moment a damaging pattern of behaviour occurs. Let’s say that a department needs a form-building capability. Rather than checking what exists, they procure a new solution. Months later, another department builds something nearly identical. Multiple departments have independently built document management, case management, and publishing platforms, all on different stacks, each requiring separate contracts and maintenance.
The Technology Code of Practice endorses reuse, but provides no mechanism to enforce or even track it as things stand, and while the GOV Reuse Library catalogues components, it can’t mandate their use. Equally, it took an inspired team of MoJ professionals to make the Reuse Library a reality when GDS did not.
Even with these small steps in the right direction, a gap persists. We need a lifecycle, not just a library. Code should flow in both directions. When someone in government discovers what exists elsewhere today, they may adapt and improve upon it. It’s rare that somebody contributes those improvements back upstream so the next organisation doesn’t start from scratch. Both in relation to government code, and publicly available code.
This lifecycle is the open source model that already powers most of the internet. The question is whether government will adopt it or continue reinventing components with incompatible dependencies. Will government invest to stop the sprawl?
There’s a persistent misconception that open source means “free” which translates to “cheap.” This fundamentally misrepresents the way that these vital projects are created, improved, and maintained.
Open source investment takes two forms, and government needs to consider both.
The first is procurement that sustains ecosystems. When government buys enterprise open source products, it’s not merely purchasing support contracts. Instead, those agreements fund the engineers who maintain Kubernetes, patch kernel vulnerabilities, and ensure foundational projects remain viable. This isn’t charity. It’s infrastructure investment through commercial relationships that benefit everyone who depends on those systems.
Current procurement frameworks struggle with this model. They optimise for short-term cost reduction and risk transfer to vendors rather than architectural thinking about long-term value. Compliance-driven purchasing rewards contractual rigidity over adaptability. The result is procurement that often delivers neither sovereignty nor value, with closed systems creating dependencies without control. And, open source without contribution creates usage without influence, leading to missed opportunities for global soft power for government.
The second form of investment is direct contribution. Government standing up teams whose job is committing code to upstream projects. Not building another bespoke platform. Not maintaining isolated forks. Contributing directly to software that makes a huge impact globally (while still being able to pay an enterprise open source company to adopt and support that code).
This approach is radical only because we’ve normalised waste.
A Government Open Source Programme Office would address what no existing body currently handles. It would create connective tissue between isolated reuse efforts and systematic upstream investment.
Major technology organisations already run OSPOs, including Google, Microsoft, and Bloomberg, as do governments including France and the European Commission. OSPOs answer questions that teams otherwise solve badly, repeatedly, and in isolation. Which projects merit trust? How do we contribute safely? Who else has addressed this? Where should limited engineering talent actually focus?
Within Whitehall, an OSPO would sit logically within the updated GDS structure under DSIT, working alongside the government CTO role to translate policy into practice. Crucially, it would not centralise delivery, mandate technology stacks, or become another approval gate. It would provide the institutional knowledge that currently doesn’t exist anywhere, and guide people to understand which upstream projects underpin critical services, where contribution opportunities exist, and how to evaluate risk in open ecosystems.
This addresses accountability pressures that are already visible, and bolsters our digital sovereignty position. The NAO has repeatedly flagged technology duplication, with Public Accounts Committee reports documenting failed programmes and wasted procurement, and the Government Major Projects Portfolio tracking numerous high-risk technology initiatives. An OSPO would reduce these risks systematically rather than reactively.
OSPO may not be the banner under which we deliver this initiative. It may be badged as reuse, efficiency, or event software lifecycle management. But embracing open source as a strategic necessity is increasingly vital for national success.
In Martha Dacombe’s article, she describes the way that government creates new institutions to work around old ones rather than reforming what exists. The result is growing complexity without corresponding capability.
The alternative requires us to ensure that new efforts contribute to larger ecosystems rather than becoming modern legacy in isolation, adding to the sprawl.
Digital sovereignty emerges, in part, from participation in what matters. Engineers with commit access to vital projects, presence in architectural decision-making, and influence through contribution rather than ownership. This gives us the ability to retain agency.
This matters urgently as Britain makes decisions about AI infrastructure procurement, cloud framework direction, and digital sovereignty within DSIT. Recent analysis suggests effective strategy isn’t model-centric but ecosystem-centric.
This indicates that we must start building sovereign capability through participation across the entire AI stack, not through isolated national projects. This would enable interdependence globally, rather than the state of dependence we currently endure.
In Europe, the push for digital sovereignty could strengthen global open source through coordinated investment, or fracture it. If sovereignty responses default to regionally-exclusive code, the commons splinters. Projects like Linux and Kubernetes succeed because they’re genuinely international collaborations with thousands of contributors across dozens of countries.
Britain has an opportunity to build influence by developing national open assets, harnessing strong domestic ecosystems, and contributing to international projects. This approach pools purchasing power and enables collective influence over global markets. China has some major players like Huawei and Alibaba contributing to vLLM to shape upstream AI infrastructure.
France and Germany build sovereign platforms on open foundations using global standards.
The risk is procurement that delivers neither goal. Proprietary systems offer dependency without strategic control. Open source consumed passively provides tools without shaping power.
Different requires decisions currently deferred.
Departments should be required to justify new platforms where existing solutions could already meet shared functional needs. Procurement frameworks must reward contribution alongside consumption. Treasury models need to value sustained infrastructure over short-cycle delivery.
It means accepting that skilled government engineers should contribute to Kubernetes improvements rather than building the thousandth bespoke container platform.
This creates discomfort for those trained on departmental delivery metrics. “Why fund work on code we don’t own?”
Because that code already runs our services. Because upstream contribution provides leverage. Because one engineer improving infrastructure serving millions delivers more value than ten building isolated departmental systems.
Different means optimising for the system, not individual parts.
None of this requires five-year programmes or billion-pound budgets to begin.
The GOV Reuse Library already exists. LocalGov Drupal proves councils can collaborate. The Technology Code of Practice already endorses open source.
What’s missing is the institution that connects these dots. The OSPO that turns examples into patterns. The procurement vehicle that makes upstream investment as easy as buying another licence.
We could start with a single vertical. Pick one domain where duplication is most absurd. Healthcare data standards. Identity infrastructure. AI governance tooling. Stand up a team. Give them a clear mandate: contribute upstream, enable reuse, make it easier for the next team.
Prove the model works. Then scale it. Test, learn, grow.
If we don’t imagine different, the trajectory is clear. It’s already visible.
More isolated platforms accumulating technical debt. More new institutions bypassing unreformed core departments. More engineers solving problems that open source communities addressed years ago.
Increased spending delivering diminishing outcomes. Citizens comparing government services unfavourably with private sector experiences. Eroding trust in state competence.
Claudia and Martha aren’t making radical demands. They’re identifying what’s already broken and asking whether we’re prepared to fix it rather than work around it.
Different isn’t mysterious. Open source communities have proven the model works at scale. The question is whether government can adopt the discipline it requires.
We must imagine what different could look like.
The alternative is continuing to procure systems we cannot repair, while the same failures repeat at greater scale and cost.
