Implementation guide for the Standard for Public Code

Code in the open This criterion in the Standard for Public Code

Share generously about your work and radiate your intent.

The Welsh Land and Property Data publish open weeknotes from their development team, this is a great way of communicating what you are working on.

The course Teaching Public Service in the Digital Age has a unit on Working in the open, which is a thorough resource with plenty of further reading.

While not only covering open source tools, the site EU alternatives lists tools and services that are compliant with EU regulations, and many of them have a spirit of openness.

Requirements

All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible.

All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible.

Consider using a git service or self hosting a git repository. While this requirement is about publishing, to really enable collaboration, this should also be where you do your development. That is, you should preferrably not just mirror the code publicly since that will make it harder for everyone (you included) to get an overview of the ongoing work.

  • GitHub: +largest community, +free for FOSS codebases, -cannot be self-hosted, -possibly GDPR-problems, -not FOSS
  • GitLab: +can be self-hosted, +free for FOSS codebases, -hosted version is not FOSS
  • Gitea: +can be self-hosted
  • Codeberg: (hosted Gitea)
  • Sourcehut: +can be self-hosted, -still in alpha
  • IEEE SA open: (hosted GitLab)
  • Bitbucket: -cannot be self-hosted, -not FOSS
  • Gitpod: (packing around other git services) +can be self-hosted

The codebase MUST NOT contain sensitive information regarding users, their organization or third parties.

Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published.

Tag releases so they can be found/checked-out from source control. Link old releases, make them easilly avialble for download. Publish releases before you start using them, or at the same moment if pre-publish is not possible for example a hot-fix in production.

Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL.