Introduction

M-16-21

MEMORANDUM FOR THE HEADS OF DEPARTMENTS AND AGENCIES

FROM:

Tony Scott United States Chief Information Officer

Anne E. Rung

United States Chief Acquisition Officer

SUBJECT:

Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software

The U.S. Government is committed to improving the way Federal agencies buy, build, and deliver information technology (IT) and software solutions to better support cost efficiency, mission effectiveness, and the consumer experience with Government programs. Each year, the Federal Government spends more than $6 billion on software through more than 42,000 transactions.¹ A significant proportion of software used by the Government is comprised of either preexisting Federal solutions or commercial solutions. These solutions include proprietary, open source, and mixed source² code and often do not require additional custom code development.

When Federal agencies are unable to identify an existing Federal or commercial software solution that satisfies their specific needs, they may choose to develop a custom software solution on their own or pay for its development. When agencies procure custom-developed source code, however, they do not necessarily make their new code (source code or code) broadly available for Federal Government-wide reuse. Even when agencies are in a position to make their source code available on a Government-wide basis, they do not make such code available to other agencies in a consistent manner. In some cases, agencies may even have difficulty establishing that the software was produced in the performance of a Federal Government contract. These challenges may result in duplicative acquisitions for substantially similar code and an inefficient use of taxpayer dollars. This policy seeks to address these challenges by ensuring that new custom-developed Federal source code be made broadly available for reuse across the Federal Government.³ This is consistent with the Digital Government Strategy’s “Shared Platform” approach, which enables Federal employees to work together—both within and across agencies—to reduce costs, streamline development, apply uniform standards, and ensure consistency in creating and delivering information.⁴ Enhanced reuse of custom-developed code across the Federal Government can have significant benefits for American taxpayers, including decreasing duplicative costs for the same code and reducing Federal vendor lock-in.⁵

This policy also establishes a pilot program that requires agencies, when commissioning new custom software, to release at least 20 percent of new custom-developed code as Open Source Software (OSS) for three years, and collect additional data concerning new custom software to inform metrics to gauge the performance of this pilot.⁶

While the benefits of enhanced Federal custom-developed code reuse are significant, additional benefits can accrue when source code is also made available to the public as OSS. Making source code available as OSS can enable continual improvement of Federal custom-developed code projects as a result of a broader user community implementing the code for its own purposes and publishing improvements. This collaborative atmosphere can make it easier to conduct software peer review and security testing, to reuse existing solutions, and to share technical knowledge.⁷ Furthermore, vendors participating in or competing for future maintenance or enhancement can do so with full knowledge of the underlying source code. A number of private sector companies have already shifted some of their software development projects to an OSS model, in which the source code of the software is made broadly available to the public for inspection, improvement, and reuse.

Several Federal agencies and component organizations have also begun publishing custom-developed code as OSS or without any restriction on use. Some of these include:

• The White House: “We the People” is a White House service that allows the American people to easily and interactively petition their Government. The source code for this website is freely available as OSS;⁸

• 18F⁹ and the Consumer Financial Protection Bureau (CFPB):¹⁰ Both of these organizations have policies that establish a default position to publish source code that is custom-developed by or for the organization. For example, both organizations contribute to the source code for the eRegulations platform,¹¹ a web-based interface for public viewing and commenting on proposed changes to Federal regulations. The eRegulations platform, which originated at CFPB, is being used by other Federal agencies¹² and continues to be improved based on public feedback;¹³

• The Department of Education: This agency’s “College Scorecard” is a citizen-facing OSS website and accompanying application programming interface (API) that provides free tools to help potential students make informed decisions about which colleges or universities to attend;¹⁴ and

• The Department of Defense (DOD): This agency issued a memorandum¹⁵ in 2009 that, among other things, describes the many benefits of OSS that should be considered when conducting market research on software for DOD use.¹⁶

The Administration made a commitment, as part of its Second Open Government National Action Plan,¹⁷ to “develop an open source software policy that, together with the Digital Services Playbook, will support improved access to custom software code developed for the Federal government.”¹⁸ This policy fulfills that commitment in an effort to improve U.S. Government software development and make the Government more open, transparent, and accessible to the public.

Footnotes

• ¹ M-16-12: Improving the Acquisition and Management of Common Information Technology: Software Licensing. Office of Mgmt. & Budget, Exec. Office of the President, June 2, 2016. https://www.whitehouse.gov/sites/default/files/omb/memoranda/2016/m-16-12_1.pdf. ↩
• ² See Appendix A for definitions of key technical terms used throughout this policy document.↩
• ³ See Section 6 of this policy for additional information about limited exceptions.↩
• ⁴ Digital Government: Building A 21st Century Platform To Better Serve The American People, Office of Mgmt. & Budget, Exec. Office of the President, May 23, 2012. https://www.whitehouse.gov/sites/default/files/omb/egov/digital-government/digital-government.html. ↩
• ⁵ “Vendor lock-in” refers to a situation in which the customer depends on a single supplier for a product and cannot easily move to another vendor without sustaining substantial cost or inconvenience. Vendor lock-in can potentially raise costs and stifle innovation and it can result in reduced competition on future related software acquisitions.↩
• ⁶ Clinger Cohen Act of 1996. 40 U.S.C. §§ 11301-11303.↩
• ⁷ Department of Defense Chief Information Officer. Clarifying Guidance Regarding Open Source Software (OSS). October 16, 2009. “The continuous and broad peer-review enabled by publicly available source code supports software reliability and security efforts through the identification and elimination of defects that might otherwise go unrecognized by a more limited core development team.” http://dodcio.defense.gov/Portals/0/Documents/FOSS/2009OSS.pdf.↩
• ⁸ “We the People” petitions are accessible at https://petitions.whitehouse.gov/. The source code for “We the People” is available at https://github.com/WhiteHouse/petitions.↩
• ⁹ 18F (https://18f.gsa.gov/) is a digital services delivery team within the General Services Administration. The 18F Open Source Policy is described at https://18f.gsa.gov/2014/07/29/18f-an-open-source-team/ and can be accessed at https://github.com/18F/open-source-policy/blob/master/policy.md.↩
• ¹⁰ CFPB’s source code policy is described at http://www.consumerfinance.gov/blog/the-cfpbs-source-code-policy-open-and-shared/ and can be accessed at https://cfpb.github.io/source-code-policy/. ↩
• ¹¹ “eRegulations,” CFPB’s platform to read regulations, is accessible at http://www.consumerfinance.gov/eregulations/.↩
• ¹² The Bureau of Alcohol, Tobacco, Firearms, and Explosives (ATF) has adopted a beta version of “eRegulations,” accessible at https://atf-eregs.18f.gov/. ↩
• ¹³ The publically accessible open source repository for submitting comments and proposing improvements to the “eRegulations” platform is accessible at https://github.com/eregs/notice-and-comment. 18F also developed https://analytics.usa.gov—jointly with the U.S. Digital Service—to provide a window into how people are interacting with the Federal Government online and made the source code available online (https://github.com/18F/analytics-reporter). The cities of Philadelphia, PA (http://analytics.phila.gov/) and Boulder, CO (https://bouldercolorado.gov/stats) were able to reuse the code to provide their own citizens with real-time information on how city government websites serve citizens.↩
• ¹⁴ The Department of Education’s College Scorecard is accessible at https://collegescorecard.ed.gov/. The open source repository for the website and API that runs the College Scorecard is available via 18F’s GitHub repository, accessible at https://github.com/18F/college-choice. ↩
• ¹⁵ Department of Defense Chief Information Officer. Clarifying Guidance Regarding Open Source Software (OSS). October 16, 2009. http://dodcio.defense.gov/Portals/0/Documents/OSSFAQ/2009OSS.pdf ↩
• ¹⁶ The Department of Defense’s OSS FAQ states that “continuous and broad peer-review, enabled by publicly available source code, improves software reliability and security through the identification and elimination of defects that might otherwise go unrecognized.” Frequently Asked Questions regarding Open Source Software (OSS) and the Department of Defense (DoD), accessible at https://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx.↩
• ¹⁷ The Open Government Partnership: Announcing New Open Government Initiatives as part of the Second Open Government National Action Plan for The United States of America. September 2014. Page 2. https://www.whitehouse.gov/sites/default/files/microsites/ostp/newnapcommitmentsreport092314.pdf. ↩
• ¹⁸ The Digital Services Playbook was developed by the U.S. Digital Service and consists of key “plays” that can help the Government build effective digital services. It encourages agencies to “default to open” and seek contracts that specify that “software and data generated by third parties remains under [the U.S. Government’s] control, and can be reused and released to the public as appropriate and in accordance with the law.” It also requires an explanation “[i]f the codebase has not been released under an open source license.” https://playbook.cio.gov/.↩