The first stage of engaging with open source is typically to use the software. As explained, there are two main categories of users, (1) end-users and (2) distributors.
- End-users worry about using quality software that, for example, will be maintained for a sufficiently long time and is not riddled with vulnerabilities.
- Distributors in addition to worrying about software quality also worry about fulfilling the open source license obligations of the code they are incorporating in their products.
An open source program office (OSPO) supports the employees of the company in making the decision which open-source software to use and which not to use. Support can range from advising what to use to outright forbidding the use of a particular open-source software.
The associated workflows can get laborious and grow in volume quickly. Efficiency is key. To this end, most OSPOs, based on the dominant business models of the company, will provide initial guidance to developers searching for open-source software to use. The following matrix shows how open-source software can be prequalified as allowed, must-ask, or verboten. Software that falls into the allowed category is likely to be allowed for use in projects and products, software that falls under must-ask will likely trigger stringent review and resolution, and software that falls under verboten is unlikely to be allowed at all.
| Allowed | Must-ask | Forbidden | |
| Software | SQLite | glibc | CoreNLP |
| By license | MIT | LGPL-2.0 | AGPL-3.0-or-later |
| By origin | github.com/google | github.com/random | Stackoverflow |
Employees who would like to use open-source software that passes this filter will then have to feed it into an approval process operated by an open source review board (on behalf of the OSPO). The review board typically consists of experts from the program office and other parts of the company.
In a comprehensive approval process, the review board will perform a thorough analysis of the open-source software to understand what’s in the package. The two main aspects of interest are code quality and software licenses.
- To review software quality, the review board or selected members will run metrics tools on the code and the community to get an indicator of their quality and longevity. Example indicators are number of outstanding bugs, mean time to bug fix, and diversity and size of the project community.
- To review the software licenses, the review board will run software composition analysis tools to identify the licenses in the code (which may be different from the licenses declared by the developers). Often, developers name one primary license, while actual code has been composed from code of many different licenses over time.
The review board makes a recommendation or casts a decision based on these findings and the use of the open-source software is approved or rejected. The review of licenses of incoming open source code is also often called the inbound licensing process.
For actual use of the open-source software in projects and products, the software together with the results of the review process should be put into an open-source software management system for retrieval when building software inside the company. A company should never pull open-source software straight off the web into their projects and products: It should only use reviewed, approved, and managed versions of the software from a trusted system. Otherwise it significantly increases the risk of falling prey to software supply chain attacks.
© 2024 Dirk Riehle, used with permission.
Next up: Contributing to open source projects