https://governmenttechnology.blog.gov.uk/2016/12/15/next-steps-for-open-source-in-government/

Next steps for Open Source in government

Cabinet Office

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.

6 comments

  1. Roy Hair

    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.

    Link to this comment Reply
    • Anna Shipman

      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.

      Link to this comment Reply
  2. Adam

    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.

    Link to this comment Reply
  3. Pete

    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....

    Link to this comment Reply

Leave a comment