Code to country: what governments can learn from open-source software

The article is written by David Durant, freelance Agile Delivery and Digital Transformation Specialist.

• The problem: Governmental policy and service delivery often lack the iterative, open and collaborative methodologies that have proven successful in open-source software development.
• Why it matters: Adopting these methodologies can lead to more effective, resilient and citizen-centred public services, ultimately enhancing the quality of governance and societal outcomes.
• The solution: Governments should integrate principles from open-source development, such as modularity, prototyping, open collaboration and continuous feedback, into their policy and service delivery processes to foster innovation and adaptability.

At first glance, it may not look as though there is much in common between providing the extraordinarily wide-ranging governance of a nation state and the development of, often relatively small, software systems. One could look at the so-called Benevolent Dictator for Life models of leadership for some of these systems and compare them, favourably or otherwise, to how various countries elect, or inherit, their Heads of State. However, I think there is a lot more than can be gained from some closer inspection of how these groups function.

Throughout this article, I will be writing from a UK context but I believe there are insights that can be applied anywhere.

Here in the UK, further development of government technology will no doubt have a huge impact on the lives of citizens. Examples include ‘GOV.UK’. OneLogin potentially evolving into a ‘government account’ and the oncoming huge impact of AI. That said, while deployment of technology might at first seem to be the natural place to put these lessons into practice and some of them have already been codified in the UK Service Standard, I believe they can apply to almost all areas of government.

I will map some parts of this discussion to the Agile software development manifesto principles. Working in an Agile way is not a prerequisite for developing open-source software but many of their principles overlap and it can provide additional insight.

Small pieces loosely joined

One of the key tenets of open-source development is the concept of small pieces loosely joined. This could be associated with the Agile principle of “Welcome changing requirements, even late in development”. The key thing here, whether delivering policy or software, is to enable contributors to work on sections of delivery that follow two simple rules. Firstly, that they are fast to create and evolve, so that incremental updating, based on testing and feedback, becomes easy and allows for quick pivots where necessary. Secondly, those sections of delivery have very well defined borders (called APIs in open-source software) so everyone involved clearly understands both the remit of the piece of work and how to work with it.

In the private sector, much has been made of the so-called ‘Bezos memo’, in which Jeff Bezos, founder of Amazon, insisted that every team in that organisation was normalised along these lines.

It can become very important, though, to understand how these pieces interconnect and to make sure your organisation doesn’t develop into the situation shown in the cartoon below.

Prototyping and customisation

From the very beginning, open-source software has ensured that its methods of development are undertaken in such a way as to enable the easiest possible methods of extension-by-prototyping and customisation to specific environments.

Software code for such projects is often stored in a huge online repository called GitHub, which everyone can access for free. Anyone can ‘clone’ an existing code repository to create their own personal version through a method called forking. These ‘forks’ can then be updated to be used as experimental prototypes without there being any danger of causing issues in the original codebase, which is said to be ‘upstream’.

The important thing in this arrangement is that new updates to the original system, often called ‘patches’, are ‘migrated upstream’ to the ongoing prototype. This means that the prototype absorbs all the new best practices from the majority of contributors who are still working on the ‘main branch’, while still being able to safely test out their own new ways of doing things. Sometimes these prototypes become their own entire new applications so that users now have several different flavours of product to choose from, each tailored to slightly different user needs. Each also benefits hugely from being based on an underlying common, regularly collaboratively updated, codebase. A fantastic example of this is the various distributions of the Linux operating system.

In relation to the delivery of policy intent, I would strongly compare this to the idea of “local scoping”, as defined by Hillary Cottam in her excellent book ‘Radical Help’. In the book, she describes how her team developed a number of different citizen-centred facilitation groups organised around capabilities-based thinking. These focused on clearly demarcated groups, such as job-seekers, older people or so-called “troubled families”. When one of these endeavours was shown to be successful, as many were, they were offered as a package for local authorities to implement. Part of that process was using prototyping methods to customise the methodology for their local circumstances, such as urban vs. rural settings.

Each new version could be considered a ‘fork’ of the original implementation that can still learn from new best practice developed by the original core team. Over time, some of these customisations could become their own ‘distributions’, e.g. one focused on rural areas. Other councils with similar circumstances could use that specific distribution of the methodology to kick-start its deployment in their area.

Measurement

One thing I hope to be hearing a lot about in the future, as the new UK government moves towards mission-based thinking, is how the assessment of policy delivery will be measured. Under traditional New Public Management thinking, this is achieved by setting targets. There are many issues with this, not least Goodhart’s Law, which is commonly stated as "When a measure becomes a target, it ceases to be a good measure" — any target can be gamed.

In the open-source community, people often look to the Agile principle of “Working software is the primary measure of progress”. This can be interpreted in a number of ways but there are two primary common methods. The first is ensuring that the product regularly, often nightly, passes a large number of small simple tests. These ensure that no new changes have broken its existing functionality. The second is through feedback from users. Feedback through forums and mailing lists usually very quickly gives an indication as to whether bug fixes or new features meet the standards of the community. These kinds of metrics are considered much more important than simple statistics, such as the number of times a product has been downloaded.

💬 Let the author know how do you think the government can measure and prototype policy and service delivery improvements of by leaving a comment below

The UK government currently has either no, or very limited, methods of testing whether the introduction of a new policy will break the delivery of an existing one for any specific sets of citizens. It would be very interesting to discuss how this might be done. In addition, the government has very limited mechanisms in place to allow feedback from citizens about delivery of policy. The few that do exist include user research, consultations and responding through your MP. Unlike the methods used by the open-source community, it's important to point out that all of those responses are isolated and do not see the huge benefits of enabling the community to discuss the issues with each other as well as the person or group asking the questions.

Funding and long-running teams

Teams that support popular open-source software tend to be very long-running, in sharp contrast to the often short-term contract outsourced teams often used by the government to develop bespoke software. As detailed in Public Digital’s ‘The Radical How’, having long-running multidisciplinary teams brings numerous advantages to delivery.

This can be related to the Agile principle of “Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.”

One might suppose that a key difference between open-source development and government work is that open-source teams are mostly made up of volunteers, who choose to spend their unpaid free time contributing to things that interest them. While that kind of developer is common, and often vital, it’s not universally the case. There are many occasions when companies, and sometimes even governments, will pay individuals to work on an open-source project because they know they will significantly benefit from its enhancement. This is an excellent example of how contributing to the commons can aid a wide variety of people and organisations.

Government often makes this kind of collaborative working much harder than it needs to be. It’s currently very difficult to build ongoing teams that are made up of individuals who work for different departments. This may be brought into sharp focus by the recent move to focus on mission-driven government.

One way to significantly reduce such friction would be to drastically decrease the number of civil servants who work directly for departments. If most government staff were in a general availability pool, it would mean they could quickly and easily be allocated into whichever pre-existing or new long-running team would benefit most from their talents. One example of this is the Canadian Free Agent model.

Developing in the open

As you can probably tell from everything I’ve written above, working in the open is vital to any open-source development. There are two fundamental parts to this.

Firstly, it’s often the case that contributors are not only physically separate, perhaps in completely different time zones, but it’s also common for them to be working for different private sector companies — often in direct competition! Again, they’ve realised that working together maximises their resources in areas that are good for the commons, leaving them to differentiate in other key areas.

As a quick aside, they often do this through the functions of standards bodies, which elect their own members from the public, private and civil society sectors, appointing those who are widely admired across the relevant communities. Two great examples of this that are related to the world of open source are the Internet Engineering Task Force and the World Wide Web Consortium.

Secondly, having all the development out in the open for anyone to see not only helps keep everyone focused on doing an excellent job, it also means that anyone anywhere can help fix issues — leading to Linus’s Law (named after Linus Torvalds, the Creator and Lead Developer of the Linux operating system): “Given enough eyeballs, all bugs are shallow.”

While the lead developers of the many open-source products will make the final decisions as to what software will be accepted, this is often influenced by discussions in the related communities that take place on the open internet.

One common method of demonstrating progression towards stated goals is via regular show and tells. These enable all manner of interested parties, from senior stakeholders to other teams that will use the product. Ideally, it will also include users, who can ask questions and provide immediate feedback. Again, the focus on mission-driven government might introduce a change here. For example, it’s been suggested that each Mission Board should have regular, perhaps monthly, public updates, in the same manner that the public became used to from the government during the pandemic.

In open-source development, there is often a blurring between contributors and users. Users who are keen for specific bugs to be addressed or for particular features to be implemented will often proactively get involved in discussions on mailing lists, forums or via online bug/feature tracking software — all of which are open for anyone to access. Government digital teams often employ user researchers, and policy groups will use consultations or, increasingly, various methods of deliberative research with the public and especially users of relevant services. However, this is almost always a set of one or more one-off events, unlike the long-running conversations that take place as part of open-source development.

Governments seldom take advantage of digital technology to have productive long-running conversations with citizens about policy development or service delivery. In the UK, good work in this area continues to be done by Policy Lab, whose new prospectus can be found here.

One notable exception to this general rule is in Taiwan, where the campaign group g0v has been extremely successful in bringing some standard open-source methods of communication into central government. The English-language version of their handbook can be found here. The public face of g0V, Audrey Tang, also has a new book on the topic.

To conclude

Much can be learned about open and collaborative 21st-century iterative development and delivery of government policy and services by examining the history of the open-source movement.

Personally, I would encourage the government to go further, by actively seeking out leading figures in both open source and other collaborative bottom-up communities, to discuss and learn how motivated communities, comprising a combination of providers and users, can come together to deliver world class services.

Some further reading

For those interested in more information on the topics outlined above, I suggest the following materials.

• Open-source software development history
  • The Cathedral and the Bazaar by Eric S. Redmond. A study of the difference between “bottom-up” development of open-source components that can be combined into bigger systems vs. traditional ‘monolithic’ development of large software applications by companies.
  • The Cluetrain Manifesto by Rick Levine, Christopher Locke, Doc Searls and David Weinberger. A book on how the internet enables radically different interactions between “consumers” and “service providers”.
  • The History of the Open-Source Movement and especially The History of the Linux Operating System. Both are articles on Wikipedia.
  • This history of the so-called “Bezos Memo” AKA ‘The Amazon API Mandate’.
• Rethinking government development of policy around new principles of prototyping, openness, etc
  • Radical Help by Hillary Cottom. Probably the most important book on the potential evolution of the interaction of citizens and the state in the last 10 years.
  • The Radical How by Andrew Greenway and Tom Loosemore (with many contributions by other members of Nesta and Public Digital and associates). A handbook on developing mission-driven government and a number of the points in this essay.
  • Liberated Public Services by Ben Glover at Demos. A paper on the evolution of public services.
  • Future Shock by Alvin Tofler. I want to give a shout out to this much under-appreciated book from 1970, in which many of these ideas, particularly around the area of government prototyping, are very clearly discussed.

I’d also like to highlight the upcoming Citizen White Paper, shortly to be released by Demos and partners via the Collaborative Democracy Network. This will be a primer on how the UK government can evolve its connection with citizens, from being almost entirely focused on the existing consultation model to a variety of much broader and deeper options for interaction.

Ongoing discussion

For further discussion, I hope to see people in the Systems Thinking in Government Apolitical community.

Done reading? Make sure to share your own thoughts about which open-source development concept you think the government should implement by leaving a comment below ⬇️

(Image Credit: Pexels)