Section One: An Overview of Open Source

Open source software (OSS), by definition, is “software that is readily available with its source code and license, free of cost to anyone who wants to study, change, modify, or distribute it,” as per the World Bank’s Open Source for Global Public Goods report. For people unfamiliar with the software development world, OSS is essentially chunks of code that are available online for anyone to use. While many non-coders may think software is written from scratch, in fact, much of the modern development process involves piecing together these blocks of code to create new applications. For example, have you ever had to reset your password to access an app? It is a common use case. If a developer needs to add that functionality to a new project, the developer can easily take existing code for resetting passwords and incorporate it into the new project rather than writing that code from scratch.

All kinds of software can be open source, from operating systems and under-the-hood utilities to web browsers and user-facing websites. A 2020 report by Synopsys notes that the majority of the world’s software is open source, and that nearly all software has some open source component to it. Chances are high that your organization is already using OSS, either directly or through other software that depends on it.

At a bare minimum, OSS is simply releasing the software’s source code publicly. One version of this is called coding in the open—publishing the source code of a system or application without taking care to ensure its reusability. While still valuable, the benefits of coding in the open fall short of what’s possible with OSS. A more robust use of the term includes providing an open license that permits broad use of software, documentation, and guidance so it can be used by others, and encouraging community engagement to facilitate organized collaboration and solve common issues.

Indeed, when fully implemented, OSS can lead to collaboration, innovation, cost savings, and sustainability—all by building software openly and for reuse. Open source aspires to a new way of thinking about ownership and accountability, something built by and responsive to the collective of users rather than purely traditional market mechanisms. Adopting open source practices as an organization means moving an organization’s culture away from one of proprietary holdings and closed ownership, and towards collaboration and working in the open.

OSS is released with specific licenses that outline the permitted usage of its source code. The licenses outline terms of use, such as requiring attribution of the original authors, that must be followed to use the software. When using open source tools, it is important to review the license to ensure you abide by its allowances and restrictions. When releasing your own OSS, it’s necessary to provide a license that makes clear what your resources can be used for. Common licenses are reused across many open source projects, such as the MIT license or the GPL license. The Open Source Initiative maintains a strongly vetted list of common open source licenses used by many in the software industry. By using common licenses, projects reduce the burden of understanding unique license terms and provide clear and well-understood terms to the use of their resources.

The benefits of using open source principles is well understood and documented by the software community around the world. Anna Shipman, former open source lead with the United Kingdom’s Government Digital Service, articulated an excellent set of benefits for open source work. Sean Boots and Josh Ruihley of the Canadian Digital Service expand on these benefits in their own analysis of the benefits of open source. We have provided a brief summary of benefits here for those who are new to open source.

Maximizes Resources and Improves Efficiencies

Maximizing existing resources and pursuing cost-effective solutions is an optimal strategy in government. Many civil servants are asked to do more with less. Equally true is the fact that most problems that civil servants encounter have been solved before, likely by a different office or a different jurisdiction altogether. Building on and reusing other organizations’ work can decrease opportunity costs and allows teams to get started making changes more quickly.

When starting a new project, significant effort must be spent on discovery, user needs and wants, development and testing, including security and usability. Using open source code reduces the time and cost of this process and can be a far more efficient route. Reusing existing code and processes can improve the speed of development and deployment, reduce the development costs, and allow for best practices. For example, there may be fewer vulnerabilities and bugs in an application since the source code has been worked on by many people, all of whom have the opportunity to point out and address these issues. These benefits all build upon one another as well—the more your organization uses open source solutions, the more benefits you see from it.

Open source software is free to use. You can copy and use the source code without payment to the original creators, and use it in whatever way you would like (consistent with the software license). Proprietary software often comes with license fees, contract agreements, and may be packaged as a bundle, which means you may pay for tools and features you don’t need.

However, this doesn’t mean that there are zero costs associated with using open source software. While the code itself is free and open, there are other types of cost considerations to make, such as server infrastructure or technical talent to modify the source code and paid support options. Still, these costs are often much less than the typical license fees associated with proprietary software. In addition, most of these costs are a constant regardless of whether you are using open source tools, building your own software, or using proprietary solutions.

Improves Trust and Increases Government Transparency

The benefit of transparency goes beyond creating accountability—it’s also a core part of working on public services. The public should be able to see the work that their government is doing for their benefit. Transparency makes it clear that progress is being made on important services and issues, and keeps the public informed on future plans. Open sourced work encourages active feedback and participation from the public, who can now view the progress as it happens and hold more confidence and trust in the work. As the Department of the Interior puts it, “By using open software and working in the open, you remove barriers to critical evaluation and participation from others. Inviting critique from others can be uncomfortable, but it increases the likelihood that the final product is more effective at meeting the needs of multiple stakeholders inside and outside government.”

The public should be able to see the work that their government is doing for their benefit.

When using OSS, either by building it or using other OSS applications, it’s easier to explain how the tools work. Nothing is proprietary or hidden. Instead, the code is accessible and available for review by anyone. This makes discovery of efforts within and across government much easier. This is important because it’s fairly common for a government organization to have duplicate or competing projects simply because they didn’t know of each other's existence. The transparency provided by open source helps governments discover tools that are already vetted by other organizations including their own government organization, and allows them to quickly and cost-effectively adapt those solutions to their immediate challenges.

More Sustainable Tools, Less Vendor-Dependence

Using OSS greatly improves the flexibility of an organization by allowing the use of multiple vendors and giving developers the ability to share software with others in the organization, and use or reuse as much of the software as needed. OSS guarantees that an organization and the public have full access to the source code without needing any permissions from the vendor.

Regardless of whether you open source your own tools or use existing open source tools, you are still ultimately responsible for the service. Using open source software does not put the onus on other contributors—as the service owner, that still falls on your shoulders. For example, you still hold the responsibility of ensuring security and meeting users’ needs. However, using open source tools makes each of these easier to achieve, and enables a community of like-minded contributors to support each other in achieving these goals. Open source software also offers flexibility in moving between tools that proprietary services seldom offer.

Grants Full Control of the Software

Much of the software that governments and people rely on is closed source and proprietary. It is owned by its developer. When there are bugs or other issues within the software, the developer is the only one that can fix it. Similarly, if software needs to be upgraded, integrated, or changed, only the company that owns the software can make that change. With OSS, any organization—including software users—can fix or change the software. OSS has roots in a philosophical belief that software should be free and open for all to use and learn from, as described in this blog. By using OSS, governments can maintain control over their software, tools, infrastructure, and services.

Encourages Good Development Practices

Open sourcing work encourages good development practices by creating public accountability. Put simply, if everyone can see something, then it has to be good enough to release to the public right from the start. The quality of the work, its documentation, code reviews, version control, and other factors are all held to a high standard, encouraging good software development practices. Open source also brings critical considerations, such as security, software design, documentation, processes, and even ownership, immediately to the forefront.

Simplifies Collaboration and Facilitates Innovation

Collaboration of all kinds is simplified when work is done in the open. When software is openly available, there are no required special approvals, agreements, or tools for code to be shared. When the software is well documented and supported by a community, it’s simple for new collaborators to start using it and contributing to it. New team members are able to find all project information since it is available openly. Developers can access and perform work using their tools of choice, rather than proprietary tools. In the current closed-source state, two different teams at the same government agency might require weeks or even months of time to secure the approvals necessary to share work. With open source software, collaboration can start immediately. Inviting people to collaborate on open source projects is much simpler, as the work to open it up broadly has already been done. This is especially helpful in times calling for rapid response, such as during a public crisis, when governments can tap into existing software and communities to build solutions that are already open sourced to the public.

Fosters growth of common solutions

Open source collaboration is a learning experience that allows both authors and contributors to exchange ideas about how each developer might solve a specific problem. Even when software has been developed, contributors may apply the software in a different way than the author had originally intended, teaching everyone something new in the process. Collaborators can use open source work as a starting point in solving their own versions of similar problems, saving valuable time and growing the original base of work. For example, the United Kingdom’s Government Digital Service released their Notify platform as open source, allowing other governments, such as the government of Canada, to adopt it for its own purposes by modifying it to support multiple languages. Additionally, open source solutions reduce duplicative work by allowing groups to collaborate on solving common problems with common solutions, rather than creating competing or diverging solutions. By making the work open source, organizations create the opportunity for creative expansion on top of what has already been done.

Inviting critique from others can be uncomfortable, but it increases the likelihood that the final product is more effective at meeting the needs of multiple stakeholders inside and outside government.

Broadly speaking, there are five paths towards adopting OSS in government. These paths differ largely because of two factors: whether a solution is new or existing, and whether organizations use a solution they created or one created by an outside entity. Here, we provide brief descriptions of each path, so that you might recognize which one may apply to you. As you read through sections two and three of this report, you’ll find that having your path in mind will help you understand how our research applies to you.

1. Working in the Open on a New Solution

On this path, agencies and organizations create new software addressing an unmet need. The software, part of a broader solution, is created specifically for the purposes of a solution. The developers might use a vendor's services to develop the software, having procured their services through a contract or grant, or may utilize in-house technical talent to write the software. Alternatively, they may have a partnership with a third party, such as an academic institution or philanthropic organization. While existing software may be integrated with the project, its main components require software to be written from scratch by developers or software engineers.

2. Migrating an Existing Solution into the Open

Governments use existing software solutions for their services and processes. In some cases, this software is old and unmaintained, though it still functions. Many of these systems are called legacy systems, which simply means software systems that are not being actively developed. You and your organization can move these applications and services into the open, using principles and practices discussed throughout this report. Legacy solutions will require review and some amount of refactoring, to open up the source code. This review and refactoring can have an added benefit of helping to make the software more secure, understandable, and useful—both for the public and your organization. Updating and refactoring legacy systems may not always be possible for a variety of reasons, from fragility of the underlying code and lack of backwards compatibility, to missing relevant expertise in a given programming language. When it is possible, it will take work, but the benefits, including the ability to increase security, collaboration, accountability, and transparency, are worth it.

3. Adapting an Open Source Solution to Meet Your Needs

Many of the standard problems that organizations have, such as inventory management or case management, can be solved by open source solutions, but they may still need customization to match your organization’s workflow, language, or needs. For example, open source case management systems can be easily configured to handle the particular types of cases your office processes. When using this kind of software, you need less direct software engineering talent than the first two paths, and instead should look for talent (either in-house or contracted) that can support the configuration and maintenance of the software.

4. Using an Open Source Solution without Customization

In some cases, you can find an open source solution that solves your problem directly, without any need for customization. While it might seem rare, consider that Firefox, one of the most popular web browsers, is open source and requires no customization to use. Open source software like Firefox is high-quality, easy to use, and doesn’t require that much technical or development knowledge. In these cases, the fact that the software is open source may not even be apparent to the users even as your organization gains the benefits of the security, feature updates, and larger community that the open source software provides.

5. Using Mixed-Source Software

Lastly, your organization might be using a mix of OSS and proprietary software as a way to ease into open source principles. This path presents challenges, as it can be unclear in vendor contracts what software might be required to be open source and what might be public. Integration can often be difficult, too, since interoperability can vary with custom build solutions. As much as possible, we recommend avoiding this path and using open source software exclusively. When this is unavoidable, clearly articulate the expectation of what software will be proprietary and why, and require that all other software be made open source.

The thought of using open source software instead of a commercial product often elicits numerous questions and concerns. A few of the most common questions about OSS include:

Q: Is Open Source Software Secure?

A: There is a common misconception that OSS is inherently less secure than proprietary software, due to the source code being publicly available. The logic for this is that if a malicious attacker has access to the source code, they can find and exploit vulnerabilities. This argument relies on the assumption that a closed-source piece of software is more secure simply because people cannot read the source code.

However, the consensus in the security space is that open source code provides an opportunity for better security practices over closed-source code. Open source code can be reviewed by collaborative and independent security experts for vulnerabilities, and these same reviewers can contribute fixes or work directly with the authors to implement solutions to these vulnerabilities. Independent and open code review makes solutions stronger and more secure. By contrast, relying on obscuring code for the sake of security actually introduces more security risks, as obscured code cannot be assessed by third parties and there may be fewer people using it as a whole. This comes into play often in a government setting where custom software was developed for exclusive use by the organization. The Department of Defense states that studies in software vulnerabilities “make it clear that merely hiding source code does not counter attacks.” The Department of Homeland Security found in their research that, “there was not an increased risk of low quality and malware in OSS compared to proprietary software.“ The United Kingdom government’s guidance states that by “keeping your code closed, you can also introduce other risks and complications including deprioritisation of code review, [and] additional costs and complexity of access controls.“

Independent and open code review makes solutions stronger and more secure.

Obscure code also allows vulnerabilities to exist in the codebase in an unknown or undisclosed state. Additionally, attackers do not need access to the source code to take advantage of a vulnerability. Opening the source code allows collaborative security partners to support in protecting against these attackers. In short, when software relies on obscurity to enforce security, it assumes that potential attackers don’t have other means to find and access vulnerabilities—which they regularly do, especially when the most common attack vectors have nothing to do with source code anyway

The most significant recommendation of the open source movement may be the fact that many of the top security tools on the market are open source as well, such as HashiCorp. These projects use more diligent security practices, including rapid security patches, automated vulnerability detection, and separation of sensitive information to stay ahead of security vulnerabilities. By building these security tools as open source, the developers have created tools that are often more transparent, accountable, and secure than proprietary, closed-source tools.

Q: What are Open Source Licenses?

A: The OSS license ecosystem is robust, mature, and easily understood. Many resources exist to support navigating licenses, such as the Open Source Initiative’s list of licenses or GitHub’s choosealicense.com. Additionally, there are technical legal experts that can assist with the interpretation of common and uncommon licenses. With proper consideration and incorporation of legal guidance, the risk of violating a license is small. Navigating this terrain generally amounts to determining whether or not attribution must be given, how your current systems and software are licensed, and how your licenses will be affected when integrated with OSS licenses you use. GitHub provides a great guide for understanding some basics of the legal side of open source.

Q: Is Open Source Software Kept Up-To-Date?

A: Just as with any software project, OSS varies in degree of maintenance. In some cases, a project may be years old and not updated since it was launched. (However, this doesn’t necessarily mean that the software doesn’t work). In other cases, a project is actively maintained, often with a vibrant and well-organized community supporting it. When using OSS, look for software that is actively updated with security patches as well as releases of new features. Software that hasn’t been updated for months or years likely will not receive attention when it needs an update, such as when a security vulnerability is uncovered. Some well-resourced open source organizations, such as the Apache Foundation or the Linux Foundation, might themselves maintain open source projects, and applications that come out of these groups are typically safer to use. In addition, OSS that garners user groups, discussions, and communities should have longevity and get regular updates.

Q: Will Using Open Source Reveal Policies Prematurely?

A: Code that implements yet-to-be-released policy should remain closed until the policy is public so software implementation details don’t potentially complicate the release of the policy. Government policies tend to follow particular paths to being released, and openly publishing the software that implements a new policy could give the public an incomplete or incorrect view of it. Once the policy is public, the code supporting it should be immediately made public as well, to demonstrate how the policy is being implemented. Afterwards, all further code should be developed in the open. Developers working on this type of software should coordinate closely with the release of the policy to ensure proper timing of the software release schedule. GOV.UK has a detailed resource for what should remain closed in these cases, which can be found here.