Table of Contents
- Overview
- Section One: An Overview of Open Source
- Section Two: Building Open Source Software
- Section Three: Using Open Source Software
- Section Four: Managing the Details
- Additional Resources
- Checklist for How Governments Can Leverage Open Source Solutions
- Open Source Project Hubs for COVID-19
- Further Reading
Overview
In this report, we outline a high-level framework for approaching the development of public services using open source software (OSS) principles and practices to maximize the reuse of existing software. Open source principles are an integral part of well-designed public technologies. Software for public benefit, such as election platforms or benefit case management systems, should always be open by default.
This report defines OSS, the benefits and risks associated with it, and provides steps for using open source principles in your organization or agency. While there are many important principles for building good software products, such as user feedback, sustainability, and open data, we will be focusing on the value of OSS in this resource. Open source software is still software, and while we won’t be going into all of the components of good software development in this report, it is important to learn from and follow known software development best practices. For example, approaches such as agile development 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.
Who Should Read this Report
This resource is intended for public servants, from executives to program managers, who are building the next iteration of digital government solutions. We initially undertook this research with the goal of providing useful information for practitioners, and we understand that there are many different types of practitioners in the government technology ecosystem.
We’ve outlined below how we anticipate different audiences can best harness this content.
- Government Leaders: We aim to inspire government leaders to think differently about technology, and to provide them with a roadmap for how to bring OSS into their country, city, county, state, and agency software and services development lifecycle. This report provides foundational knowledge that executive decision makers can tap when setting organizational strategy.
- Technology Leaders: Directed by the strategy and policy set forth by organizational leadership, technology implementers translate desired public outcomes into technical products. They enact the agenda using technology, aiming for on-time, on-budget, and effective delivery of services. This report outlines how to make open source a core part of the implementation of government services, and provides arguments for why OSS is the best choice for government services.
- Innovation Officers: Innovation officers fall into a special category of government leaders, as they tend to be highly technical and hold positions of authority in their organization. We look to innovation officers as a driving force, a catalyst to lead colleagues along government services modernization efforts. This report provides this cohort with the research needed to support this work, as well as actionable recommendations for their efforts.
- Decision makers including government officials (e.g. legal, procurement, security): OSS presents a very different operating model than what government is traditionally used to. Software is built or procured at no cost, and ownership is less important than license provisions since open source licenses vary in their permissiveness. This cohort of officials have a duty to reduce the risk of government projects. This report provides information regarding security, licenses, ownership, and costs, arming these approving government officials with the knowledge they need to confidently assess open source at its true value, rather than as an unknown entity.
Software for public benefit, such as election platforms or benefit case management systems, should always be open by default.
The Structure of this Report
The research is broken into four main sections. While we encourage you to read the entire report, we understand that you might want to review the sections that pertain most to your needs.
Section One: An overview of open source
This section is a primer on open source in government, and answers some key high-level questions that many newcomers may have. All readers should read this section as it will help grow their baseline understanding of open source, and correct some common misconceptions about the feasibility of government open source solutions.
Section Two: Building open source software
In this section, we provide guidance for organizations looking to build their own open source systems and outline considerations to keep in mind.
Section Three: Using open source software
An outline of recommendations on how to best use existing open source software. In this section, we cover topics ranging from finding open source solutions to understanding the licenses of open source software that you might use. Readers looking to find open source tools to bring into their organization should read this section.
Section Four: Managing the details
We discuss some of the details that should be kept in mind when moving your organization into a more holistic open source strategy. These details are common regardless of whether you build new software, or use existing OSS. Topics such as open source implementation policy, in-house technical talent, and copyright fall into this section.