Working in the Open

Working in the open means providing public access to your source code throughout its development. This leads to a better end-product by encouraging collaboration within and outside of DC government and allowing public feedback from day one.

A Word on Security

Security is a commonly voiced concern about open development. As DC government moves toward an “open by default” policy for its data, code, and content, it maintains that openness fundamentally improves security by making bugs shallow and encouraging strong coding practices. So long as a few key conditions are met, agencies should consider open sourcing their code and working in the open.

Open Source Checklists

Below are common scenarios teams may face as part of the Open Source Pilot. Use the relevant checklist to evaluate your situation. If you and your manager can say “Yep!” to each item, you should go ahead with your plans.

Even if you have doubts regarding a checklist item, it is still very likely you can proceed. Reach out to opensource@dc.gov for guidance.


Checklist: I am using GitHub to work on a new project in the open

My team is kicking off a new project and wants to develop in the open. I have ensured that:

  • The repository’s contents will be publicly releasable under an open license.
  • The project does not have a special categorical security sensitivity, such as including classified information.
  • The project or program manager agrees that the above conditions have been met.

Checklist: I am going to publish an existing DC Government project to GitHub

My team wants to make an existing codebase public for the first time. I have ensured that:

  • All personally identifiable information (PII), including private keys, tokens, passwords, IP addresses, and other authentication information has been removed from the codebase.
  • The licenses and contracts governing the project’s contents permit their public release.
  • The repository includes a README file with a clear project description. If applicable, these include installation instructions.
  • The repository includes a LICENSE file, which also notes the presence of any third-party code with different license requirements.
  • The project or program manager agrees that the above steps have been followed.

Checklist: I am reusing third-party code in a DC Government project

My team wants to reuse non-DC Government code, as in the case of forking a third party’s repository on GitHub. I have ensured that:

  • I understand the terms under which the source code base is licensed.
  • The source code base’s license permits modification and re-use.

Checklist: I am pushing or pulling code to an existing DC Government GitHub repository

I want to make incremental changes to my team’s public repository—a routine part of working in the open. I have ensured that:

  • All personally identifiable information (PII), including private keys, tokens, passwords, IP addresses, and other authentication information has been removed.
  • All of the commits’ contents are allowed to be released under the repository’s existing license.

Checklist: I am using GitHub to work on a new project in a private repository

Creating private repositories within DCgov is discouraged. If you believe you have a valid reason to do so, please send an email explaining the repository’s proposed contents and your requirement to opensource@dc.gov.

Close

Glossary of Terms

  • Commit

    Committing records changes made to a Git repository.

  • Fork

    A fork is a copy of someone else’s Git repository. You can make changes to your fork without affecting the original project.

  • Git

    Git is a popular free and open source system for tracking changes in text-based files. It is primarily used for software development.

  • GitHub

    GitHub is a web-based platform on which you can host and work on Git repositories. It provides a number of useful features, including bug tracking, feature requests, and task management.

  • Open Source

    In brief, open source licenses allow software to be freely used, modified, and shared. They abide by standards laid out in the Open Source Definition.

  • Personally Identifiable Information (PII)

    PII is any information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.

  • Private Key

    Private keys are a kind of PII used to decrypt messages sent over the Internet. They form part of a system called Public-Key Cryptography.

  • Push

    Pushing allows you to share the Git commits you have made with others.

  • Repository

    Repositories are places where a Git project’s files and their revision history are stored.

  • Token

    A software token can be used in two-factor authentication to authorize access to computer services.

  • Two-Factor Authentication (2FA)

    In two-factor authentication, two different components are used in combination to verify a user’s identity (e.g. a password and a single-use token sent to your email).