Missing: Use FOSS tooling
I'm missing information/recommendations in the Standard for Public Code to use Free and Open Source Software for developing public code.
I see often that the infrastructure for developing and hosting public code is proprietary software. It would be good to mention this topic in the Standard for Public Code.
We have two related requirements in Make the codebase reusable and portable:
- The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed software or services for execution and understanding.
- The software SHOULD NOT require services or platforms available from only a single vendor.
If they are not enough, do you have a suggestion for a change of either of them or a suggestion for a new requirement?
I would suggest something like:
- I would add that collaboration, communication and contributing to the code base MUST also be possible without the use of proprietary services.
To some more concrete examples:
- Standard for Public Code is hosted on a proprietary platform (GitHub).
- Some projects use proprietary communication platforms (e.g. Slack) for communication.
Since the Standard aims to collect best practices in government collaboration (in contrast to hypothetical bests), it would be great if we could point to a couple of projects doing this (mostly for documentation). Do you know of any outstanding role models?
- I would add that collaboration, communication and contributing to the code base MUST also be possible without the use of proprietary services.
I think I see your point. I tried to rewrite them in the form of how we usually formulate requirements in the Standard that I hope are inline with your thinking:
- Contributing to the codebase MUST NOT require the use of proprietary tools or services.
- Communication channels used by the codebase MUST NOT be proprietary tools or services.
I have split them to separate requirements, as that makes it easier to check if parts of it have been met (we have split many of the original requirements earlier). I struggled to come up with a good requirement for the general collaboration that would not also cover the first two.
If we choose to add them, they could fit in the criterion Make contributing easy. (But I still think we need some role models first.)
Regarding communication channels - I wonder if there is the risk of excluding civil servants - some government bodies restrict what their staff can use (eg only MS teams) and prevent them from installing anything on their machines.
Further I wonder about scope. Public code must be open because it involves the execution of governance and law. That's the mission of the Standard. Decisions about communication channels and collaboration tools may or may not be strictly essential to executing governance, and so might fall outside of the mission (particularly if it's fully portable).
So perhaps these should be encouraged but not hard musts?
Good points, Claus. The example given in the standard for communication channels is a mailing list, so nothing that anyone needs to install at all.
It might also be worth noting that in the implementation guide, all examples are FOSS.