Consider an illustrative government team that takes delivery of a new case-management system. The supplier has met the contract: the application is live, the source code sits in a repository, and a final training session has been held. Six months later, a change in eligibility rules exposes the difference between possession and control. No one on the institutional team knows which configuration affects the calculation. The repository has not been updated since handover. A security patch requires a deployment process that only the departing supplier understands. The service owner can see the problem but cannot safely change the system on which citizens now depend.
Open source did not cause that failure. It did not prevent it either. For public digital services, open source becomes a sovereignty advantage only when the institution can govern, maintain and adapt the system as an operating asset. Access to code is valuable, but it is only one condition of practical control.
That distinction is increasingly relevant as governments and development partners look for alternatives to opaque platforms and long-term vendor dependency. The ITU–UNDP Open Source Ecosystem Enabler initiative explicitly frames open source as a potential accelerator for government digital transformation, while warning that deployment and maintenance require new skills and sustainable maintenance plans. The useful question for public leaders is therefore not whether a system is open source. It is whether the service can remain safe, responsive and accountable when its original implementation arrangement ends.
Source code is an input, not an operating model
Open source means more than visible code. The Open Source Initiative’s Open Source Definition requires licence terms permitting use, redistribution, modification and derived works, alongside its other criteria. A source-available licence does not necessarily qualify. That can give public institutions important options: teams can audit components, commission a different provider, extend a service for a local workflow, and avoid being locked into a proprietary codebase by default. It can also make it easier for local firms to compete for support and integration work.
None of those options is automatic. A repository without clear deployment instructions, architecture documentation, test coverage and current dependencies is not a viable handover. Nor does a permissive licence settle who is responsible for fixing an incident at 2 a.m., reviewing a security advisory, responding to a user’s correction request or approving a change to a benefits rule.
The distinction matters especially for systems that are integral to public administration: identity verification, registries, payments, permits, social protection, health information exchange and field-service tools. These are not finished products that can be left on a server. They are evolving services shaped by policy, staffing, security events and the daily experience of users. An institution needs the ability to direct that evolution even when specialised engineering remains partly outsourced.
Control is a set of practised capabilities. It includes knowing the critical components, understanding what data enters and leaves the service, approving changes, running a recovery procedure, commissioning independent support and making a defensible decision when risk and service continuity conflict. These duties belong to the institution even when much of the technical work is contracted out.
The current policy signal is about ecosystems, not free software
The recent emphasis on open source in digital public infrastructure is often read as a simple procurement preference. The more useful reading is institutional. UNDP and ITU describe OSEE as an initiative to support and catalyse country-level open-source digital ecosystems. Their material notes both the potential for greater government ownership and reduced vendor lock-in, and the need for sustainable maintenance, new skills and engagement with communities and local digital ecosystems.
That is a more demanding proposition than downloading a reference implementation. A healthy ecosystem has maintainers, implementers, documentation, security practices, user feedback routes, procurement pathways and a realistic budget for work that happens after launch. It allows public agencies to benefit from shared software while retaining responsibility for the service rules and data they are legally authorised to administer.
The World Bank’s May 2026 account of its Global Digital Public Infrastructure Program makes the same broader point from a service-delivery perspective. It describes support for digital identity, payments and secure data sharing through interoperable foundations anchored in inclusion, privacy and user trust, rather than isolated systems. These foundations are useful only when they can be governed and reused across real services.
For African governments, the choice should remain deliberate. Define the public capabilities that must stay portable and governable, then select open-source and proprietary components by maturity, support, security and total cost of ownership.
Maintenance is where the economics become visible
An open-source licence may remove a recurring licence charge. It does not remove the costs of operating a system. Hosting, monitoring, security updates, backups, accessibility improvements, technical support, integration work, user research, documentation and staff time remain. In a low-resource environment, a design that assumes continuous expert availability or unlimited cloud spending can make an ostensibly low-cost solution expensive to keep alive.
This is where public programmes can make an early error. A project budget may fund discovery, configuration and launch, while treating maintenance as a future line item for another institution or funding cycle. The result is predictable: the service begins to drift, routine fixes become risky, and staff return to spreadsheets, WhatsApp messages or paper registers because they are more reliable than an unmaintained digital process.
A maintenance plan need not be elaborate. It must be explicit. It should identify the system owner, core maintainers, support channels, update cadence, security responsibilities, service-level expectations, documentation standards and funding source for the next operating period. It should include a tested backup and restoration process rather than a statement that backups exist.
The cost question should be comparative. A proprietary platform with strong local support may be the safer choice for a bounded workflow. An open-source component may be superior where an agency needs control over a strategic interface, a reusable capability or a locally specific service rule. The relevant comparison is not licence cost alone. It is the cost and risk of operating, changing and eventually replacing the service at scale.
Local ownership must reach beyond the IT unit
Public institutions sometimes interpret capability transfer as a technical training event for a small IT team. That narrows the problem too far. A service cannot be governed by infrastructure administrators alone. Policy owners need to understand the rules encoded in workflows. Records and data-protection teams need to know which data are exchanged and retained. Procurement officers need evidence on support performance. Front-line teams need a route to report failures that affect citizens. Senior leaders need a view of whether the service is meeting its public purpose.
This wider model matters where staff turnover is high, teams are small and a central digital unit supports many ministries or local authorities. It avoids the fragile assumption that one specialist will carry institutional memory. Published interfaces and usable documentation also let universities, civic-technology communities and local firms contribute without needing to replace a whole platform.
Runbooks written only for specialists, support paths that assume a personal laptop, and approvals that require uninterrupted connectivity can exclude the people who operate a service. Ownership design should account for shared devices, decentralised offices, variable connectivity and manual fallbacks.
Open standards keep future choices credible
Open source does not by itself guarantee interoperability, and open standards do not by themselves guarantee that a government can operate a system. Together, they can reduce the cost of keeping future options open.
GovStack’s analysis of digital sovereignty presents open, reusable specifications as a way to describe functions and interfaces in vendor-neutral terms. That is an architectural argument, not proof that any particular deployment is interoperable or publicly controlled. A specification does not make a registry, payment system or identity service real, and it does not determine the lawful authority governing it. The government’s deployment, operating arrangements and accountability mechanisms remain decisive.
In practice, public buyers should specify portable data formats, documented interfaces, audit requirements and testable export procedures where these serve a clear service need. They should avoid confusing a long standards catalogue with interoperable practice. Two systems only work together when institutions agree the meaning of a record, the permitted purpose of access, the process for correcting errors and the responsibility for resolving failure.
Operational and personal data should remain in the governed systems responsible for them. If several independent parties require shared proof of a transaction, provenance or settlement, a jointly governed registry or ledger may be appropriate. It should not become a substitute for data quality, access control or the authority to make a public decision.
A small capability test is more valuable than a large promise
Before selecting a strategic platform or approving a national-scale implementation, leaders can test whether a proposed service can genuinely be owned. The test should use one consequential workflow, such as a licensing change, an eligibility correction or a service outage. Ask the institutional team, not only the supplier, to explain what they would do.
Map the service. Identify the decision it supports, its data stores, interfaces, manual fallbacks, users and named accountable owner. This exposes where an apparently simple application depends on an unseen platform or contractor.
Run the handover. Require institutional staff to deploy a safe change, retrieve a usable export, restore a non-production backup and use the operating documentation. Record where supplier intervention is still needed and why.
Fund the next year. Cost monitoring, maintenance, security work, support and targeted capability development separately from the build. A launch without an operating budget is an unfinished service.
Measure retained control. Track the time and cost required to complete an approved change, resolve a priority incident, onboard a new support provider and produce an auditable data export. These measures say more about sovereignty than a procurement label.
Xelius supports institutions and delivery partners to map service dependencies, design maintainable data and platform architectures, and build the operational capability needed to govern systems after launch. The most productive first engagement is usually not a platform selection exercise; it is an honest examination of the service that must remain under public control.
The public asset is the ability to adapt
A government does not need to write every line of software to retain agency. It does need to understand what it relies on, preserve the right and capacity to make changes, and ensure that a citizen-facing service does not become ungovernable when a contract, grant or individual contributor disappears.
Open source can strengthen that position, but only through sustained maintenance, documentation, funding and sound operational decisions.
