Every digital service designed within government has to meet the Digital Service Standard. One of the requirements of the standard is that new source code should be made open and published under an open source licence.
There are a few situations where it’s acceptable to keep code closed but in most cases it will need to be open.
The easiest way to make code public is to write the code in the open from the beginning, and I’ve previously blogged about the benefits of doing this.
Your team may have old closed code that it needs to open. If there is a lot of closed code, this can be challenging. Here are 3 ways to open it up.
Option 1: Cycle all credentials then open it
The commit history is a very useful part of a codebase as it explains the reasoning behind changes. If your team wants to maintain the commit history a good approach is to make sure your code contains no secrets and then make it public.
GOV.UK’s infrastructure team did this when it opened the GOV.UK Puppet code. The team reviewed the code closely and made sure that any credentials mentioned in the code were no longer in use. They were then able to open up the code. You can read the infrastructure team’s blog post about it to learn more about what tools and techniques they used to make sure the code was safe to open.
The advantage of this approach is that you maintain the full commit history.
Option 2: Rewrite history
If your team feels that the commit history is not suitable for publication, there is an alternative. After reviewing the code to make sure it’s safe to open, you can either rewrite history to remove or improve some commits, or squash all previous commits into one.
The MOJ’s Prison Visit Booking team took this approach when it moved from coding privately to coding in the open. The team opened the existing code in a snapshot commit (this was the first commit) and then carried on coding in the open.
The advantage of this approach is that you don’t have to touch your infrastructure to do things like change a password or other details. However, the disadvantage is that you lose useful commit history, which can provide context for people working on that codebase.
Option 3: Move code to a new repo as you use it
Another way to open closed code is to create a new repository and move code. GOV.UK used this method when improving its deployment workflow. This helped the GOV.UK team to spread out the work over a longer time and share the workload out between a larger group of people.
The advantage of this approach is that you can do the work in smaller chunks. And, all the code is examined as you make it open. The disadvantage is that it can take a long time. You’ll also need to make sure your team finishes the job, otherwise you’ll end up maintaining two repos alongside each other.
After the code is open, work on the open code
You may be tempted to open code in a snapshot, continue to work in private, and regularly release code to the open version. This is a bad idea because:
- you need to continue to maintain 2 repos alongside each other, which is extra overhead for your team
- you may find it hard to keep up the commitment to open code
- you are not coding in the open so you’ll lose the main benefit of encouraging good practice, as well as other benefits
I hope these examples will help you find the method that will work best for your team, so you can enjoy all the benefits of coding in the open.
Stay up to date with all the latest posts by signing up to alerts from Government Technology blog, join the cross-government conversation on Slack or follow Anna on Twitter.
