Use of Existing Tools
When developing software solutions, teams should prioritize the adoption of well-established, community-supported, and actively maintained open-source libraries and tools. Preference should be given to projects licensed under the MIT License or similarly permissive open-source licenses.
Developers are strongly discouraged from using packages that exhibit any of the following characteristics:
Staleness:
The package has not received updates or releases within the last 18 months.Unresolved Maintenance Issues:
There are multiple open issues or pull requests that have remained unaddressed for more than 6 months.Low Community Adoption:
The library is not widely used, lacks contributor activity, or has limited community trust.
When evaluating open-source libraries on GitHub, developers should review:
- Number of stars (popularity)
- Number of forks (adoption & experimentation)
- Frequency of commits and releases
- Quality of issue and pull request responses
- Contributor activity and maintainer engagement
Use of Closed-Source or Proprietary Tools
Closed-source, proprietary, or commercially licensed tools must not be used without prior internal approval. These tools may introduce operational, financial, or security risks and must be reviewed accordingly.
If a valid technical or business need requires the use of a closed-source library, framework, or SDK:
- A justification must be prepared.
- A preliminary assessment must be completed (security, licensing, supportability).
- Approval must be obtained from:
- the Head of Digital Development, and
- the Head of DevOps.
No closed-source dependency may be introduced into any DIT software system without this explicit, pre-approved process.
By adhering to these principles, we ensure that DIT systems remain secure, maintainable, cost-effective, and aligned with best practices from the global open-source ecosystem.