Using 3rd-party open source products
In order to make effective commercial decisions, it is important to recognise the characteristics of open source software that we find desirable. These include:
- Avoidance of vendor or proprietary ‘lock-in’.
- Flexibility of customisation.
- Faster and more transparent patching and security fixes.
- Highly cost effective.
- Common convergence on standards.
- Transparent record of development.
However, many organisations ‘open’ their code, but monetise the software through means that restrict the freedom of the user. Some open source software does not have a strong community, and can be risky to use should problems arise which the DfE does not understand how to resolve.
Criteria for identifying truly open-source products
Each of these criteria should be considered for the product in question. If it doesn’t meet any one of them, you should understand what risks that presents and consider if that risk is acceptable.
The code is maintained by a mature, diverse community
If the code for the product you’re evaluating doesn’t have an active community working on it, the software presents a sustainability and security risk to the DfE.
There is no established method for assessing the maturity of open source communities, however factors to consider include:
- The activity of its contributors and contributions (regular commits)
- Healthy throughput for issues
- The patterns of its release history
- Active discussion lists
- The health and diversity of its community of users
- Trust established through longevity of use
- The ecosystem it belongs to (other projects/products being built using the code)
The responsiveness of the community to emerging security issues is acceptable, given the context of use
If the open source code is used for a critical security function, the community must be very responsive to emerging vulnerabilities. Equally, a much slower response is acceptable for non-critical code libraries.
Responses should include healthy discussion of the severity/validity of a given issue, and timely fixes for vulnerabilities which are deemed to be serious.
A broad community supports users of the product outside official forums
Without community engagement, we are reliant on support through the vendor. This usually means that we should consider the product as a commercial product, and evaluate it alongside others with licensing and support costs.
Multiple independent suppliers offer commercial support for advanced use
Truly open source products are surrounded by ecosystems of independent suppliers that are able to offer support. Without such an ecosystem, we risk getting locked in to uncompetitive support contracts depending on single suppliers.
No closed source extensions or plug-ins are required for normal operation or scaling
Truly open source products don’t require the purchase or licensing of closed source extras to operate at scale. If products can only be operated at scale by purchasing closed-source plug-ins, this could introduce commercial implications over time.
Other Considerations
GDS guidance on choosing technology and the technology code of practice should also be considered.