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:
- MIT license for code
- Open Government Licence for text and documentation
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.
6 comments
Comment by Barrier Tocoding posted on
these are actual issues with open code:
1. Our code is our competitive advantage. Why don't all big software companies share their core code? Google is not opening it's search engine, Facebook is not sharing it's ads mechanisms? They only share utility frameworks, infrastructures, or projects that cater to developers.
2. Just throwing a bunch of files to public is easy. But keeping it up-to-date, thriving and easy to enter is an extra mile more than small dev-teams usually need to do internally. Most opensourceing-friendly codebases are self-contained, non-core-business (because 1.) components, but they usually don't get much of attention so even as open source are quite unexciting.
If your company is bigger than 20-30 devs then chances are you're spending enough time internally to teach new developers that going open source starts making sense as an investment.
Comment by Terence Eden posted on
Hi,
Thanks for sharing those thoughts.
In our situation, most government departments don't need a "competitive advantage". There's no one else out there who is writing the GOV.UK website, or APIs for Prisoner Visits, for example.
Other governments benefit when they can reuse our code - and we benefit when we can reuse theirs.
I agree that publishing is the easy part and maintenance is hard. That's why we stress that government departments should code in the open. See https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/
Thanks
Terence
Comment by Gilles Gravier posted on
Hi!
There are 2 approaches to open sourcing code. The idealist approach: "Everything should be open source."... It's an idealist view. Idealists are good as they help move in the right direction.
But in the real world, a more pragmatic approach is in order. The article here talks about open source in government, and gives directly, at point 9 a link to guidelines to help decide what code may be too sensitive to open source. But for businesses, indeed, the criteria may be different.
When I work with my customers on open source strategy, I always take a lot of care to help them identify which part of their code is a competitive advantage that needs to remain secret and which part is supporting code that can be open sourced. Sometimes they realize that their business model isn't based on monetizing the software itself, but rather hardware running it (think Linksys routers - you buy the box, but the software inside comes for free and for some models is even 100% open source and can be downloaded here: https://www.linksys.com/us/support-article?articleNum=114663), or services supporting it (think: Red Hat - you can get RHEL free here: https://developers.redhat.com/products/rhel/download/ but for production you really want a support subscription model).
So keep that in mind. Be pragmatic. Think about why you are open sourcing your code. It's OK to do that for very strong business reasons and reaping benefits. Once you identify which benefits you get from open sourcing your code... you'll naturally see which parts can/should be open sourced... and which ones probably shouldn't.
Comment by Jonathan Ingram posted on
Great stuff in here. Don't forget that Australia has also reused the UK Government's code.
Comment by Marcus Ferbrache posted on
And Jersey https://www.gov.je/Government/PublicSectorReform/eGovernment/Projects/Pages/e-petitions.aspx
Comment by Andrej Shadura posted on
And Slovakia: https://idsk-elements.herokuapp.com/