Publish your code openly and use open source technology to improve transparency, flexibility and accountability.
To meet point 3 of the Technology Code of Practice your plan or design must show you have considered the use of open source and publishing your code openly.
You’ll have to explain how you’re meeting point 3 as part of the spend control process or any limitations you’ve encountered that prevented you from achieving this.
How open source differs to open standards
Open source is a way of developing and distributing software. The code is often written collaboratively, and it can be downloaded, used and changed by anyone.
Open standards are a set of rules designed to do a specific job in technology. They are also designed collaboratively and free to use. Open standards allow open source and closed source (proprietary) software to work together.
How using open source will help your programme
Give equal consideration to open source software when you choose technology.
Your technology project or programme could benefit from:
- solving common problems with readily available open source technology
- more time and resource for customised solutions to solve the rare or unique problems
- lower implementation and running costs
Be aware that open source software is not completely free, so take into account the total cost of migrating, including exit and transition costs.
How being open will help your programme
Publishing your code and data from the beginning of your technology project or programme will encourage:
- clearer documentation, making it easier for your team to maintain the code, track changes to it and for other people to use it
- cleaner and well-structured code that is easier to maintain
- clarity around data that needs to remain protected and how that’s achieved
- suggestions about how the code can be improved or where security can be improved
If your technology project or programme includes code in its development, refer to the Service Manual section on making source code open and reusable. There are times when it’s acceptable for code to be closed source. For example, keys and credentials, algorithms used to detect fraud and unreleased policy.
Using open source
The following questions are some of the points to consider when choosing technology and your preferred open source solution. These questions can also help if you are evaluating whether you want a proprietary or open source solution.
- Does the solution do what you need it to do?
- Does the solution meet the needs of your end users?
- What are the solution’s initial and ongoing costs?
- Will the staff need training or will expert users need to be employed to manage the solution?
- If the solution is open source, how widely is the code already adopted? How mature is it?
- Does the solution offer the level of support needed?
- How well is the solution maintained and is there evidence of further development?
- How reliable is the solution? This is hard to measure, but one way is to assess it by looking at its maturity.
- How well does the solution perform? Can you analyse performance data or reviews?
- How well will the solution scale to meet your needs?
- Does the solution’s security meet your needs and does it have regular security patches?
- Is the solution flexible? You can customise the solution to fully meet your needs but be aware this can make future updates and security patches hard to implement.
- Will the solution work with your other technology?
- Is the solution’s licence acceptable to your organisation’s business requirements? Are there any restrictions or gaps that would cause issues?
- Is the solution’s warranty acceptable and is there an option to buy one?
Related guides and sources
- Full list of related Technology Code of Practice guidance
- Open Source Initiative
- Choosing technology
- Making new source code open by default
- Ministry of Justice case study - why we code in the open
- GDS case study - making the register to vote code open
- 11 barriers to coding in the open and how to overcome them