Standard for Public Code

Bundle policy and source code →


  1. Requirements
  2. Why this is important
  3. What this does not do
  4. How to test
  5. Policy makers: what you need to do
  6. Management: what you need to do
  7. Developers and designers: what you need to do
  8. Further reading

Code in the open


  • All source code for any policy and software in use (unless used for fraud detection) MUST be published and publicly accessible.
  • Contributors MUST NOT upload sensitive information regarding users, their organization or third parties to the repository.
  • Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published.
  • The source code MAY provide the general public with insight into which source code or policy underpins any specific interaction they have with an organization.

Why this is important

Coding in the open:

  • improves transparency
  • increases code quality
  • facilitates the auditing processes

What this does not do

  • Make source code or policy reusable.
  • Make the codebase and the code within it understandable to as many people as possible.

How to test

The source for any version currently in use is published on the internet where it can be seen:

  • from outside the original contributing organization
  • without the need for any form of authentication or authorization

For each commit, reviewers verify that content does not include sensitive information such as configurations, usernames or passwords, public keys or other real credentials used in production systems.

Policy makers: what you need to do

  • Develop policies in the open.
  • Prioritize open and transparent policies.

Management: what you need to do

  • Develop a culture that embraces openness, learning and feedback.
  • Collaborate with external vendors and freelancers by working in the open.

Developers and designers: what you need to do

  • Clearly split data and code, in order to meet the requirement about sensitive information above.

Further reading