Why build infrastructure? Answer: to enable other things to be built with it that meet the needs of the public in some way or another. Payment infrastructure, for example, is used for everything from making welfare payments to paying for a taxi. Thinking about building public services from (or is it ‘on top of’? Or ‘with’?) digital infrastructure means thinking about the experience of building those services and the nature of the services that can be built. The former mostly consists of concrete day-to-day things, like the experience of software developers. The latter means considering some big conceptual questions, like the role, shape and stance of the state. Both are, however, related.

Design for self-service

Several of these essays have tried to underline the importance of understanding the needs of the designers, developers, policy-makers and others who will implement public-facing services using digital public goods. By understanding their needs, the aim is to maximise uptake by minimising implementation effort. Something being open-source is not enough. It needs to be well documented, have code libraries accessible via commonly used package managers and are quick to try out. And of the need to think about local implementation, as well as central governance. As such, digital public goods projects should aim to follow the principles of self-service that are employed by successful platform teams.

Also, as previously noted, if an individual digital public goods project does too much, it is more likely to constrain than empower. Taking a ‘small parts loosely joined’ approach should make it easier for organisations closer to local users to build services that meet the needs of the public, rather than predetermining those needs. Empowering local delivery by teams is where I think the seemingly prosaic questions of the experience of building services relate to the bigger questions about the nature of the digital state.

The myth of ‘government in a box’

The term ‘government in a box’ sometimes gets used in the context of the wholesale replication of digital services from one state to another jurisdiction. I’d argue that the term should be avoided as the framing for digital public goods and digital infrastructure. It’s too simplistic and risks presenting government as some deterministic machine.¹ That is why the infrastructure approach to digital public goods - focusing on the genuinely foundational - feels like the right one. Not only does it fit with the emerging platform model of government, but it also has the potential to enable local variation, rather than imposing a particular approach. Without enabling local variation in the delivery of public services, the hope of digital public goods building sovereignty could be false.

For this reason, I argue that the community that is building around digital public goods should actually double down on the focus on infrastructure, even if it means less software carrying the label of ‘digital public goods’. Digital public goods should become synonymous with infrastructure.

The reason enabling local variation is important is because software embodies political decisions. If those decisions come pre-made, what does it mean for the agency of the public and the politicians they elect? There is a tendency in digital transformation to shy away from the social and political implications of the digital state. To some extent that’s understandable. It’s a simpler message to deliver the (already often complex) message about the practical application of digitisation without adding in the out of context and the political. However, it stops us asking some fundamental questions like: what will the digital state feel like to be a citizen of? Where will power lay? What types of behaviours will it enable? What are the bounds of the state? What is it’s ‘stance’?

The characteristics of the digital state

By focusing effort on digital public goods that solve genuinely foundational and common problems, I hope it creates more space for the conversations about the type of digital public services that communities want and need and the qualities those services embody. Thinks like:

• The weight of administrative burden — real-time digital services can free the public from administrative burden, or they can place new burdens on the public.

• The boundaries of what constitutes a digital public service — just as countries may historically have chosen to have their healthcare or postal services operated as public services, which digital services should be operated as such?²

• The balance of power with commercial operating systems — how will public services integrate with commercial operating systems like iOS and Android?

• Abstraction of institutions — digital services can abstract or hide previously familiar organisations. To what extent is that desirable and when might it reduce the legibility of the state and understanding of who is responsible for services?

• Interoperability across borders — standards and digital infrastructure can abstract away differences when interacting across borders ³

• Uncertainty and access to recourse - automated decisions and interoperability of data can make services that ‘just work’, but without clear routes to recourse and explanation they risk creating outcomes that are uncertain to the public.

• What gets joined together when - digital identity can enable disparate datasets about people to be joined together. When should administrative friction or explicit consent required? When are multiple identities for different domains desirable?

The appropriateness of any given bit of technology to a particular policy area or place should always be a matter for communities and elected governments. I hope that, when it comes to measuring the success of digital public goods is assessed, in addition to the United Nations Millennium Development Goals, it also allows governments everywhere to get ahead of these questions of what public services will be like in the digital state.