Open Sourcing the Public Sector in Scotland

If there was one decision that could have the greatest positive impact on the use of ICT In the Public Sector in Scotland, it would be the wholehearted open sourcing of public sector ICT. I don’t simply mean the use of open source software: I mean taking software produced for the public sector and making it unambiguously publically owned and publically accessible by default.

Unfortunately, there is such a wide range of opinions on this topic that it seems almost impossible to write a concise text that addresses the concerns and misunderstandings that still hold back progress in this area. I am therefore inclined to quote from text produced for the Consumer Financial Protection Bureau[1] of the US Government which (in April 2012) announced its intention to do exactly what the Scottish Government should do. Here is a portion of an article explaining the two halves of this policy: using open source and open sourcing their own software:

Source code that can be freely modified and redistributed is known as “open-source software,” and it has been instrumental to the CFPB’s innovation efforts for a few reasons:

• It is usually very easy to acquire, as there are no ongoing licensing fees. Just pay once, and the product is yours.
• It keeps our data open. If we decide one day to move our web site to another platform, we don’t have to worry about whether the current platform is going to keep us from exporting all of our data. (Only some proprietary software keeps its data open, but all open source software does so.)
• It lets us use tailor-made tools without having to build those tools from scratch. This lets us do things that nobody else has ever done, and do them quickly. Until recently, the federal government was hesitant to adopt open-source software due to a perceived ambiguity around its legal status as a commercial good. In 2009, however, the Department of Defense[2] made it clear that open-source software products are on equal footing with their proprietary counterparts.

We agree, and the first section of our source code policy is unequivocal: We use open-source software, and we do so because it helps us fulfill our mission.

Open-source software works because it enables people from around the world to share their contributions with each other. The CFPB has benefited tremendously from other people’s efforts, so it’s only right that we give back to the community by sharing our work with others.

This brings us to the second part of our policy: When we build our own software or contract with a third party to build it for us, we will share the code with the public at no charge. Exceptions will be made when source code exposes sensitive details that would put the Bureau at risk for security breaches; but we believe that, in general, hiding source code does not make the software safer.

We’re sharing our code for a few reasons:

• First, it is the right thing to do: the Bureau will use public dollars to create the source code, so the public should have access to that creation.
• Second, it gives the public a window into how a government agency conducts its business. Our job is to protect consumers and to regulate financial institutions, and every citizen deserves to know exactly how we perform those missions.
• Third, code sharing makes our products better. By letting the development community propose modifications , our software will become more stable, more secure, and more powerful with less time and expense from our team. Sharing our code positions us to maintain a technological pace that would otherwise be impossible for a government agency.

The CFPB is serious about building great technology. This policy will not necessarily make that an easy job, but it will make the goal achievable.

If you are left thinking that the United States is very different from the UK then you can also look at the UK Government in Westminster which has set up the Government Digital Service[3] which is now open sourcing the software it uses and produces, and even blogs about the many open source technologies that they rely on to make it all work[4].

 FAQ

So, here’s a pseudo FAQ (Frequently Asked Questions) covering some of the concerns and issues I’ve heard relating to the idea of the public sector adopting open source and open sourcing the software it produces.

How can open sourcing software save the government money?

Open sourcing government software makes it easy for other public sector bodies to identify and re-use software themselves, thus removing duplication: reducing development costs and development time. Well known open source software also benefits from free contributions from third parties who are able to find and fix bugs or contribute enhancements at no cost.

With traditional government approaches to tendering, the private company supplying the software is often the only organisation that understands the software and is able to support it in the future, this means that the government is ‘locked-in’ to using that supplier or starting all over again with a new supplier. The cost of starting again or the lack of competition act to increase the cost to government.

Finally, the large size of public sector contracts eliminates most nationally based suppliers from tendering for the work. Whilst these multinationals may well go on to employ staff from within Scotland, the profits are probably taxed elsewhere. Open sourcing the software creates an open system which can and should be modularised into smaller components that could be delivered by local suppliers. This would rely on some centrally based development team much like the model of the UK Government Digital Service[3].

The Government can’t open source public software—think about the security risks!

There is a misconception that open sourcing software makes it more vulnerable to security risks: the reality is quite different. The underlying security mechanism currently relied on by Banks and Governments connecting with the public over the internet is something called SSL/TLS[5]. This standard is open and it exists in many software libraries including OpenSSL—an open source version. The open nature of this standard has been critical to the identification and consequent elimination of security vulnerabilities in earlier versions of the standard. The Linux operating system, the Apache and Tomcat web servers and numerous other open-source technologies are relied upon across the world to drive countless high security web services.

Open Source is a nice idea but surely it’s no good for big government projects?

Open source is not some new idealistic approach to building software for academics. When governments contract large multinational companies to develop critical software they are typically paying for them to produce software which under the hood is made up of lots of open source components. Conceptually the government agency is not placing its trust in the open source software but in the company that uses it to produce the solution they require: in reality they are just paying a lot of money for something they could get for free.

How would open sourcing government software align with the McClelland report on ICT in the Public Sector?

The McClelland report makes it clear that there is a need for greater transparency in the use of ICT and its costs and that there is a need to increase reuse of software. Open sourcing government software is the ultimate form of transparency and opens up opportunities for re-use not just of complete software systems, but also of components that make them up. For example, within the GDS[3] open sources software for the DirectGov web site, there is a software library that will take a postcode, determine it’s location and generate a map showing the location. By open sourcing this software, any government department can reuse it for any purpose it sees fit.

How would open sourcing government software align with the Christie Commission on the future delivery of public services?

The Christie Commission report emphasises the importance of saving money by preventative actions and tailoring services to meet local needs. Open sourcing government software prevents huge and unnecessary costs around the commissioning and future decommissioning of large contracted software systems and the complex tendering processes around these. Open sourcing software enables iterative change and development that allows systems to adapt to needs rather than being locked into agreements sometimes lasting as long as eight years at a time. Because open sourcing software allows sharing and adaptation, it allows software to be both shared and adapted to local needs.

---

1. Consumer Financial Protection Bureau: http://www.consumerfinance.gov/. The quoted article can be found here: http://www.consumerfinance.gov/blog/the-cfpbs-source-code-policy-open-and-shared/. They have also published their source code policy to help other organisations to do the same thing: https://gist.github.com/2343578. Finally, you can look at their open source software as it develops on their Github account here: https://github.com/cfpb.  ↩

2. US Department of Defense policies around open source software: http://dodcio.defense.gov/Home/Topics/UseofFreeOpenSourceSoftwareFOSS.aspx  ↩

3. The Government Digital Service: http://digital.cabinetoffice.gov.uk/. A document describing their software design principles: https://www.gov.uk/designprinciples. Their own software freely available on Github: https://github.com/alphagov.  ↩

4. UK Government Digital Service blog entry describing the current technologies they are using: http://digital.cabinetoffice.gov.uk/colophon-beta/.  ↩

5. Secure Sockets Layer: for a good overview and history see the Wikipedia article here: http://en.wikipedia.org/wiki/Secure_Sockets_Layer.  ↩