Why digital public goods matter

Richard Pope
Exploring Digital Public Goods
6 min readJun 9, 2021


Technology creates new contested spaces. Without a focus on digital public goods, governments and civil society could find themselves locked-out and locked-in.

It is becoming customary when writing about digital to reference how COVID-19 has changed the role of technology and data in government forever. Only time will tell if that is true in any strategic sense, or if it has entrenched a series of tactical responses that will need to be unpicked. Less cited is how COVID-19 has highlighted the power that technology companies have to shape and make policy.

Professor and researcher Jonathan Albright has compiled a dataset of the technology used by different governments to create COVID contact tracing, exposure and information apps. It shows the power of Google and Apple’s platforms:

I simply do not remember a time when global public communication channels have been so codified and platformitized. By this, I mean that 2020 marks the stage — quite literally — when hundreds of public health agencies and government communication channels simultaneously collapsed their efforts into exactly two tightly controlled commercial marketplaces: Apple’s iOS and Google’s Play stores. Not to mention the code infrastructure (SDKs) for at least half of these iOS apps has been built by one of the companies (Google).

Locked out and disintermediated

In creating tightly constrained, well engineered platforms, Apple and Google were not really doing anything different than they normally do. Their services, code infrastructure and platforms regularly place boundaries on what software developers and service designers can do. They regularly do this to protect the interests of their users or their business model (things which often, but not always, align). However, that approach, applied in the context of COVID-19, meant they were essentially making public policy. Governmental responses were only able to play out in the space demarcated by the design of their platforms. They are ‘locked-out’ of those policy decisions.

Rather than this being an exceptional event, we can expect that technology companies will continue to make plays in the spaces traditionally occupied by governments and civil society. Apple reportedly has plans to enter the passport space and have made mention of the role of technology in voting. Google is slowly adding drivers licences to Android. The commodity offerings of cloud providers such as Amazon Web Services, Alibaba Cloud, Microsoft Azure are increasingly in use by governments around the world for things like hosting and databases. But we can expect them to slowly ‘move up the stack’ and start offering more government-focused services — say payment systems or prescriptions. We could also point to Facebook taking on a small part of the role of an electoral commission and taking defacto responsibility for the publication and archiving election advertising.

The purpose of the examples above is not to point fingers at technology companies and certainly not to criticise the governments who used their services to rise to the challenge of COVID-19. It is to make the point that technology creates new ‘zones of contest’. Technology creates spaces where the politics of public vs private, central vs local, government vs civil society play out. We are used to hearing of technology as an enabler: this is technology as a limiter.

The more emerging technology companies encroach on the spaces traditionally occupied by governments, the more they may make architectural decisions that lock governments out of certain decisions. As their services become more central to the lives of the public and the development of public services, the risk of disintermediation of the state increases.

Locked-in and unable to govern

Possibly more familiar in the context of government use of technology is the concept of ‘lock-in’ — where the lack of internal capability means that a government has to rely on external partners to develop and operate technology, or where a technology partner gradually grows their influence over time to the point where a government agency is essentially ’captured’. The cost of moving becomes prohibitively high, either because the expertise to understand how to unpick the lock-in is outsourced along with the service provision, through the use of proprietary data standards or technology, or through contractual constraints.

Examples of technology lock-in government abound, including welfare payments in South Africa and desktop computing in the UK’s National Health Service to name just two. The point to make here, however, is that as technology becomes less peripheral to how governments and wider society operate, the costs of lock-in and capture become higher.

That higher cost is because of two characteristics of digital technology. Firstly, it is ‘path-dependent’ — that which already exists to some extent limits the direction it can take over time. It can influence standards, social norms and limits future decision making — the more foundational a bit of technology, the greater the effects. Secondly, there is the tendency of digital technology to move towards shared platforms or tools over time  — solving problems once rather than multiple times. Taken together these mean that being locked-in constrains more things in more ways as time passes. The more fundamental the technology is, or the closer it is to a core function of government or society, the more this should be a matter for concern. This is a point that the open-source digital payment platform Mojaloop makes:

We don’t want a single monopoly power in control of all payments in a country, or a system that shuts out new players.

If software is eating the world, then it matters whose software it is matters. Who gets a say in how it works and how it changes over time matters? As does which values, risk profiles and affordances are ‘baked in’?

Sovereignty through code

The response that some public institutions have made to lock-in is to form digital service groups — in-house teams with the capability and mandate to design and operate population scale digital services. In-house capacity should also (hopefully) give governments better situational awareness about the risks of lock-out too. But does that scale? (i.e. Is it an option open to all government’s, central and local, and public organisations, big and small?). And does it do so fast enough to counter the risk of lock-out by technology companies?

Maybe the digital skills shortage and related high costs is a transitional problem. Maybe soon any public institution — from the largest central governments to the smallest regional councils — that want to hire technologists will be able to do so with relative ease. Even if that is the case, there remains a large duplication of effort with multiple teams solving the same or similar problems. The complexity is, of course, that while a lot of what different governments do is the same, but the things they do that are intentionally different can be a matter of sovereignty.

One answer to this is to share software code between organisations. So, could more governments publishing their code, in addition to in-house capacity, be the answer? Waldo Jaquith and Robin Carnahan from the Beeck Center at Georgetown University have recently documented examples of cooperative code sharing between (mostly U.S. based) governments and agencies. There is also a long list of government organisations publishing at least some code on GitHub.

However, open-source, or the act of open-source-ing code, is likely not enough on it’s own. There needs to be the capacity to identify shared problems, build community, finance, maintain teams, create fair and open contribution models. As Carnahan and Jaquith note:

Successful co-ops tend to have a clear governance structure, deliver value to users incrementally, and focus relentlessly on user needs. New co-ops should start by identifying a shared need, seek to solve a small problem, operate under a clear governance structure, architect software to suit the needs of the members, and work in the open.

There may also be issues, not dissimilar to ‘lock-out’ as described above if less digitised governments become reliant on the software open-sourced by more digitised governments. All software can have biases or assumptions ‘baked’ into it. As with commercial software, different countries will design for different risk profiles and circumstances. (Note: ‘more digitised governments’ does not necessarily map to existing concepts of development and such governments are located in the Global South and North).

A digital public goods approach — combining the characteristics of good quality open-source projects with governance and harm prevention — in combination with some in-house capability to implement them, could be a way for governments to avoid being locked-in and locked-out and to do so in a way that works for different contexts. Not through building software that can be endlessly customised, but by creating shared infrastructure that solves a common set of problems and enabling in-house teams to focus on the problems that are unique to them.

The creation of digital public goods matters, not just because of the types of problem that individual examples might seek to address (access to welfare payments, land rights, reduction in administrative burden etc), but because they could allow public institutions to operate in the contested spaces that digital technology is creating right now.

The authors would like to gratefully acknowledge the Omidyar Network for supporting their research. The views herein, however, do not necessarily reflect those of the funder.