Checklist for How Governments Can Leverage Open Source Solutions

Software for public benefit should be open source by default

  1. Create organization-wide open source policies: Create organization-wide policies that establish that all teams and offices pursue open source solutions before acquiring, designing, or building their own systems. Policies can also outline processes and decisions to make it easier for teams to adopt open source, such as pre-vetting open source licenses that can be used.
  2. Make usage of open source a priority: Technology modernization is a top priority for many governments in response to aging legacy systems and heightened constituent and user expectations of transparency and service quality. Open source software should be a part of these priorities and efforts. Open source software can reduce costs, improve transparency, and lead to more efficient services by building on solutions that have been developed to address the same challenge, rather than reinventing wheels.
  3. Clarify misconceptions on the security of open source solutions: Many believe that open source software is less secure, due to the nature of the source code being available to the public. However, the process of making application source code open can make it more secure in a number of ways: open source code can be reviewed by independent security analysts, making discovery of any issues faster and more actionable. The Department of Defense, Department of Homeland Security, and UK Government have all vetted open source as a secure method of developing software.
  4. Work in the open: When adopting open source principles, projects should not just be opened upon completion. Instead, all development work should be done in the open. This includes everything from coding to documentation, as well as research and decision-making artifacts. In some cases, such as when policy is not yet released, this may not be possible. But as soon as it is, all historical work and all work going forward—not simply the finished product—should be done in the open.
  5. Publicly document your work: Open source projects should include comprehensive public documentation that is maintained as up-to-date as possible. While most organizations that have used closed systems are accustomed to receiving end-user documentation like user manuals, good open source software is itself well-documented, from project roadmap documentation that outlines the plan for the project, to contribution guidelines that guide outside developers on how they can best contribute, and software documentation that explains how different portions of the software work. For good references on projects that have achieved these goals, see the Atom repository and the VSCode.
  6. Use permissible open source software licenses: The open source software license ecosystem is robust, mature, and well-understood. Many resources exist to support navigating licenses, such as the Open Source Initiative’s list of licenses or GitHub’s choosealicense.com. We recommend permissive licenses, such as the MIT license and the Apache license, as they give anyone the ability to use, modify, and redistribute the software as they see fit, which will help not only your organization, but others who are trying to solve a similar problem for their constituents.
  7. Migrate existing software and code to open source: While the best practice is to make projects open from the start, an existing closed system doesn’t necessarily have to remain closed. Opening existing projects is worth the effort, even though it can be difficult. The process provides value in the various arenas described throughout the report, including security, transparency, and accountability. Migrating existing projects tends to be more difficult because the entire project needs to be reviewed prior to being made open. Reviews should check for and resolve security vulnerabilities, including bugs as well as sensitive information (e.g. passwords) that were written into code. It also requires all documentation to be updated.
  8. Hire in-house technical talent to manage common open source solutions: As with any technology project, certain types of in-house expertise are critical in using and managing open source solutions. Hire technical talent, such as product managers, designers, and senior software engineers, to support building, modifying, and using open source software.
  9. Facilitate interoperability: Whether you are building a new system in the open or reusing existing open source solutions, you will still be operating a system that likely collects data or works in tandem with other systems or applications. Incorporating team members who are knowledgeable about existing systems and prevalent data standards will drastically reduce integration pains down the road. Use open interfaces, or APIs, that are well-documented and automate the transfer of data to ease future system integrations.
  10. Follow product development best practices: Whether software development is open source or not, it is essential to learn from and follow known software development best practices. Follow established approaches such as agile development to define clear goals, build iteratively, and design with users in mind. We find GOV.UK and the U.S. Digital Services Playbook to be great starting points for understanding best practices for creating government digital services.
Checklist for How Governments Can Leverage Open Source Solutions

Table of Contents

Close