This year’s cross-government open source meetup in October covered many interesting topics, from documenting code best practices to changing an organisation’s culture.
Terence Eden, open standards lead at GDS, also gave a talk about overcoming barriers to coding in the open, which generated lots of debate.
Here’s a recap of some of the open sourcing issues he’s come across when visiting government organisations and ways to easily address these problems.
1. ‘We’ll get hacked by open sourcing’
Senior leaders are usually worried about hacking and this is the most common reason given across government for not working in the open.
There are a few ways to overcome this potential barrier. Firstly, a quick Google search shows many major worldwide security breaches take place because hackers exploit security flaws in closed source software.
Secondly, we have government guidance that makes clear why it’s ok to code in the open and gives advice on:
Finally, UK intelligence agencies such as Government Communications Headquarters and the National Cyber Security Centre work in the open as much as they can, demonstrating it's possible for even high level security organisations to work in this way.
2. ‘Rogue developers will damage our reputation’
Developers are unlikely to post rude or inappropriate messages in GitHub repositories because they want to build a credible public portfolio.
If your organisation cannot trust your employees to follow the Civil Service Code then there are bigger recruitment issues you need to tackle.
3. ‘What if we accidentally commit a secret key?’
Organisations should work with the assumption that a data breach will take place at some point. The best way to prepare for a breach is to set up and test a disaster-recovery policy.
As a backup, GitHub offers several solutions to help prevent you from committing private information. There are also monitoring solutions to alert you if something accidentally gets released that should not.
4. ‘Our code isn’t good enough to open source’
Mature government projects that run tens of millions of user transactions are usually built using robust code. If this code meets government standards it’s definitely good enough to open source.
You should not worry about perfecting early versions of your code. However, if your organisation is genuinely embarrassed by the code in a mature project, then there’s probably a need to reassess the quality of the work.
It’s also important to remember that the public has a right to see the code that’s impacting their lives.
5. ‘We’re confused by licences. What if we do not use the right one?’
The Open Source Initiative has good guidance on licences to reduce confusion.
At GDS we use the:
While it’s easy to get confused, at worst, you’ll get a message from a member of the public letting you know that you’re using the licence incorrectly.
6. ‘What if people find bugs?’
All companies have bugs in their code and government organisations are no different. Your organisation should not keep code closed because it’s worried about people finding bugs.
There is a perception that opening code may lead to hackers exploiting bugs. However, coding in the open usually means teams take extra care because they know other people will see their work.
The open source community is also great at helping to identify bugs so you can fix them and improve your service faster.
7. ‘Our developers cannot access GitHub through the firewall’
Blocking developers from accessing GitHub does not make sense because government has a cloud-first policy and software-as-a-service tools are widely used across government.
GitHub is an important tool to help organisations work in the open and developers must be given access.
8. ‘We’ll open the project when we finish’
You may have the best intentions but in all likelihood your organisation will not open source code once it’s complete.
You must make all new source code open to meet point 8 of the Digital Service Standard. This takes away the worry of having to open source at a later date.
For organisations that are interesting in open up existing projects, we also have tips on how to open up closed code.
9. ‘We’re working on things that are too politically sensitive’
There are rare exceptions to working in the open. If you’re still unsure you can get advice from your organisation’s communication, policy and ethics team to double check whether your project is too sensitive to open source.
Most information we work with is subject to a Freedom of Information request. Your organisation will save time and resource when it comes to answering any FOI queries by proactively publishing information in the open to begin with.
10. ‘We don’t know where the code has come from and no-one will be interested’
When code is created in a closed environment it is not always easy to trace the source. Coding in the open helps your organisation track code from its origin so you know whether it’s been created in-house, by a contractor or a supplier.
You should not assume that people will not be interested in your code. Your code will probably be useful to someone in another department, country or for a brand new project.
Even if no-one looks at your code you’re still getting all the benefits open sourcing brings. It’s often hard to keep track of all the work being done across government.
11. ‘What if other countries steal our code?’
Open sourcing helps to export best practice, people, standards and our code. Governments can start conversations, create links and learn from each other to improve ideas.
The EU, US, Canada and New Zealand have already reused the UK government’s code to improve their services, helping them progress their digital transformation faster, more efficiently and cheaply.
Tell us about open sourcing problems you’ve overcome
Has your organisation come across any other barriers to working in the open? Let us know how you’ve overcome these problems by leaving a comment below.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.