It’s a cliche to say the future is here, it’s just not evenly distributed. Normally it’s a cliche used in the context of the adoption of particular technologies, but it’s true of the affordances and the behaviours and that sit around technology too. As digital has moved from the periphery to the centre of public and private life, we have seen this play out again and again.

A few examples.

• Photo sharing website Flickr launched its ‘interestingness’ algorithm in 2005. Today, reading the responses on the community forums from 2005, we can tick off many of today’s concerns about algorithmic decision making (How does it work? Is it fair? Can it be gamed? What does it mean for localised or cultural variation?). Today, we ask those questions about automated decisions in welfare systems, rather than for sorting holiday snaps.

• In less than a decade, user-centred design has gone from a relatively niche practice to the way significant government services are designed. In turn, that’s raising questions about the power and accountability of technologists in directing public policy.

• The digitisation of political campaigning has seen the adoption of practices once the domain of bulletin boards and other early social media.

In emergent systems, the behaviours, processes and affordances that were once emergent or fringe become more important and established. So it seems reasonable to ask of the digital public goods approach to digital infrastructure: what have we seen play out in open-source software and with commercial platforms? How might those manifest themselves in an international, multi-stakeholder, governmental context?

Who gets to make a contribution?

The first to note is that open-source software development has a diversity problem. GitHub’s 2017 Open Source Survey found that 95% of respondents were men; just 3% women, and 1% are non-binary. Surveys also point to significant race and ethnicity disparities in open-source contributions.

Programmes like Outreachy (an initiative that provides paid, remote internships to people subject to systemic bias and impacted by underrepresentation in the tech industry where they are living) are trying to address these problems. Still, it only takes a visit to an open-source conference to see how entrenched the problem is.

Given the issues around diversity in tech are now widely known, how should funders of digital public goods projects ensure these statistics are not repeated on the projects they support?

There is also growing disquiet in some open-source communities about the range of institutions who contribute to certain open-source projects and the dependence of projects on those organisations.

Many of the most used open-source projects on GitHub are backed by companies like Microsoft and Facebook. Many companies also allow their developers to spend time working on open-source projects that relate to their work. In both cases, there is a question of whether the institutional incentives adequately align with the aims of the open-source projects.

As researcher Simon Wardley often notes, many companies also use open-source as a way to impact on their competitor’s value chains, or for their own advantage, the classic example here being Google’s role in the Android Open Source Project. Dependence on organisational support may also reduce an open-source projects likelihood of project survival - one of several factors that need to be understood in the context of digital public goods.

Hopefully, by providing clear funding and governance models, the digital public goods approach could provide a model for a different approach, where philanthropic organisations back the key bits of digital infrastructure needed by modern digital states. Could it also generate digital public goods that have a similar economic model to open-source projects that are reliant on a single company or the resources? Could suppliers and consultancies follow the Android model of releasing everything but the ‘crown jewels’ as digital public goods, as a way to expand their influence? Or attempt to dominate the development of individual projects? Will individual states start releasing digital public goods in an attempt to influence the value chain of others? Will funders of digital public goods be able to play this game better than suppliers or states?

Will open-source digital public goods lead to more openness?

Open-source is widely used, in part, because it makes it quicker and easier to make other software, and reduces reliance on proprietary code. This, is essentially the main argument of the digital public goods approach, as transposed to the context of nation states. However, as Karen Sandler and Bradley Kuhn from the Software Freedom Software Freedom Conservancy point out, ease of reuse is only part of a bigger set of ethical priorities for the open-source software community, that include transparency, safety and sustainability. Considerations that the corporate model for open-source development find it hard to prioritise.

Funders of digital public goods could replicate these behaviours. By focusing only on the needs of nation states to build digital infrastructure, they could undervalue the needs of citizens for transparency and legibility that open-source can enable. The aim of digital pubic goods should not just be the greater use of open-source in government, but the openness of the implementations too. This is where, I think, the nascent movement around digital public goods has an opportunity to use that label to truly differentiate the effort.

Might digital public goods be ‘captured’?

Openness is by no means guaranteed in perpetuity. Take the pattern in open-source software of taking a successful open-source project and creating a software-as-a-service version of it. It is an approach adopted both by the developers of open-source software, such as the databases MongoDB Inc and Elastic Search, and platform providers like Amazon AWS and Microsoft Azure, which provide on-demand versions of many open-source products. Sometimes, developers have tried to change the software license to make it harder for others to sell competing offerings. Elastic Search attempted to do this in response to Amazon AWS providing a competing software-as-a-service. Amazon AWS responded by recreating and supporting an open-source version.

Let’s say that some of the digital public goods offerings being developed today are hugely successful. So much so that commercial software-as-a-service providers start offering, for example, MOSIP, as an on-demand service. What safeguards need to be in place to make sure that the teams developing digital public goods keep them open-source for the long term? How would you feel about a single software as a service provider operating the foundational identity platforms for multiple countries? Could digital public goods offerings end up centralising control?

Similarly, what safeguards need to be in the situation where a government uses a digital public goods project as a starting point but customises it in a way that is not transparent to the public or civil society? Part of the answer to that will likely lie in governance.

Digital governance for digital infrastructure?

Digital infrastructure demands need governance practices that are digital in spirit and approach. There are now some fairly established categories of governance models and other socio-political infrastructure in open-source software. This article is going to dodge the question of the relative appropriateness of those models for digital public goods because it seems likely that we will see versions of all of those emerge with open-source projects adopting the digital public goods label. (It’s just that the benevolent dictator might be a product owner in a government digital service unit somewhere, and the foundations might end up as more fully-formed international organisations). The key will be working out how to combine each of those models with a public-sector ethos and for funders to understand what model is in place.

The point I do want to make is that, regardless of the chosen governance model, there are practices that will gain in importance around how software is actually made, day-to-day. Creating a functioning open-source project is not a case of publishing some code on GitHub. It’s a set of tools and practices for working in the open and documenting decisions and changes. The Mojaloop project is a good example of this in practice. Not only is the code open, but so is the documentation and code of conduct. There is a Slack community, a mailing list and regular community meetings. The roadmap and backlog are published in the open. These are all standard approaches in mature open-source projects but are often absent in the cases where government projects do publish their code.

When it comes to thinking about governance processes for digital public goods, these are the places those processes will play out. Funders of digital public goods should be looking here to embed governance processes rather than layering them on top. And they should be looking for opportunities to embed openness at every level, not just software code.

The above list is by no means exhaustive, but hopefully it is enough to make the point that funders, creators and implementers of digital public goods can use existing practices and behaviours in open-source to understand how their projects might play out. Further, there are many opportunities for collaborations with those studying open-source communities and power dynamics today.