If digital public goods are going to have the effects hoped for, there will need to be clear routes for their creation, maintenance and adoption. Otherwise, there is a risk of ‘performative openness’, where source code is published in the hope that it is reused. Or because it is seen as the ‘right thing to do’.

So, what might the routes be for creating digital public goods that meet genuine user needs?

Five models for creating digital public goods?

It is obviously early days in the story of digital public goods, but I think we can guess at some patterns from existing projects and software development more generally.

Placing a bet (The MOSIP model)

There is a strong enough indication of a common need to create a dedicated new team. The team is independently funded to create a bit of reusable infrastructure from scratch. The hypothesis is tested through implementation.

Organic adoption (The Notify model)

A government or agency creates a digital product for its own purpose and releases the source code under an open licence. Other governments fork that code and implement their own version, and they may or may not share code back into a common repository.

Export (The X-Road model)

A government or agency creates a digital product and spins out into a new or pre-existing organisation responsible for managing the codebase. This could be as a logical next step of the organic adoption model, or potentially aiming to create global public value or soft power.

Professionalisation/takeover (DHIS2 model)

A government or agency has created something that has the potential to be reused. A team is funded to support ongoing development and reuse (as opposed to for a single use case). This could be a logical next step of the organic model. There may also be situations where a philanthropic organisation unconnected with the initial project identifies potential value and essentially undertakes a ‘friendly acquisition’ of the project.

Corporate ‘donation’ (Exposure notifications model)

A technology company creates a piece of shared infrastructure or standard. The motivations for doing this may vary. As technology companies move more into the civic space, there may be more instances of this. The Apple/Google exposure notification system is probably the closest example to this (although much of it is not open-source).

It may well turn out that there are additional models to these five, but, regardless of the number, it feels like a good hypothesis to have that a healthy digital public goods ecosystem will require a mix of different approaches: an ecosystem that allows for routes for both emergent and top-down routes to usage.

Measuring usability as a route to adoption?

What about adoption? We know from the adoption of government as a platform components, and from general open-source development, that it is not enough to write code. The needs of the developers, administrators and designers need to be understood and met. Things like good documentation, self service and example code are important.

Usability is hard to measure in the abstract, after all, the existence of documentation does not mean that it can be followed. One option that could be explored by funders is commissioning a team to independently review the usability of different digital public goods from the point of view of teams needing to implement them. How easy is it to set up? Does it have updated documentation? Is it interoperable with other systems? How responsive is the support community?

Separately, funders of digital public goods should be routinely interviewing the implementation teams to understand what works and what can be improved. This should be in addition to any attempts to measure the impact of the technology on a particular policy outcome.