Digital infrastructure needs governance that is digital in spirit and approach. As such, there is much that digital public goods projects can borrow from today’s digital and open-source working practices — things like working in the open, documenting decisions and security incidents, building communities of practice and continuous development. Where lessons from digital are maybe lacking is the creation of digital institutions for the long-term (the W3C is 26 years old, Google is 22, the Internet Engineering Taskforce is 35 and WhatsApp is only 12). If digital infrastructure is going to be truly ‘foundational’ then it will need to be persistent.

A good analogy might be to Trinity House which for over 500 years has been responsible for maritime safety in England’s coastal waters, including navigation aids, maritime radio/satellite communication systems, and education. It’s not part of government - it is an independent charity with a clear mission, paid for through a mix of fees paid by commercial vessels and an endowment. Oversight is provided by a court of thirty-one people, drawn from a wider group of lay people with marine experience. This shared infrastructure supports not only commercial operations, but also the business of government. The organisation does one thing and is funded to do so for the long-term.

The story of digital public goods, if it succeeds, will be one of institutions. They will need institutions that are persistent and resistant to sectional interests, and ones that can accommodate agreements and collaboration between governments of all shapes, sizes and levels. Institutions responsible for digital public goods will need to combine the best properties of good quality open-source projects and public service. It is not enough to publish code and it is not sufficient to expect existing organisations to adopt digital public goods without adaptation.

The twin institution question

The ‘build once, use many times principle’ digital public goods approach to infrastructure requires thinking about governance in multiple places. Digital public goods may require two types of governance — institutions to coordinate the design and maintenance of digital infrastructure, and institutions to operate instances of that infrastructure. Sometimes they will be the same institutions, often they will not. Both are critical. To explain why, let’s take three examples, each at different scales of operation.

The concept of a ‘Single Trade Window’ or ‘portal’ is promoted by international organisations including the United Nations and World Customs Organisation (the ‘window’ and ‘portal’ being not very helpful shorthand for ‘technology’). The idea is that, through use of technology and standards it should be possible to interact with a country as an entity for the purposes of importing and exporting goods. A company wanting to import medical supplies or animal feed into a country should not have to concern itself with the internal structure of that country’s government, or how its ports are administered; and dealing with one country should be much the same as dealing with another.

Superficially, this feels like the domain of digital public goods. Let’s assume that is the case and there is the potential for collaboratively maintained digital infrastructure in international trade facilitation.¹ Not a fully-fledged ‘trade stack’, but a set of reusable components that implement recognised standards and solve common problems (like looking up a trade tariff, submitting a declaration, or integration with international digital identity platforms). These in turn might free up a government to focus on the elements that are truly unique to their context.

The practical reality of digital services is that code needs to be written and only so much code can be written in a given period of time while continuing to ship improvements to the software. Any organisation developing common components for trade (or any other domain) will need to manage the competing priorities of different stakeholders (in this case, national governments) wanting different features.

Assuming useful, viable software can be created that makes it easier for a country to implement a ‘single trade window’, there is the question of how this should be implemented in a country? This too is an institutional question because embedding it in a piece of cross-government infrastructure in a departmental silo probably won’t work. There may need to be a new agency created. Or a partnership between government and port authorities. The answer will be different in different countries. These questions are even more apparent if we look at something like digital identity, where which arm of government has responsibility for identity (Home affairs? Local or state government? An independent commission?) has big implications for trust and funding.

To explore this further, let’s take a second example: taxi services. It is reasonable that an elected city government might want to implement its own taxi dispatch system that acted as a thin layer over commercial providers. It could allow cities to maintain quality of operators, whilst also acting as a counterbalance to the risk of dominance from a single provider, such as Uber or Grab, avoiding lock-in. It may also allow the kind of interventions that the private sector does not have the incentives to prioritise, such as using real-time analytics to monitor pollution and congestion.

Again we have the twin institution question. 1) How can an institution create a digital service that is good enough to meet the expectations that people have from using commercial service, while also managing competing priorities from different cities? 2) What sort of institutions need to be in place locally to provide a good service, enable policy outcomes and protect the privacy of the public?

The importance of a product paradigm

The trade and taxi examples assume that there is capacity to implement a local version. That seems reasonable in those examples. It feels reasonable to expect nation states and large cities to have some technical and institution-building capacity. But what about for smaller units of government? Let’s take the question of urban planning, a function that is often delegated to the smallest units of government. Again, let’s make the assumption that there is value in creating software for the management of changes to the built environment.²

As with the previous examples, there’s the need for some form of governance to manage the competing priorities of different local government users relative to a limited development recourse. But what about implementation? Are we really to expect every local government to maintain a technical team to implement their own version of the software? Probably not. We could leave it to private sector consultants to implement and operate, but the number of local governments in any given jurisdiction is unlikely to be high enough to create a genuine market. So it’s likely it would result in a monopoly supplier whose effort is subsidised through a digital public goods project.

In situations where it is unlikely or unreasonable that consumers of digital public goods maintain instances themselves, developers and funders of digital public goods will need to look at how institutions can be created to offer hosted versions. This might be directly by the teams responsible for the open-source project, or enabling a new regional institution (for example a cooperative of local governments or hospitals).

These are questions that those hoping to create digital infrastructure using the digital public goods approach will need to embrace. If they just see themselves as creating open-source software, they will likely have as much success as the long list of failed attempts at countering the dominance of social media companies through the creation of open-source alternatives.³ Above all, funders and developers of digital public goods need to have a product mind-set, focused on creating fully-fledged digital products that not only provide the raw materials, but also support implementation or provide the implementation themselves, and do so from a secure institutional setting.

The need for a digital observatory

In the essay on transparency, I posed the idea that radical transparency is one of the areas where the digital public goods ‘label’ can become a true differentiator from standard open-source projects and proprietary offerings. By systematically publishing information about how they work and how they are changing, digital public goods could enable scrutiny and reduce some of the risks associated with digital infrastructure. That obviously only works if there are organisations capable and empowered to scrutinise. For the same reasons listed above, that scrutiny will also need to apply at the level of the implementation and level of the overarching project.

When it comes to local implementations this is probably the domain of local regulators and data protection authorities. But what of global oversight? One option would be for funders of digital public goods to also setup an observatory that actively monitors the development of critical digital public goods. Such an observatory would monitor and report transparency, highlight potential risks and maintain independent registers of implementations. With appropriate agreements in place, an observatory could also provide independent verification of how implementations have been configured.

What can international organisations + open-source do that a standard open-source project cannot?

There’s one final intriguing question thrown up when thinking about institutions in the context of digital public goods and infrastructure: could existing international institutions became the custodians of digital public goods? If so, what options are open to official international organisations that are not open to a standard open-source project?