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 in the comments below.
8 comments
Comment by Roy Hair posted on
An interesting idea that there is a difference between Open Source and Coded in the Open. I find there is always a real sense of collaboration and willingness across local government colleagues to share developments - even things are not code - openly.
Fewer and fewer orgs are able to code these days, it being seen as non-core business and something that is apparently cheaper to outsource, or buy off-the-shelf software in the short term. Longer term we end up with supplier lock-in and I think paying over the odds. I wonder if we're all missing a trick and collaborative developments that can be jointly supported is a model that has something to offer in terms of best-value.
I do have reservations if code in particular becomes open beyond the public sector where there is a danger of exploitation by IT service giants and the public sector then losing the intellectual property rights so that we end up paying for something that originated as a free, or low-cost option.
Would all code be able to be shared as open? Even that developed by companies on behalf of a pub sec org?
In general the initiative does sound like it would encourage greater sharing and best-value so it's a positive move.
Comment by Anna Shipman posted on
Thanks for your comments, Roy. I do think that collaborative development will result in better value because we are often solving the same problems over and over again.
Yes, most code written can be shared openly. For example if you look at our GitHub organisation (https://github.com/alphagov/) you will find almost all the code that runs the GOV.UK website, the Digital Marketplace and other GDS projects. That includes code written by suppliers on GDS’s behalf.
In order to remove the risk of losing the intellectual property rights, to pass a service assessment (https://www.gov.uk/service-manual/service-standard/make-all-new-source-code-open) you need to confirm that you own all the IP rights for the code you make open.
Comment by Adam posted on
Great that the government is adopting a more open source model for it's code, but lets not stop at your code. Embrace Open Source software and really kick off a revolution. I mean ditch Microsoft, Oracle and Apple... replace with Linux, Libre Office and Android.
The government have funded countless high profile and expensive IT failures whilst paying extortionate licensing fees. In recent years I get the impression (through lack of headlines!) that this trend may be reversing.
The move towards open source will make a significant impact to cutting costs; there will still be IT project failures but not extortionately expensive ones.
The creation of a Open Source Lead role is a welcome move. I hope you will be championing Open Source in all its guises. Good luck and keep us updated.
Comment by Anna Shipman posted on
Thanks for your comment, and it’s great to hear that you’ve noticed the work GDS has been doing in reducing these expensive IT failures. Open Source technologies like the ones you mention are already used extensively throughout government. The spend control team already ensures that Open Source is given a level-playing field when choosing technology, and last year the team helped government to save £339 million https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice.
We’ll definitely keep you posted!
Comment by Pete posted on
I think you hit the nail on the head with - "However, it can be a lot of work to make the code reusable and maintaining it is an extra overhead". Contracts are mostly awarded on a least cost basis - so commercial organisations must pay lip service to 'open source' in order to get the work. Now is government was prepared to invest by paying a premium....
Comment by Anna Shipman posted on
The code I'm talking about here has been written by in-house development teams. What you say is one of the reasons we say you should have teams with the capability to write and maintain the code, as Alex Holmes explained in this post: https://governmenttechnology.blog.gov.uk/2015/02/18/knocking-down-the-towers-of-siam/.
So they aren't paying lip service to Open Source, they are following our principles, and will have to pass the service assessment requiring them to have made the code open: https://www.gov.uk/service-manual/service-standard/make-all-new-source-code-open.
Comment by Tim Needham posted on
Great article and really positive to hear!
Here at West Midlands Fire Service we've had an in-house (award winning no less!) dev team for 20+ years and have been offering our in-house wares under GPL3/MIT since 2012... and couldn't recommend it enough.
Yup, it's all a bit daunting at first... and "Why are we giving away the crown jewels?" crops-up a bit... but in our experience it's worth persevering - SMEs engage more, good "social value" badges, improved job satisfaction, cloud services like Travis/Github/NPMJS etc. are free to use, other Fire Services have contributed... all good stuff.
Outrageous opportunism: If anyone fancies contributing to our latest proof-of-concept project, please feel free! 😉
https://wmfs.github.io/
Get coding everyone!
Comment by Anna Shipman posted on
Hi Tim,
This is really great to hear! Very impressive and it's really good to hear about the value it's had to your organisation.
Thanks a lot for sharing your experience!
Anna