https://mojdigital.blog.gov.uk/2017/02/21/why-we-code-in-the-open/

Why we code in the open

At the Ministry of Justice, we code in the open, by default. This means whenever we write software, we make our source code available to anyone and everyone.

We are strong advocates of point 8 of the Digital by Default Service Standard:

Make all new source code open and reusable, and publish it under appropriate licences (or provide a convincing explanation as to why this can't be done for specific subsets of the source code).

So our teams have to make a case for not making their code freely available. This approach has resulted in us writing tens of millions of lines of code, in hundreds of code repositories, in the open since 2012.

This is not only the code for our front end systems, but includes the code for our:

  • back-end systems
  • data handling systems
  • services for staff and
  • sometimes our security-enforcing systems.

Encouraging good discipline

We expect a high level of quality from all of our software developers, but we have found the quality of code and commit messages is higher when developers are working ‘in the open’.

We think this is caused by a developer’s contribution being seen by other developers both inside and outside the MoJ. This is a commonly identified psychological effect about the improvement of human behaviour when we believe we are being observed.

Increased sharing and collaboration

Coding in the open means people outside our team can use it, and even help to improve it.

When we built Send Money to a Prisoner it was coded in the open and allowed people outside of government to add support for different versions of Python (the programming language we built the tools in) and improve the tools’ integrity checks.

This made the tool better for us, and more usable for people outside our teams.

Screenshot of The NOMS Ops UI for the Money to Prisoners Project

It helps us hire great people

Our public code repository is an important part of our recruitment strategy.

Many people who have joined our team have told us that what they saw in our code repositories was part of attracting them to the role. They can easily see the quality and style of code we produce, the types of technologies we work with, and the kinds of services we deliver.

It's more important to secure data than code

Building technology and making it secure costs money. Whether it’s simply the time people spend discussing it, or in the security features or components used.

Keeping code confidential can be complex, leading to additional cost and leaving less money available to use securing the data the service handles.

Open code builds trust in government

Transparency and freedom of information are important priorities at the Ministry of Justice. So being more open about our code, and the processes which lead to coding decisions, are vital parts of building trust in government.

Keeping things confidential

Sometimes software will need to be confidential because it’s commercially sensitive or waiting for organisation approval. In most cases it will only need to be confidential temporarily, so we try to make the code open as soon as possible.

A good example of this process is explained by GDS when opening up the Register to Vote codebase.

Doesn’t it give attackers an advantage?

Although there’s a common concern that coding in the open could give an advantage to an attacker, we believe that only a negligible advantage exists.

In fact there is no evidence to suggest that being open source makes software more susceptible to exploitation.

For example, publishing code in the open, especially when using good security discipline, is no riskier than closed source software where the binaries (the executable version of the source code) are public.

Lots of closed source software such as components, libraries and operating systems can be disassembled to reveal a similar level of detail to source code.

If you look at all the bugs in closed source products, the people that find the bugs don't have the source, they have [disassembly tools], it's out there and it's going to work on open and closed source binaries — get over it.
—Dr. Ian Levy, Technical Director, NCSC, in an interview with ZDNet in 2013

So how secure is coding in the open?

In the past, there’s been a misconception that openly sharing code presents security risks. However, we believe that can be avoided by following best practice, and keeping code separate from configuration and data.

Make things open: it makes them better

As the tenth GDS design principle says, the more eyes there are on something, the better it gets.

Making our code open makes it more usable, more secure and more accountable.

Would you like to work on things that matter? Find out more about working at MoJ Digital & Technology.

Subscribe to the blog for updates on our work or follow us on Twitter.

Leave a comment