presidential-innovation-fellows/code-gov-web

<h2>5. Open Source Software</h2>

<h3 id="pilot-program-publication-of-custom-developed-code-as-oss">5.1 Pilot Program: Publication of Custom-Developed Code as OSS</h3>

<p>Each agency shall release as OSS <u>at least 20 percent</u> of its new custom-developed code<sup id="fnr29"><a pageScroll href="#fn29">29</a></sup> each year for the term of the pilot program. As discussed above, agencies must obtain sufficient rights to custom-developed code to fulfill the open source release objectives of this policy’s pilot program.</p>

<p>When deciding which custom-developed code projects to release, each agency should prioritize the release of custom-developed code that it considers potentially useful to the broader community. Agencies should calculate the percentage of source code released using a consistent measure—such as real or estimated lines of code, number of self-contained modules, or cost—that meets the intended objectives of this requirement. Additional information regarding how best to measure source code will be provided on Code.gov.</p>

<p>Although the minimum requirement for OSS release is 20 percent of custom-developed code, agencies are strongly encouraged to release as much custom-developed code as possible to further the Federal Government’s commitment to transparency, participation, and collaboration.</p>

<p>OMB expects all agencies to satisfy the requirements of this pilot program without exception. Agencies should—as part of their selection of custom-developed code to be released as OSS—refrain from selecting code that would fall under the exceptions outlined in Section 6 of this policy. In the event that an agency’s CIO believes that the agency cannot satisfy the 20 percent requirement of the OSS pilot program (<em>e.g.</em>, because releasing code as OSS would create an identifiable risk to the detriment of national security), the CIO should consult with OMB.</p>

<p>Unless extended or supplanted by OMB through the issuance of further policy, the pilot program under this sub-section will expire three years (36 months) after the publication date of this policy; however, the rest of the Federal Source Code Policy will remain in effect. No later than two years after the publication date of this policy, OMB shall evaluate pilot results and consider whether to allow the pilot program to expire or to issue a subsequent policy to continue, modify, or increase the minimum requirements of the pilot program.</p>

<p>Within 120 days of the publication date of this policy, OMB shall develop metrics to assess the impact of the pilot program. Additional information on these topics will be available on Code.gov.</p>

<h3 id="participation-in-the-open-source-community">5.2 Participation in the Open Source Community</h3>

<p>When agencies release custom-developed source code as OSS to the public, they should develop and release the code in a manner that (1) fosters communities around shared challenges, (2) improves the ability of the OSS community to provide feedback on, and make contributions to, the source code, and (3) encourages Federal employees and contractors to contribute back to the broader OSS community by making contributions to existing OSS projects. In furtherance of this strategy, agencies should comply with the following principles:</p>

<ol type="A">
  <li><u>Leverage Existing Communities:</u> Whenever possible, teams releasing custom-developed code to the public as OSS should appropriately engage and coordinate with existing communities relevant to the project. Government agencies should only develop their own communities when existing communities do not satisfy their needs. </li>
  <li><u>Engage in Open Development:</u> Software that is custom-developed for or by agencies should, to the extent possible and appropriate, be developed using open development practices. These practices provide an environment in which OSS can flourish and be repurposed. This principle, as well as the one below for releasing source code, include distributing a minimum viable product as OSS; engaging the public before official release;<sup id="fnr30"><a pageScroll href="#fn30">30</a></sup> and drawing upon the public’s knowledge to make improvements to the project.</li>
  <li><u>Adopt a Regular Release Schedule:</u> In instances where software cannot be developed using open development practices, but is otherwise appropriate for release to the public, agencies should establish an incremental release schedule to make the source code and associated documentation available for public use.</li>
  <li><u>Engage with the Community:</u> Similar to the requirement in the Administration’s Open Data Policy, agencies should create a process to engage in two-way communication with users and contributors to solicit help in prioritizing the release of source code and feedback on the agencies’ engagement with the community.</li>
  <li><u>Consider Code Contributions:</u> One of the 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 throughout the software development lifecycle. Communities help 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.</li>
  <li><u>Documentation:</u> It is important to provide OSS users and contributors with adequate documentation of source code in an effort to facilitate use and adoption. Agencies must ensure that their repositories include enough information to allow reuse and participation by third parties. In participating in community-maintained repositories, agencies should follow community documentation standards. At a minimum, OSS repositories maintained by agencies must include the following information:
    <ol type="i">
      <li>Status of software (<em>e.g.</em>, prototype, alpha, beta, release, etc.);</li>
      <li>Intended purpose of software;</li>
      <li>Expected engagement level (<em>i.e.</em>, how frequently the community can expect agency activity);</li>
      <li>License details; and</li>
      <li>Any other relevant technical details on how to build, make, install, or use the software, including dependencies (if applicable).</li>
    </ol>
  </li>
</ol>

<br />
<h4 id="footnotes">Footnotes</h4>
<ul class="list-unstyled">
  <li id="fn29"><sup>29</sup> The definition of “custom-developed code” can be found in Appendix A. <a pageScroll href="#fnr29">&#8617;</a></li>
  <li id="fn30"><sup>30</sup> For the purposes of this policy, an “official release” is a release that is not in the alpha or beta test phases and, in the field of computer programming, would typically be designated with a version number 1.0.
   <a pageScroll href="#fnr30">&#8617;</a></li>
</ul>