Skip to main content
U.S. flag

An official website of the United States government

Back to Blog

Facts about publishing open source code in government

At 18F, we believe that developing software in the open has many benefits, and we write about our open source work as much as we can. We get questions from other people in the federal government because they’ve run into legal and practical uncertainties when seeking permission to work in the open from their agency or team.

We’ve put together a list of facts and references that will help you build the case for open source development in your team or agency and bust myths about using public code repositories. This post is based on our experiences at the federal level, but we hope it’s helpful for anyone working in government.

Fact: Many parts of the federal government already approve use of public repositories for open source software development.

Myth: “Public repositories are an emerging technology without widespread government use. The people using them are probably not paying full attention to compliance.”

Developing in the open and using public commercial hosting services is an accepted practice in many agencies and offices of the federal government. For example, along with the General Services Administration (GSA) and the Library of Congress, over half of Cabinet-level agencies maintain sets of public code repositories, including Commerce, Defense (and combat support agencies like NGA), Education, Energy (57 including NREL), EPA, HHS, Interior (17 including USGS and NPS), Labor, OMB, State, Treasury, Agriculture, and the VA. To see 235 examples, visit this comprehensive federal GitHub dashboard created by our partners in GSA’s Office of Government-wide Policy. In our own work, 18F has collaborated with more than 25 federal agencies on open source projects in public repositories.

Some parts of government also use public repositories for collaboration on content with the public. For example, the White House Office of Management and Budget uses public repositories to gather public input on draft policies, including its Federal Source Code Policy. The National Institute on Standards and Technology (NIST) used a public repository to solicit feedback on public previews of draft guidance.

Fact: 18F and other federal teams publicly collaborate on code while complying with relevant federal policies.

Myth: “Agencies can’t release code on vendor-run repository hosting websites because it’s not compliant with what we’ve heard about federal requirements (for example: we don’t control the servers; everything on a .com domain must also be on a .gov domain).”

There are several teams across government that publish helpful documentation about their internal policies and practices for compliant open source development. For example, here are details about how 18F complies with relevant requirements in our work:

  • Our parent agency, the GSA, has a CIO Information Technology (IT) Integration Policy that supports publicly releasing GSA software as open source code. For more about GSA’s support of open source, see this list of GSA IT’s key initiatives and the GSA Open Source Framework.
  • 18F has a public open source policy and team practices that guide our development of open source code.
  • We use a public code hosting service with Terms of Service compatible with government use; other government-friendly Terms of Service amendments are listed here.
  • We comply with FISMA requirements by having all employee accounts and project teams configured in a standard way, as documented in the FISMA Ready project page here. Our new hire onboarding process outlines how to configure public repository accounts to that standard, and we have an employee handbook page that lists our public repository usage rules.
  • We only use open code repositories for information that is public (such as hosting our open source code) or would not be a problem if unexpectedly made public (such as a few non-public repositories with team planning information).
  • Specifically, we do not store sensitive personally identifiable information (PII), environmental configuration variables, or passwords on the service (also an industry best practice).
  • We regularly export our work to comply with recordkeeping requirements and to have backups if a public repository has problems.
  • We don’t endorse any vendors in our blog, website, and other internal and public materials.

Other agencies and teams publish documentation about their open source policies and guidelines, which can also inform your implementation. Here are some examples:

Fact: Public code services enable federal staff to fully control access and permissions for official repositories.

Myth: “Public repository hosting services are social networking tools with dubious collaboration features; using them would lead to our projects getting unreliable external code mixed into our official work.”

As an example, 18F’s staff controls and decides what code goes into our repositories. For almost all of our projects, we only allow the public to make suggestions to our official repositories (in the form of pull requests), and we carefully review those suggestions before deciding whether to accept them. We’ve also developed clear policies for work with outside-of-government collaborators, guided by FISMA Ready standards.

Fact: Agencies that do classified work can release code that isn’t sensitive.

Myth: “All of the code we develop is sensitive and protected by security exceptions. It can’t be released in the open.”

There are several agencies that do classified work and release code that isn’t sensitive. If your agency or team works with sensitive information and has concerns about releasing any code, we’d suggest investigating whether you have a blanket policy for all code. For example, these agencies deal with classified work and still share some non-sensitive code publicly:

Fact: The White House considers open source software a priority for its open government efforts. Releasing code publicly provides several benefits to agencies.

Myth: “Releasing open source code is not a priority. Our current closed-source practices are fine.”

Just today, the White House released its federal source code policy (PDF link) that requires agencies to begin developing policies that will require releasing a portion of custom-developed code as public open source. In other words: most agencies will be required to do some open source work, so it’s helpful to start work on this soon. Prior to this, the federal government built many important projects using open source code. The Consumer Financial Protection Bureau built an open source tool using open data from the Department of Housing and Urban Development to find nearby free housing counselors for those struggling to make mortgage or rent payments. 18F and the Presidential Innovation Fellows built notalone.gov to help survivors of sexual assault can find resources and data. The College Scorecard and its underlying data API were also all built with open source code.

Here are a few federal explanations of the benefits of open source development:

  • The federal source code policy discusses how code reuse can have significant benefits for American taxpayers, such as reducing vendor lock-in, decreasing duplicative costs for the same code, and increasing transparency across the federal government.
  • The 18F open source policy explains important benefits including rapid prototyping, easy collaboration, community involvement, peer review, cost savings, and reusability.
  • 18F’s Partnership Playbook explains why we work in the open with federal partners and how our projects benefit from the open collaboration.
  • The United States Digital Service created the Digital Service Playbook, which includes the best practice of defaulting to open.

Fact: There are supportive resources available for federal teams who want to start working in the open.

Myth: “Our team can’t use a commercial code hosting service without unreasonable effort. I’m not allowed to even contribute to a different agency’s repositories.”

  • It’s free to open public repositories on some platforms.
  • Some public repositories have federally compatible Terms of Service. Our colleagues in the Technology Transformation Service can work with your agency to find open source code sharing services that have Terms of Service that work for your agency.
  • Somebody at your agency might have already given somebody else at your agency permission to use the service. Try checking to see if your agency already has a presence on a public repository hosting service. If you don’t see an example use case, we’d suggest reaching out to someone with appropriate authority to release information, such as the head of Information Resources. We’ve learned that every agency is different; the specific path to using public code repositories may vary.
  • If you run into restrictions from your agency on participating in public government projects on repository hosting services, you can reach out to the Office of the Federal CIO.
  • If you’re trying to help your government team start working in the open but are running into barriers, you can reach out to us at 18f@gsa.gov. We’d like to help you if we can, such as by answering a specific question.

We hope this is useful. Please open an issue if you have another question, and make use of our repositories as much as you want!

Related posts