1. We build in the open

18F works in the open from day one of a project, and our resulting code is dedicated fully to the public domain. In addition, any contracts 18F enters into where others will develop software on 18F’s behalf ensure that all results are dedicated to the public domain. For our international colleagues, 18F also permanently waives all copyright and related rights worldwide to code created by 18F or its contractors.

We operate in this way for three reasons:

  1. Operating in the open streamlines communication. GitHub issues can be used without concern about access permissions and account creation. Access to the project is available regardless of VPN or location, without additional verification requirements. Open source repositories are an easy and accessible location to find source code when pulling in additional experts to check out a problem.
  2. Transparency builds trust with the public, since everyone’s work is accessible to others. Transparency also builds trust within the government, since we can freely pull and cite methods and ideas from existing projects without worrying about possibly revealing something inappropriate.
  3. Working in the open helps to encourage good documentation and coding practices. Everyone is aware of and following processes for open information from day one. There is no just-before-launch, last-minute review of everything. All code and documentation is reviewed as it’s developed.

What does this mean for you?

Your tools will be developed in public view. While our open source policy explicitly covers software, 18F also publishes much of its designs, product discussions, and other artifacts in the open as a matter of policy, principle, and working preference. This fosters a working environment that is more conducive to outside feedback and contributions, and increases operational awareness of the work across our project teams and those of our partners. In one example, we and a partner office at EPA successfully opened a project’s internal task management tool to public view.

The public will be able to examine the code, point out issues, and suggest edits (all edits must be accepted by authorized personnel on the 18F or partner agency team). While they aren’t guaranteed, we celebrate public contributions to our code. Interest groups may take note of the developing project once it is publicized.

Additionally, we will write about the work (or the process used to create the work) in public blog posts, case studies, or other means (social media, etc). Communicating openly is a critical process that we’ve put in place to stop the government from repeating the same mistakes. Not sharing solutions and best practices — both between different teams inside the government and between the government and private sector — has led to financial waste and damage to the public. We need the ability to communicate solutions as fast as we find them, and the most effective way to do that is to work in the open.

How do you know if you’re ready to work in the open?

As you consider working with 18F, reflect on the following questions with your stakeholders. You may not be able to answer “yes” to each one, but they can help serve as indicators of potential conflict points that may need to be resolved before we partner. If any of these look like red flags to you, please raise them right away with your 18F point of contact and we’ll work together to address them.

  • Are you already working in the open or using open source products?
  • Have you and your IT department discussed developing your project with open source?
  • Has your agency developed other projects using open source code?
  • Have you taken a look at 18F’s GitHub repositories to become familiar with how open source projects look? (Example 1, Example 2, Example 3)
  • Have you talked to your communications team about how you plan to announce and promote the project?