When a module is released under an open source license on Github, other people can submit improvements and fix bugs to the code.
This approach is beneficial to the person who built the module and to other people who are using it. But it does require the owner of the module to respond to community requests and maintain the module. In some cases, agencies are not resourced for this operational work, but there are a number of options available to an agency that wants to share code.
This approach allows you total control over community contributions to your module. People can submit changes (pull requests) and your developers review the code changes and decide whether they want to bring them into your code (the trunk). So there is a resourcing implication for this approach.
If other people are using your module then there is responsibility on you, the owner, to review pull requests and keep improving the module. If you stop maintaining a module, then other people can publish a new module based on your code, so it’s not the end of the world.
If you think it’s a module that other agencies would be keen to use, then you can raise it in the co-funded development pool backlog. The backlog items get prioritised for development every 3 months. If it gets picked it will become a CWP supported module, will be publically with an open source licence, and SilverStripe will manage the maintenance work. But this depends on whether it is a priority for other agencies, so it might take a long time or never get picked at all.
Many web companies are already active contributors to the open source community. They might see value in taking on the ownership of the module and managing contributions. Alternatively you could agree a commercial arrangement, where they would review, accept and test pull requests, and apply the improvements to your website’s using the module.
You can choose to share code with a participating agency, without open sourcing the code. This will still reduce spend across government. The simplest approach would be to give them read-only access to your Gitlab project, and they could copy the code and reuse it as they see fit. You wouldn’t be able to accept contributions back to fix things, and so you wouldn’t maintain the module for the other agency. The benefits of this approach are limited and working out what interesting modules agencies have in their private repositories is a challenge, so open sourcing is much better approach overall.