Discuss | Edit | View PDF of Policy

Source Code Policy

5. Federally Funded Custom Code as Open Source Software

As previously mentioned, a number of private sector companies have shifted some of their software use and development to an open source model.24 Similarly, when properly implemented and documented, releasing code as open source can benefit Federal agencies by allowing professional communities of practice to develop around software libraries and Application Programming Interfaces (APIs). This collaborative atmosphere makes it easier to conduct software peer review and security testing, to reuse existing solutions, and to share technical knowledge.25 In fact, the Federal Government and partner organizations have recently begun using more OSS and publishing some of their custom software code under open source licenses or in the public domain. Some examples include:

  • “We the People”26 – This 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;27

  • The General Services Administration’s (GSA) 18F28 and the Consumer Financial Protection Bureau (CFPB)29 – Both of these government organizations have policies that establish a default position to publicly publish all custom code developed by or for the organization—whether developed in-house by Federal staff or through negotiated agreements—with limited exceptions;

  • The Department of Defense (DoD) – This government agency issued guidance30 dating back to 2009 that, among other things, clarifies the use of OSS at DoD and makes clear that OSS products are on equal footing with their proprietary counterparts in terms of procurement and usage; and

  • The Open Source Electronic Health Record Alliance (OSEHRA) – This is an independent 501(c)(6) organization that was established in 2011 to support the Veterans Information Systems and Technology Architecture (VistA) electronic health record system developed by the U.S. Department of Veterans Affairs. OSEHRA supports the VistA community through activities such as maintaining code repositories, providing certifications and standards, and facilitating developer engagement. The code is released under a standard OSS license.31

As outlined in the OMB Open Government Directive,32 the three principles of transparency, participation, and collaboration form the cornerstone of an open government. Federally released OSS embodies these principles. Leveraging the skills and knowledge of individuals across the Federal Government and beyond can result in, among other things, enhancements to code quality and security as a result of public scrutiny of open source code.33 Federal OSS can also contribute to economic growth and innovation as state and local governments, private sector companies, taxpayers, and others can reuse that code to develop products and services for the public.34

5.1 Pilot Program

In furtherance of the objectives outlined in the Open Government Directive, this policy requires that covered agencies participate in the following pilot program to encourage the development and publication of custom-developed Government code as OSS.

Each covered agency shall release at least 20 percent of its newly-developed custom code each year as OSS. Custom code is defined as code for all custom software projects, modules, and add-ons that are self-contained.35 When deciding which custom code projects to release, each covered agency should prioritize the release of custom code that it considers potentially useful to the broader community.36

Although the minimum requirement for OSS release is 20 percent of custom code, covered agencies are strongly encouraged to publish as much custom-developed code as possible to further the Federal Government’s commitment to transparency, participation, and collaboration. Please note that this requirement refers to new code that is developed by third party developers or vendors on behalf of a covered agency, as opposed to code developed by Federal employees as part of their official duties. As noted previously, all new custom code developed by covered agency employees as part of their official duties shall be released to the public—subject to certain exceptions—as enumerated in Section 6 (“Exceptions to Government-wide Reuse or to Publication”).

Within 120 days of the publication of this policy, OMB shall develop metrics to assess the impact of the pilot program. No later than two years after the publication date of this policy, OMB shall consider whether to issue a subsequent policy to continue, modify, eliminate, or expand the pilot program. Unless extended by OMB through the issuance of further guidance, the pilot program will expire three years (36 months) after the publication date of this policy. Please refer to the “Implementation” section of this policy for additional guidance on how to comply with the requirements of the pilot program.

5.2 Membership in the Open Source Community

Communities are critically important to the long term viability of open source projects. Consistent with the Digital Government Strategy’s principles to participate in open source communities and leverage public crowdsourcing, covered agencies should develop and release code in a manner that (1) fosters communities around shared challenges; (2) optimizes the ability of the community to provide feedback on, and make contributions to, the code; and (3) encourages Federal employees and contractors to contribute back to the broader OSS community by making contributions to existing open source projects. In furtherance of this strategy, covered agencies must comply with the following principles:

  1. Leveraging Existing Communities – Whenever possible, custom code released to the public as OSS should be incorporated into existing communities of practice that are self-sustaining. For example, there are already existing communities for electronic health records and geospatial software.37 Government agencies should only develop their own communities when existing communities do not satisfy their needs.
  2. Open Development – Software that is custom-developed for or by covered agencies should, to the extent possible and appropriate, be developed in the open. Open development practices provide an environment in which open source code can flourish and repurposed. This principle, as well as the principle for “Releasing Code” below, shall include the distribution of a minimum viable product as open source code, engaging the public before official release,38 and drawing upon the public’s knowledge for bug fixes, algorithmic optimization, and other improvements to the project.
  3. Incremental Release – In instances where software cannot be developed in the open, but is otherwise appropriate for release to the public, covered agencies must develop and use an incremental release schedule and undertake all necessary steps to make the code and associated documentation available for public use. This will assist in discouraging the practice of releasing large, bulk pieces of software code, which negates many of the positive attributes of open source software.
  4. User Engagement – Like in the Administration’s Open Data Policy, covered agencies must create a process to engage in two-way communication with users to solicit help in prioritizing the release of code and feedback on the agencies’ engagement with the community. See Project Open Source for best practices and tools that can be used to implement user engagement efforts.
  5. Code Contributions – One of the most powerful potential benefits of OSS lies within the communities that grow around OSS projects, whereby any party can contribute new code, modify existing code, or make other suggestions to improve the software. Communities can be used to monitor changes to code, track potential errors and flaws in code, and other related activities. These kinds of contributions should be anticipated and, where appropriate, considered for integration into custom-developed Government software or associated materials.
  6. Documentation – It is important to provide OSS users and contributors with adequate documentation of source code in an effort to facilitate use and adoption. At a minimum, OSS repositories must include a README (or similar) file that includes the following information (note that additional guidance on repositories can be found in the “Implementation” section of this policy):
    1. The status of the software (e.g., prototype, alpha, beta, release, etc.);
    2. The intended purpose of the software;
    3. Expected engagement level (i.e., how frequently the community can expect to be engaged by the agency);
    4. License details; and
    5. Any other relevant technical details on how to build, make, install, or use the software, including library dependencies (if applicable).

Footnotes