What We Mean When We Tell Government to 'Do Open Source'

I’m guilty of telling people, especially in government, to “do open source.” I know, I know, I’m sorry. It’s good advice, obviously, but it’s also vague and broad. It means something different to everyone.

Plenty has been written on the boons of open source in government, and I’m sure we’ll be writing plenty more. But first, it’s time to unpack the verb “do” and clarify what this encompasses. When we talk about “doing open source,” we generally mean one or more of these three verbs: USE, MAKE, and CONTRIBUTE.

USE open source software

Anyone can use open source software. Most people already do. Use the internet? You’re almost certainly using open source software – your browser itself might be open source (Firefox) or built on open source (Chrome, built on Chromium), or you’re looking at a web page that uses open standards such as HTML or CSS. I know open standards aren’t technically open source software, in the sense there isn’t source code to be open, but I typically lump them together in the same boat because they are open for anyone to use and they are built with similar practices and processes as open source software (e.g. you can contribute to HTML on Github).

In addition to relying on open standards to be useable, chances are, any webpage you’re on was built with open source software as well. So many languages used to build web applications are open source: Wordpress (which is used by 64.5% of websites using a content management system), JavaScript libraries such as jQuery or Node.js, Ruby or RubyOnRails, Rust – to name a few you may have heard of.

When we talk about using open source in government, sometimes we mean using an end application with a user interface (e.g. an open source map tool) but usually we mean using code libraries or languages that are open source by incorporating them into another software project. You can make a website that is not open source but uses many open source libraries, because they are utilities or tools rather than the end product. Almost everyone does this, unless they’ve been locked in to a vendor situation and can’t get out. It isn’t controversial anymore, since open source software (and open standards and programming languages) now pretty much powers the digital world. Open source software is a utility, and it’s ubiquitous.

MAKE open source software

Technically, to make open source software, you don’t have to do anything but slap one of these licenses on your code that allow your software to be freely used, modified, and shared. Does anyone else need to be able to find or see your code? Nope. Example? I can think of tons from government (I won’t name names), where I’ve been told something is “open source” and when I ask to see the code, either no one can find it or someone emails me three weeks later with a zip file full of millions of lines of Java. If you can’t tell, I am not a fan of this meaning.

To make open source software in a functional sense and not just a technical sense, you have to license your code appropriately and make your code publicly available and discoverable. I believe that software paid for by the public should (except in certain circumstances) live in the public domain, but if the public can’t find it or view it, is it in their domain? Furthermore, some of the benefits of making open source code such as enabling reuse, providing transparency and accountability to algorithms, and facilitating contributions from the public (more on contributing below), are nigh on impossible without the code being available publicly online.

People sometimes make their code publicly available on the internet and don’t use an open source license, either intentionally, like Mapbox, or because they forget (totally guilty here!), so always be sure to look for the license is you’re about to use code you’ve found online, and don’t forget the license on your own projects.

CONTRIBUTE to open source software

Contributing to open source software, while not a necessary part of using or making it, is a key way to unleash the value of open source software. For government, this could mean that your team contributes back to the open source software it uses, and/or that your team allows the public to contribute to the open source project that it makes.

Contributions don’t have to be code: they can be reporting bugs, adding or fixing documentation, answering questions on Github issues, translating content, or even providing money to the open source maintainer team or governing body to support continued development.

Individuals working on government teams should be encouraged to contribute back to open source software that the team uses, because it helps make the software better and ultimately makes that team’s end product better – and even more secure. One example of government already doing this is QGIS, a popular free and open source geographic information system. Although QGIS is not a government-created or -maintained tool, the changelog shows new features that were developed by or funded by local and national governments over time.

The recent log4j vulnerability highlighted the value of contributing back to open source: maintainers of this critical open source library that used by many federal agencies are volunteers, and if the government were to invest resources into supporting this project or others that it uses, then they could help identify and mitigate vulnerabilities more quickly. Contributing to open source is investing in digital infrastructure.

Likewise, government teams can realize a huge amount of value by supporting public contributions. The US Web Design System, an open source project includes design components, tools, and guides for government agencies to use in the design of their websites, has over 150 contributors – way more than the number of staff actually on the project. This sort of value isn’t realized overnight, and empowering external contributors takes substantial work in the form of good documentation and a responsive team, but it’s a worthwhile goal for many government projects.