WIREDGOV

Blog posted by: Anna Shipman, 4 September 2017 – Categories: GDS design principles.

For any service to be put in front of the public, it has to meet the Digital Service Standard, a set of 18 criteria.

One of the criteria is that all new source code is made open and published under an open source licence.

This goes hand in hand with our tenth design principle: make things open: it makes things better.

In this blog post, I explain why coding in the open makes things better.

It encourages good practice

When you know someone is watching, you tend to take greater care. You're more inclined to document your work clearly. You make sure your code is secure by keeping secrets separate from the code. You are polite and constructive in code reviews, and you follow good architectural principles.

In short: when other people can see your work, you tend to raise your game.

It makes collaboration easier

If code is open, it is easier to work on it with others. You don't need to give them special access or make complicated business arrangements. You don't even need to be in the same building.

For example, someone from 18F, the government agency that provides digital services to the government of the United States, was able to help a colleague from GDS with a code-writing problem.

It worked because both sides coded in the open. We also worked with the Australian Government to help them establish their own Digital Marketplace.

Closer to home, it makes it easier to work on the same code between departments.

External users can help make it better

Open code makes it possible for people who don’t work for you to make improvements to your code.

For example, members of the public made improvements to the Government Petitions Service. Someone added the scheduled date for debates. Someone else made a change to the signature counter to make it update in real time.

People can ‘scratch their own itches’. They can make the small improvements that aren't at the top of your list of priorities, and they can help make your code more robust.

Others can learn from your work

If your code is open, people can apply what you've learned from doing the work.

Skills Funding Agency used GOV.UK's Smart Answers code to build a tool for their apprenticeships service. It took less than a week.

Without the Smart Answers example to learn from, it would have taken at least two months.

It makes it easier to share standards

Open code makes it easy to follow other teams’ work. This promotes a common culture and way of working when you can see how other teams manage certain issues.

Anna Shipman (left)

Quite often, teams will make small improvements to other teams’ work. For example, a developer from GOV.UK made a correction to GOV.UK Verify.

GOV.UK publishes coding style guides. This makes it easy for everyone to find and stick to the same standards.

It improves transparency on government’s work

When code is developed in the open, you can see where public money goes.

It is a catalyst which encourages openness in other things. For example, the GOV.UK roadmap is open, and one of the teams on GOV.UK uses a public Trello board.

When there is an occasional outage on GOV.UK we investigate and publish a report. It’s important to show how we learn from mistakes.

It clarifies ownership

We want government to own and be able to make changes to its services, and lack of clarity on intellectual property (IP) can be a barrier to that.

Open coding from the beginning surfaces copyright and IP issues before work starts.

The Service Standard demands that code is published under an open source licence (at GDS we use MIT). Additionally, all the work we do as civil servants is Crown copyright.

In the past, government services have wanted to change a project but have been unclear about who owns the IP.

Clarifying the issue upfront is valuable. It means that departments can bring in a supplier to work on their alpha and then switch to another supplier for beta without losing their work.

They can even build up teams from many suppliers who can work on the code seamlessly.

It prevents supplier lock-in. Without clarification, the software created for you can be the thing that will prevent you from switching suppliers.

So resolving this can save a lot of money for government.

It helps make government technology seamless

People who move between departments can continue to work using the same tools as before. It saves time and money. They can share knowledge of projects they were working on, because it’s all open.

After someone moved from GDS to another department, they contributed to our single sign-on service.

Over time, it will make government technology seamless as people move towards the most useful tools.

It’s easier to code in the open than to open a closed repository

Coding in the open means you decide whether that code is suitable for publication as part of reviewing each small piece of work.

To open it later means having to go back through a body of work that has built up over time to make sure there is nothing that shouldn’t be made public, which can be significant extra work.

Make your own code open

Many people think that being able to reuse code is the biggest benefit of coding in the open. However, while reuse is a nice-to-have, I hope this blog post illustrates that there’s more to it than that.

Take a look at our open code and our guidance.

Join the conversation in person, in our #open-code channel on Slack or in the comments below. You can also follow Anna on Twitter.

Developing the DfT Digital Data Index