Organizations are increasingly turning to commercial third-party code, code brought in from outsourcers and contractors, and open-source software (OSS) to accelerate development and reduce development costs. While there are immediate advantages realized by using third-party code, there are also several challenges that can arise: governing the quality, security, licensing and other intellectual property (IP) attributes are imperative to avoid risks and potential downstream costs of using third-party software. Additionally, the process of managing third-party content in a codebase alone can be time-consuming and resource intensive.

This article will look at the costs (in terms of person days and dollars) associated with managing third-party code in a hypothetical single-product organization of less than 200 people. Let’s say that the organization plans to release a new version of its product three times per year, and plans to make at least US$1 million in revenue from each release. It will be necessary to factor in the amount of time spent for each release on cataloguing the elements of the code portfolio. We’ll also look at the cost associated with fixing potential third-party quality or compliance issues as well as the revenue lost while fixing those problems.

The effort to manage open-source software content
The first step in managing OSS content is to understand what third-party content exists within the codebase, and to identify its licensing attributes. This is called creating a “Bill of Materials” (BoM) for the portfolio, and is typically accomplished through a manual audit or automated scanning of the codebase. This stage typically takes two to five person days to complete.

After all of the licenses in the codebase have been uncovered, it’s time to determine each license’s associated obligations. Depending on the variety of the licenses, the complexity of the language associated with these licenses, and how the corresponding code is used and distributed, this step could take one to three person days to complete.  

Depending on the end application, there may be a need to check for known security vulnerabilities in the software components used in the portfolio. Further, many jurisdictions have certain export control rules that require software that includes encryption functionality to be declared. These tasks can take between one to three person days each.  

Finally, OSS licenses have attribution clauses that require the actual text of the license to be included in the product that uses the OSS code. If the software is delivered to a customer who is in another technology group in the software food chain, then the customer may ask for various reports on the composition of the software. This step generally takes between one to two person days to complete.  

Associated costs on the rise
The tasks described so far take seven to 19 person-days, per release. These estimates may be optimistic, so it would be safe to assume that the actual effort involved will most likely be higher. Depending on which part of the world this hypothetical organization operates in, as well as the prevailing labor rate, we can translate the effort into dollar value. The assumed three releases could mean anywhere from $9,000 to $20,000 in North America, or $3,000 to $10,000 in India will be spent on managing the third-party content.

During the process of building the BoM and checking the licenses, export control obligations and security vulnerabilities, it’s quite possible that an issue will be uncovered that needs to be fixed. That means potentially delaying the product release, and based on expected $1 million revenue, losing $5,000 of revenue every day the product shipment is delayed. And if an issue is uncovered after the product is shipped, then costs will really skyrocket.

The use of OSS should not be avoided based on the costs above, as the costs of shying away from leveraging OSS in a technology organization far outweigh that of managing the third-party code effectively. In the race to deliver products at a faster pace and reduced development cost, a structured OSS adoption process can be put into place with policies that dictate which OSS packages are acceptable for use in the organization. This will ensure that obligations are met and vulnerabilities are eliminated.

Lacey Thoms is a technical blogger at Protecode and has written many articles on open-source software management.