I have been the Open Source Lead at GDS for a year now. Here are some of the things I’ve achieved and learned.
Open source in government covers a huge range of activities, including open sourcing our own code, using open source software and contributing to open source software. My first task was to define the strategy, work out what areas would have the most impact and then prioritise within those areas. I wrote about the strategy, and the areas I prioritised, on the GDS blog.
I had to be very focused to stick to these priorities, as lots of people had many interesting ideas for other things I could do. Most of these ideas were excellent suggestions that were just not as high a priority, though I was able to do some of this work as well without getting diverted.
The UK government has committed to making all new source code open.
Many teams are doing this really well (you can see a lot of government code on the GitHub government page). However, some teams find it harder to meet this commitment, so one of my main priorities was helping those teams to overcome the barriers.
The first step to coding in the open is very small; you don’t need to jump in by opening all the code that exists in your organisation. The first thing can be just creating a repository on GitHub with a licence and a README. The step itself is easy; what is difficult is making the decision to take that step. There are many barries, including organisational barriers and emotional barriers.
This year I’ve approached that from three main angles.
Firstly, I’ve shown the value of coding in the open; why it’s worth taking that step. I’ve had many one-to-one chats and given presentations to organisations, and to reach a wider audience I’ve given two conference talks, at GOTO Berlin and Turing Fest.
Most importantly, I’ve blogged about the benefits on the GDS blog, which I’ve had feedback has been of huge help to open-source advocates across both government and industry.
Secondly, I’ve addressed the reservations teams have around the practicalities of taking that step. The first question most people have is whether coding in the open is secure. It is. To make that clear, and to share the safeguards you need, I’ve published guidance about when code should be open or closed and security considerations when coding in the open. This not only helps people with the details, it also demonstrates our commitment to the policy.
Thirdly, I’ve addressed some of the other practical details. For example, here is some guidance I wrote about how we license code at GDS.
As well as helping teams code in the open, I’ve also supported teams opening existing code that had been closed. As well as lots of smaller services, I’m really proud to have supported the opening of three high-profile GDS projects this year. GOV.UK Verify, GOV.UK Pay and the Register to Vote frontend.
The Open Source Lead role is about strategic influence, and the versatility required to persuade and support such varied teams, working with everyone from developers to very senior executives, has been one of the most interesting parts of the role.
My work here has ranged from writing papers for completely non-technical audiences explaining why (and how) the code should be opened, through hands-on help with the code, to influencing senior stakeholders to push for quicker progress from their angle.
One of the main ways to find out about useful code you can learn from and reuse is by hearing people talk about it. It’s also really useful to have people you can discuss shared problems with, so one of the most important things to do was to build the kind of environment where these conversations can happen.
To facilitate this I organised a series of cross-government open source meetups. They were very well attended, each with around 100 participants from 20+ government organisations, and they received 80% Net Promoter Scores. Khidr Suleman did a good write-up of the second meetup.
More important than the events themselves was the community I built around this work. We have a cross-government Slack organisation and there is an #open-code channel. When I started this role a year ago, this channel was very quiet, and I was involved in most of the conversations. Now I often log into Slack and see that several questions have been asked and answered by other people, and discussions have taken place that haven’t needed my input. This is really heartening to see, as it means the community is supporting each other without my active involvement being required on a daily basis.
One thing I had to do a lot more of this year was write business cases, and I wrote some guidelines on how to do it. I was really pleased when the head of GDS’s delivery management community sent the post round to his team, to show why writing business cases need not be laborious or confusing.
The most interesting piece of work that I wrote a business case for was a discovery into how we could promote reuse of open government code. One addendum is that I followed my own guidelines to write the business case, but although it was well-received (the report I got was that it was “super”) that wasn’t enough to get it approved; I had to keep pushing, and eventually rewrote it as a one-pager, which got a very quick result. In future I’ll try and keep such pitches to one page.
Another interesting aspect of roles at this level is that things can take a very long time to come to fruition. I had to demonstrate single-mindedness to see some of them through.
For example, the security guidance I published had a longer than expected road to publication, firstly because of the unexpected general election and then because of a new process around guidance, and it involved liaising with a wide range of stakeholders including NCSC and other government departments. I started work on it in January and wasn’t able to publish it until September; but it was worth waiting for: the blog post I wrote announcing it made it to #2 on Hacker News and had 11,000 views in the first 24 hours. More importantly, lots of people have given me feedback that it really helped them with opening their code.
Alongside these larger themes I did some smaller things I’m pleased with.
I worked with several departments to review and assist with their open source policies. One of the things I’m really proud of is that, based on my feedback, HMCTS changed their open source policy from “closed by default” to “open by default” and their technical architect later gave an interesting talk about how that cultural change had happened at our meetup.
I arranged a workshop on contributing to humanitarian open source software; two core committers from OpenMRS gave us an introduction to the project and the code, and then we worked on some tickets. We all managed to contribute some code to production during the workshop, which was great.
I’ve supported and encouraged several others to write blog posts about their open source work. Many have been published on the GDS technology blog as well as an excellent one from the Ministry of Justice.
I’ve also talked to a lot of my counterparts in other governments, and I even found myself writing some lines to send back to an MP responding to a constituent’s inquiry about open source.
I also did a lot of other work moving things along, but can’t yet report the results. That’s one of the interesting things about this level of work, the achievements are larger but the intervening steps tend to be things that are not interesting to talk about (“I had a chat with this person and now have an idea of what to say to that person to convince them that this other course of action might be a good bet…”).
My aim in any job I do is to ultimately replace myself with a small shell script. For example, a major success this year was when my colleague Jenny Duckett was able to help a team through the whole process of opening their code, using guidance I’d written and with almost no input from me.
As Open Source Lead I’ve received a lot of very similar questions on a lot of very similar topics, and much of the work I’ve done this year has been to stop people having to ask those questions by publishing the answers and then publicising them. So my aim in this role is perhaps not to replace myself with a shell script, but rather series of blog posts, guidance, videos, and a shared culture and community. And from the evidence so far, I’ve made significant inroads to that!
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: