Beta This is new guidance. Complete our quick 5-question survey to help us improve it.

  1. Service manual
  2. Technology
  3. Making source code open and reusable

When you create new source code, you must make it open so that other developers (including those outside government) can:

  • benefit from your work and build on it
  • learn from your experiences
  • find uses for your code which you hadn’t found

Meeting the Digital Service Standard

To meet point 8 (understand security and privacy issues) you must:

  • make all new source code open and reusable
  • publish code under an appropriate licence
  • explain your reasoning for any code you haven’t made open

You’ll have to explain how you did this at your service assessments.

Consider the types of code you shouldn’t make open

You must be careful when publishing code that includes:

  • information about how your software is configured
  • the implementation details for code that makes your software secure
  • anything that can’t be published yet due to unannounced policy

Find out more about when it may not be okay to make code open.

If you’re not sure which parts of your code can be published in the open, talk to a third party that you trust. For example, a technical architect in your department or another government department.

You can find a technical architect by joining the technical architecture community.

Make your code open from the start

Ideally, you should code in the open from the start of your project.

Coding in the open from the start means you can:

  • plan how you’ll avoid publishing sensitive information later in the project
  • follow best practices from the beginning, for example keeping good documentation
  • identify parts of your code for reuse which you might not have recognised yourself

How to code in the open

You should make your code publicly available in an open internet source code repository. For example, the code for GOV.UK is on GitHub.

When publishing your code you need to make sure:

  • you’re clear about who owns the code and how others can use it
  • you don’t release sensitive information
  • any third-party tools you use to host or manage your code meet the Cloud Security Principles

Licensing your code

You should publish your code under an Open Source Initiative compatible licence.

All code produced by civil servants is automatically covered by Crown Copyright.

Taking responsibility for open source code

When you make your code open, you should:

  • use Semantic Versioning to make it clear when you release an update to your code
  • be clear about how you’ll communicate with users of your code, for example on support channels and email lists
  • set time aside to maintain your code
  • encourage contributions from people who use your code, for example by maintaining a public issues list

You might also find it useful to read:

Tracking changes to your code

When your code is open, you should keep track of changes to it using version control.

Services like GitHub make version control much easier. They allow you to track issues and read documentation alongside your code so you understand what has changed and why.

Dealing with security issues in published code

If you find a security issue in your code after you’ve published it, you need to be able to deploy fixes quickly without disclosing too much information about the vulnerability until you’ve dealt with it.

Fixing security issues in public copies of the code doesn’t work for every team.

For example, the development team behind the Register to vote service used scripts to switch between private and public copies of the code to manage fixes securely.

You may find the Maintaining version control in coding guide useful.

Published by:
Technology community (technical architecture)
Last update:

Guidance first published