This post originally appeared on my blog
Welcome to this four-part mini-series on open-source best practices. In this series, we will discuss the best practices for adopting open-source software (OSS) into your organisation, managing OSS dependencies daily, fostering collaboration with the OSS community, and finally, my opinion on which best practices are best adopted for organisations of all sizes and industries.
The second and third parts are already readily available on my website here.
This article will discuss the best practices for adopting open-source software, including the internal considerations organisations must make, the metrics to judge the quality of OSS components, the approval process, and the licensing of OSS components.
Introduction
Open-source adoption includes the strategic and tactical considerations of introducing open-source software to your organisation. A robust adoption process is critical to ensuring new open-source components are correctly evaluated before being integrated into the organisation’s systems.
This article lists all the general best practices for adopting OSS. It is by no means an opinion piece.
OSS Policy
An OSS policy is a formal document that outlines the rules and guidelines for using open-source software within an organisation.
Our literature review found an OSS policy to be a recurring theme in the best practices for adopting open-source software. Best practices recommend that organisations have a formal OSS policy in place.
An OSS policy should (Hammond, 2009);
- Be concise
- Developer consumable
- Involve general counsel early and often
- Classify OSS license types
- Take control of the process
- Measure internalisation
- Be revisited and revised on a regular basis
It should include the goals for OSS adoption, the acquisition process, the rules for the business case, and guidelines for the appropriate use of OSS (Hammond, 2009).
Lacking a formal policy for OSS usage and adoption, which typically includes licencing guidelines, can lead to legal and security risks (Schofield, 2008).
However, a policy alone is not enough. It is essential to ensure that all employees understand and follow the policy. Most importantly, the policy steps should apply to the organisational context (Osborne et al., 2023).
Open-source policies are a formal way for an organisation to set guidance and rules for using open-source software. As we will see later, most developers use their own discretion rather than a formal organisational process, which can lead to inconsistencies and licensing risks.
A policy is an excellent way for an organisation to ensure that all developers are following the same process, the correct stakeholders are included in the adoption process, and that the process is tailored to the organisation’s needs.
Maturity Models
Maturity models are a way to evaluate the quality of open-source software components. They can play a key role in the adoption process, as they allow for evaluating OSS components before they are integrated into the organisation’s systems. We found that there are several maturity models for evaluating OSS components; however, there wasn’t a consensus on which model was the best.
Fundamentally, the adoption of OSS components differs from the adoption of proprietary software due to the fact OSS is stored in public repositories, accessible by anyone, and is often developed by a community of developers (Umm-e-Laila et al., 2016). Due to this, the quality of open-source software can be very different from one product to another; therefore, evaluation methods have been developed to evaluate OSS components properly.
The most popular OSS evaluation methods are the Capgemini-Open Source Maturity Model (C-OSSM), Navicasoft-Open Source Maturity Model (N-OSSM), Qualification and Selection of Open Source (QSOS), Open Business Readiness Rating (Open BRR) and Easiest Open Source (E-OSS) (Umm-e-Laila et al., 2016).
None of those interviewed were familiar with these models, let alone using them in their organisation. This suggests that these models are not widely used in practice. We also found, from our literature review, that there is no consensus on which model is the best, with Umm-e-Laila et al., 2016 going as far as to say that “in order to take advantage of OSS properly, it is recommended to propose a new framework/model that will eliminate the weakness of all models.”.
We can conclude that while maturity models are an excellent way to evaluate OSS components, there is no consensus on which model is the best, and they are not widely used in practice. From our interviews, we found that most developers judge the maturity of OSS components based on their own discretion, usually stemming from their own experiences and the experiences of their colleagues.
Trust in Open-Source Software
Trust in OSS is a critical concept when adopting OSS components. How does one come to trust an OSS component? More often than not, “there is no sound basis for trust in the Software Ecosystems (SECO) hubs”, with trust being considered “founded or unfounded” (Hou et al., 2022).
Trust is subjective and based on the end-developer’s perception and intrinsic and extrinsic motivations. When adopting a new OSS component, the developer will consider intrinsic factors such as:
- Source code
- Reliability
- Security
Extrinsic factors such as:
- Documentation
- Structural assistance
- Cost
Quality is the most discussed factor in trustworthiness, with most developers considering the quality of the OSS component as the most critical factor in trustworthiness (Hou et al., 2022).
From our literature review and the interviews, we found that each developer uses their own trust model and that there is no documented process for evaluating the trustworthiness of OSS components within an organisation.
Outside of academic papers, trustworthiness wasn’t mentioned in any of the best practices we reviewed.
This is a significant gap in the best practices landscape, as trust plays a vital role in adopting OSS components.
Approval process
The approval process is a formal process for evaluating and approving OSS components before they are integrated into the organisation’s systems. It’s an opportunity for the organisation to evaluate the OSS component and ensure that it meets the organisation’s needs and standards, and engage relevant stakeholders in the approval process.
When adopting OSS, there are several “deal-breakers” that can prevent the adoption of an OSS component. Outlined by Spinellis, 2019, these include:
Lacking functionality
Incompatible license
Nonfunctional properties
Businesses should approve OSS based on technical needs, licensing, longevity, and business factors like cost and benefits. Yet, businesses must balance risk with commercial advantages and be willing to adapt their methods quickly. The approval process should be formal, with a clear set of guidelines and rules, and should be managed by a central team and engage relevant stakeholders (Butler et al., 2022).
When selecting an OSS component, ensure it demonstrates the following security and maintenance best practices (Department of Defense, 2022):
Detection Tool Usage: Actively employs detection tools within its integration pipeline and externally.
Vulnerability Reporting Transparency: Has a clear process for the open reporting and documentation of security vulnerabilities.
Security Review History: Possesses a record of security reviews.
Cybersecurity Testing: Undergoes regular cybersecurity assessments, notably third-party audits, to verify security measures.
Issue Resolution: Demonstrates a commitment to promptly addressing and resolving reported issues.
Timely Vulnerability Remediation: Shows a track record of quickly remedying vulnerabilities.
We found that an approval process was a recurring theme in the best practices for adopting open-source software. Every interviewee demonstrated some approval process for the adoption of OSS components. Smaller companies tended to build a minimal viable product (MVP) with the OSS in question; larger teams had a multistep process that involved multiple stakeholders.
The US Department of Defense, 2022 recommendations primarily emphasise the quantifiable attributes of OSS dependencies, including security features and measurable performance metrics. In contrast, Butler et al., 2022 analysis portrays the approval process as somewhat ambiguous, describing it as more reliant on assessment and discretion than on strict, predefined criteria.
To conclude, the approval process for adopting open-source software is dynamic and customised to each organisation’s specific requirements, yet it remains a universally acknowledged standard that all entities conform to.
Software Bill of Materials
Software Bill of Materials (SBOM) is a formal list of components used in a software system. It allows for tracking OSS components and their dependencies, which is essential for managing the security and compliance risks associated with OSS.
Since 2018, SBOMs have surged in popularity, driven in part by a collaborative effort headed up by the American National Telecommunications and Information Administration’s (NTIA) multi-stakeholder process (National Telecommunications and Information Administration, n.d.). This work culminated in the US government’s issuance of an executive order mandating the use of SBOMs in all federal software (The White House, n.d.) in direct response to the SolarWinds supply chain attack (Schwartz, 2021).
The two primary standards for SBOM are SPDX and CycloneDX.
SPDX17 is an open standard developed by the Linux Foundation to communicate details of a SBOM, including components, licenses, copyrights, and security references, recognised internationally as ISO/IEC 5962:202118 (System Package Data Exchange (SPDX®) 2024). CycloneDX19, originating from the Open Web Application Security Project (OWASP) community, is an SBOM standard crafted for application security and supply chain component analysis, now extended to encompass a broader array of applications such as software-as-a-service BOM (SaaSBOM) (CycloneDX 2024).
Both formats are popular, yet organisations are advised to select the format that most aptly meets their specific requirements (Alvarenga, 2023a).
At a minimum, an SBOM must contain three categories (United States Department of Commerce, 2021);
Data fields Data fields must be standardised and contain essential information on each component for effective tracking and management. The aim is to ensure these components can be easily identified throughout the software supply chain, linking them to other valuable data sources (United States Department of Commerce, 2021). Naming conventions should try and follow the guidance outlined by NTIA Multistakeholder Process on Software Component Transparency Framing Working Group, 2021.
Automation Support Automation support is essential for the effective use of SBOMs, as it allows for the automatic generation and updating of SBOMs, which is essential for managing the large number of OSS components used in modern software systems.
The data formats that are being used to generate and consume SBOMs are:
Software Package Data eXchange (SPDX)
CycloneDX13
Software Identification (SWID) tags
Practices and Processes Practices and processes are essential for the effective use of SBOMs, as they allow for the effective management of OSS components and their dependencies, necessary for managing the security and compliance risks associated with OSS.
There are two elements that should be explicitly stated in the SBOM:
Frequency – When a software component is updated or new information about its components is discovered, the supplier must issue an updated SBOM to reflect these changes (United States Department of Commerce, 2021).
Depth – An SBOM must include all primary components and their transitive dependencies, ensuring top-level dependencies are detailed enough to identify all subsequent dependencies recursively (United States Department of Commerce, 2021).
Licencing
The licensing of OSS components is a crucial consideration when adopting OSS as it can significantly impact the organisation’s ability to use the OSS component and considerably affect the organisation’s ability to distribute the software that uses the OSS component.
As of 2022, 78% of open source components are under permissive licenses, which allow users wide freedom to use, modify, and distribute the software, with minimal requirements on how it can be redistributed. Meanwhile, copyleft licenses, which require that any modified versions of the software also be distributed under the same license terms, make up the remaining 22% of open source components (Murray, 2022).
The Apache License is the most popular OSS license, with 30% of all OSS projects using it (Murray, 2022).
Larger organisations (>5000 employees) are more likely to have an internal legal team familiar with OSS licensing when compared to small organisations (100 employees) 31.46% vs 22.30%, respectively (OpenLogic, 2023).
To help reduce the risk of legal problems arising with the use of open-source software (Mathpati, 2023), organisations should watch over all open-source code being brought into the organisation, ensuring that licence requirements are met. To achieve this, there are several tools available, such as (The Linux Foundation, 2024):
Black Duck Protex – A fee-based tool for license compliance and open source management.
Copyright review tools – Command line utilities for copyright file management.
FOSSA – Automates code dependency tracking and license compliance.
FOSSology – An open-source toolkit from the Linux Foundation for license compliance featuring a web UI for compliance workflows.
Managing the licensing of OSS components is a key consideration when adopting OSS. Large organisations often have the advantage of an internal legal team to navigate open-source software (OSS) licensing, a resource that smaller organisations lack. Therefore, relying on internal legal teams for OSS license management cannot be deemed a universally applicable best practice, as it disadvantages smaller entities. The easiest way to manage your OSS licensing is to use a tool that can automatically track and manage the licensing of OSS components, as outlined by The Linux Foundation, 2024.
Conclusion
In this article, we have discussed the best practices for adopting open-source software, including the internal considerations organisations must make, the metrics by which to judge the quality of OSS components, the approval process, and the licensing of OSS components.
The adoption of open-source software is a complex process that requires careful consideration of the organisation’s needs and the OSS components being adopted. Having a robust adoption process is critical to ensuring that new open-source components are correctly evaluated before being integrated into the organisation’s systems.
We can see that the current literature is broad and extensive, with many different opinions on the best practices for adopting open-source software. However, there are some recurring themes, such as the need for an OSS policy, the importance of an approval process, and the need to manage the licensing of OSS components.
We hope that this article has provided you with some valuable insights into the best practices for adopting open-source software and that you can use this information to improve your organisation’s OSS adoption process.
Top comments (0)