Anna Shipman : JFDI

Next steps for Open Source in government

15 December 2016 / Open source / Strategy

I was recently appointed Open Source Lead at the Government Digital Service (GDS) with the aim of making more government code open, improving the reusability of the open code we already have, and helping government as a whole be a better member of the Open Source community.

Making code open is vital to the transformation of government. Working openly also supports our work with other governments and last week, the UK government reaffirmed its commitment to making source code open by default at the Open Government Partnership summit in Paris.

By making our code open and reusable we increase collaboration across teams, helping make departments more joined up, and can work together to reduce duplication of effort and make commonly used code more robust.

A lot of great work has been done across government on this and it’s clear that developers across government are seeing the opportunity to better meet users’ needs through code reuse. We’ve seen that there is demand for more action and more support through our cross-government StackTech events and the code sharing unconference that took place earlier this year.

In this post, I am going to talk about my first priorities as Open Source Lead and let you know how you can get involved.

Open Sourcing government code

Over the past five years, a huge amount of government code has been released under Open Source licences. This has been great for transparency, collaboration and encouraging good practices. Making things open makes them better.

However, most of this code is what we call coded in the open rather than Open Source Software. The teams don’t guarantee that they will support it 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.

When code would be useful for other teams there are clear advantages to supporting reuse. For the other teams, and for government in general, the advantage is the chance to save time and money. In these cases, it might be worth taking the extra steps to make this code Open Source Software.

There are advantages to the originating team as well. Your code will be used and tested in a variety of environments and there is a greater chance of people finding issues and in many cases helping you to fix them. People who use the code often contribute bug fixes back to the original and these may help set direction and contribute features as well.

However, it can be a lot of work to make the code reusable and maintaining it is an extra overhead, so it’s important to focus the effort on the projects which are meeting the greatest user needs.

Teams across government are already doing great work producing reusable code. For example the GOV.UK frontend alpha, GCHQ’s Gaffer and Home Office Forms, to name just a few. Initially, I will be doing user research to understand what code that has already been written by government would be useful more widely, and I will then identify a few projects to focus on making into Open Source Software. There will be opportunities to get involved in this user research which I will talk about more next year.

Not all code needs to be Open Source Software but all code needs to be open

Even where the project does not meet user needs for reuse beyond its originating team, it’s worth making it well documented, with good commit messages, and blogging and talking about it, so that other teams can reuse your learnings if not the code itself. A great example of this recently is the digital apprenticeship service using GOV.UK’s smart answers code.

There are many benefits to making your source code open even if not fully Open Sourced, including encouraging good practices and making it easy for teams to collaborate. All new code written in government has to be open by default.

However, it’s not always easy for teams who aren’t used to it to make this happen. Firstly, it’s clear that our guidance is not as joined up as it could be so I’m going to be working on clarifying that and filling any gaps, and then I’ll look at how to address any other barriers we find through user research.

It’s all about community

The most important thing when sharing code and making code open is to talk to others working on same things, share ideas and learn about code you can reuse or collaborate on.

We held a cross-government meet-up on code sharing earlier this year and some great ideas came out of that. I will be building on this by organising meetups every few months as part of building a community around this work.

The next cross-government open source meetup will be in February, and GDS is co-hosting with the Ministry of Justice (MOJ). There will be a series of short talks from departments on what they are doing around open source, followed by some open space/unconference sessions. If you work in government and would like to attend (or speak about what you’re doing about Open Source in your department), sign up to the cross-government technical architects mailing list where I will post details next month. I will also blog more about it closer the time.

Making higher impact contributions to Open Source Software

We depend a lot on Open Source Software. For example, you can see from the GOV.UK Colophon a small fraction of the Open Source Software we use at GDS. Many teams contribute back patches to help improve these projects, but next year I’m going to be looking into how we can make higher impact contributions. This will help make sure that the Open Source Software that the government depends on is more stable in the long term; and also, giving back to these projects that we use for free is the right thing to do.

It’s worth mentioning that the primary focus of my job is not about driving adoption of Open Source Software. Open Source Software is already used widely across government. The Technology Code of Practice is very clear that you must give it equal consideration when choosing technology, and the spend controls team are doing an excellent job making sure Open Source Software is given a level playing field.

How you can get involved

If you are in government and would like to attend the meetup in February, please sign up to the cross-government architects email (google) group where we will post more details next month. There is also a cross-government slack with channels for a range of topics, including #open-code.

If you are interested in helping us with our user research on any of this please get in touch. I will also be talking next year about the specific work we are doing and how you can take part.

There is lots to do and these are just the first few things I’m focusing on. I’d be very happy to hear your thoughts.

This post originally appeared on the Government Technology Blog.

If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list:

Email Format