Open source helps governments shift from technical debt to technical equity
Open source, shared standards, and long-term stewardship can help governments move beyond technical debt and build lasting technical equity.
-1783661616299.jpg)
When governments evaluate open-source solutions, they can inspect the code, understand the maintenance model, assess the contributor ecosystem, and determine whether the software can be supported by more than one supplier. Image: Canva
Public sector teams are often constrained by short-term funding and procurement cycles.
A department may focus on launching an immediate digital service. But when a supplier contract ends, institutional memory can leave with it. A few years later, a new team may be asked to continue the work with different suppliers, different architecture, and many of the same constraints.
This cycle can produce working systems. It can also create something costly and often hard to see: technical debt.
In the public sector, technical debt is not just outdated code. It makes future changes more difficult.
Technical debt appears when systems cannot share data, when accessibility is not prioritised, when documentation is incomplete, or when public institutions depend on one supplier for routine improvements.
Following a recent visit to Singapore, where we spoke with civic tech leaders across government-adjacent, practitioner, and public interest tech communities, one question stood out: will today’s digital investment create public capacity that lasts?
That question frames the shift from technical debt to technical equity.
Unlike technical debt, which accumulates through isolated projects, technical equity creates long-term institutional capacity. It relies on open standards, modular architecture, and active stewardship to ensure systems remain maintainable, cost-effective, and adaptable for future teams.
From ownership to operational stewardship
Governments often focus on technology ownership: who owns the code, the contract, or the intellectual property?
For digital public infrastructure (DPI), ownership matters, but it is not enough. The critical question is stewardship.
Stewardship asks whether a system can be responsibly maintained, improved, governed, and reused over time. It asks whether public investment strengthens public capacity or increases long-term dependency.
Open source and open standards can reduce risk by allowing governments to inspect how systems work, avoid single-supplier dependency, and reuse components across programmes.
But openness alone does not guarantee public value.
A public code repository without maintainers, documentation, accessibility practices, security review, and a path for improvement is not yet infrastructure. It is an asset with unmet potential.
DPI requires operational stewardship: the continuous work of keeping shared systems secure, inclusive, performant, and adaptable.
One useful example from Singapore is Oobee, formerly Purple A11y, developed by GovTech Singapore. Oobee is an open-source accessibility testing tool that helps teams identify and address accessibility issues in digital services.
By making the tool available beyond a single programme or institution, GovTech Singapore has contributed a practical resource that other teams can learn from and adapt.
Open source as a mature software option
Open source should not be treated as an experimental alternative. In many settings, it is already a mature, commercially supported, widely adopted software option.
When governments evaluate open-source solutions, they can inspect the code, understand the maintenance model, assess the contributor ecosystem, and determine whether the software can be supported by more than one supplier.
That visibility can support better due diligence before investment decisions are made.
Commercially-supported open-source systems can also reduce long-term licensing pressure and help public institutions avoid upgrading paths that are controlled only by supplier roadmaps.
The key question is not simply whether the software is open. The question is whether it is actively maintained, secure, documented, accessible, and governed in ways that support public value over time.
The US offers one example of how this thinking is being formalised in policy, but the underlying issue is global.
In the US, open-source software can align with Federal Acquisition Regulation definitions of commercial software when it is customarily licensed to the general public.
In 2024, the SHARE IT Act directed federal agencies to share custom-developed software code and related materials across government, with the goal of reducing duplication and improving reuse.
The broader lesson applies well beyond one country: when governments share code, standards, documentation, and architecture patterns, they can reduce waste and make public investment work harder across institutions.
Procurement is where technical debt often begins
Technical debt is often treated as an engineering problem. In reality, its causes appear much earlier. They appear in procurement and commissioning.
If a tender rewards speed without maintainability, the result may be a system that launches quickly but becomes expensive to change.
If evaluation criteria do not ask about reuse, open standards, documentation, accessibility, security, or long-term maintenance, those qualities may not appear in the final system.
Procurement is where public value is designed. A technical equity approach encourages governments to ask different questions before they buy:
- Has the team reviewed existing open-source tools, shared components, or cross-agency systems that could meet this need?
- Can future teams maintain, inspect, and adapt the system without starting again?
- Does the supplier have a credible record of contributing to or sustaining shared open-source ecosystems?
- Are accessibility, security, and performance testing built into the delivery process?
Will the system leave behind reusable assets, documentation, and institutional knowledge?
These expectations can be built into supplier agreements, delivery plans, and acceptance criteria.
For example, teams can use open verification frameworks such as OpenACR to support accessibility assessment, and they can require content systems to support recognised accessibility authoring practices so staff do not unintentionally create barriers when publishing content.
The human side of infrastructure
Modernisation is not only about technical architecture. Sustaining an infrastructure requires people, practices, governance, and continuity.
Accessibility is a clear example. It is not a checklist to complete at the end of delivery. It is a measure of software quality and service inclusion.
Third-party accessibility overlays and widgets may appear to offer a shortcut, but they fail to remove underlying barriers and can introduce privacy, security, and usability concerns.
A more sustainable approach is to build accessibility in early. Teams should use semantic HTML, inclusive design practices, and automated testing tools such as Axe, or Oobee throughout delivery, not only before launch.
Accessibility also connects to digital sustainability. Heavy pages, redundant libraries, and poorly optimised scripts consume more bandwidth and energy than necessary.
Lightweight, performant, semantic interfaces are not only better for sustainability; they are also more usable for people on older devices, slower connections, or assistive technologies.
The next test for modernisation
The next phase of digital government should not be measured only by the number of systems launched. It should be judged by whether those investments leave public institutions stronger.
A modern system should not just work on launch day. It should be easier to maintain next year. It should be easier to integrate, audit, and adapt when policy changes. It should make accessibility, privacy, sustainability, and security easier to sustain.
Every digital investment makes a choice. It either adds to the technical debt that future teams must manage, or it builds the technical equity that future teams can use.
----------------------------
Bill Ogilvie is Chief Strategy Officer at CivicActions, where he leads the company’s global strategy for advancing DPI, DPGs, and open-source innovation in government.
Mike Gifford is the Open Standards & Practices Lead at CivicActions. He is a W3C Invited Expert who focuses on intersecting open government, digital accessibility, and sustainability.
CivicActions is a US-based mission-driven steward of the Digital Commons. We build public capability, cultivate communities, and advance the governance, technology, and shared solutions that create lasting public value worldwide.
-1783304403050.jpg)
