We should aim to share all the modules with open source licences by default. But some code holds sensitive information, that should be kept private for security and privacy reasons.
You should keep a module private when:
It contains sensitive data or information
It presents a security risk to the website
Here are some considerations when deciding whether to keep your code private.
Information such as passwords, api keys or tokens cannot be shared. Keep these isolated and stored on an environment configuration file. When building, allow for dynamic configuration and for these values to be passed to the module from the configuration layer. This configuration layer is stored on the CWP and is per environment. This also allows you to have different settings on the testing server versus production.
The generic code for a feature should be kept in one module, more sensitive features can then be added to a private module or custom project code.
This is to make sure that if code contains features that can be shared are standalone to the parts of the feature that might hold information/data of a sensitive nature.
There may be cases where sharing publicly is not appropriate, but could still be reusable within government. You should still construct in the same way as sharable code, only the availability will be different. In this case, private modules can be stored on the CWP private code repository (GitLab) and still included into projects via the composer tool (with a slight variation to indicate private module use when deploying code on to the CWP).