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.
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.
Watch our video about why we code in the open at GDS:
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.
3 comments
Comment by Simon Dickson posted on
I totally agree with all the benefits, immediate and potential, which you've listed. But my concern with the focus on Coding In The Open is that it only goes part-way towards realising the full benefits of truly collaborative engagement in Open Source practices.
As you've acknowledged yourself in the past, GDS teams 'don’t guarantee that they will support (their code) or maintain it in the way Open Source Software needs to be, and a lot of it is not set up to be easily reused'. As a result, the pool of potential collaborators is limited to highly skilled and highly motivated volunteers; or the relatively small number of organisations with identical usage scenarios.
Coding In The Open is a great start, infinitely preferable to not doing so. But as I know from working with a hugely successful Open Source project (and community) like WordPress, the real benefits come when large numbers of people are actively using open codebases for their own, sometimes selfish, purposes. As Eric S Raymond famously put it in The Cathedral And The Bazaar: 'Given enough eyeballs, all bugs are shallow.'
It's good to hear that Coding In The Open facilitates cooperation within UK government, and collaboration with other governments. But GDS should look wider: not only would more easily reusable code increase the pool of possible collaborators, thus reducing the depth of the bugs, it would also allow GDS to spread its expertise far beyond government circles, including to the UK individuals and businesses who provide its budget.
Equally, I would like to hear more examples of GDS practising what it preaches, and engaging actively in other people's open coding, providing fixes and proposing improvements. Where others have packaged and licensed their open code for easy reuse, GDS stands to benefit in terms of lead time and development cost; and can contribute its expertise for the benefit of all users of that code.
As you've proven here, there's a strong business case for the additional overhead of Coding In The Open. I don't think coding for reuse is a nice-to-have: it's the logical destination for this approach.
Comment by Rod Plummer posted on
I can understand this if a Government department wants a 3rd party to build it something that it has a requirement for, or something that it has invented. However, what if a company invents something completely new, that it holds all the IP for, that a Government Agency then wanted to use? Does the 3rd party then still have to published the source code under an open source licence?
If so, then I can’t see many SME’s wanting to do that, in fact I can’t see any as it would be commercial suicide, as it will simply enable their competitors to use their source code to compete with them and that would be utter madness.
Comment by Stuart Roebuck posted on
The guidelines linked at the bottom of the article talk specifically about making new code open. I don't think anyone is suggesting that every dependency must also be open but at least by making the 'calling' code open you are clearly showing/documenting the dependencies.
That said, I would hope that very careful consideration would be made to the implications of depending upon proprietary code if that could potentially lock the government into depending on a particular supplier or spiralling licensing costs.