In the past, developing all software internally was a point of pride. Today, the complexity of modern software, coupled with the pressures to release products on tight deadlines, has made delivering projects that rely exclusively on internal code development almost impossible.
Related Articles
- Avoiding Enemies And Making Friends Using Embedded Open Source Software
- Open-Source Software Is Stealing Your Business
- Open-Source Hardware Opens New Opportunities
Increasingly, organizations are turning to commercial third-party code, brought in from outsourcers and contractors, and open-source software (OSS) to accelerate development and reduce development costs. Along with the advantages realized by using third-party code, a few challenges can arise. Governing the quality, security, licensing, and other intellectual property (IP) attributes is imperative to avoiding the risks and potential downstream costs of using third-party software. The process of managing third-party content in a code base can be time-consuming and resource intensive.
This file type includes high resolution graphics and schematics when applicable.
Picture a hypothetical single-product organization of less than 200 people. It releases a new version of its product three times per year and plans to make at least $1 million in revenue from each release. Factors to consider include the amount of time spent for each release on cataloguing the elements of the code portfolio, identifying the attributes of the OSS and other third-party components, and their level of compliance with internal policies.
The Effort
The first step in managing OSS content is to understand what third-party content exists within the code base in the first place and identify its licensing attributes. This is called creating a bill of materials (BoM) for the portfolio, and it is typically accomplished through a manual audit or automated scanning of the code base. This stage typically takes two to five person-days to complete.
After all of the licenses in the code base have been uncovered, it’s time to determine each license’s associated obligations, which typically is done in consultation with a licensing expert. 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. The terms of certain licenses can be contradictory, so checking the compatibility between the licenses will take roughly half a day 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 person-day and 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 in another technology group in the software food-chain (e.g., a protocol stack delivered to a communications chip vendor in the case of a mobile device), then the customer may ask for various reports on the composition of the software, IP ownership, existence of the OSS and third-party code, and its license requirements. This step generally takes between half a person-day to two person-days to complete.
The Cost
The tasks described so far take seven to 19 person-days per release. These estimates may be optimistic and the actual effort involved will mostly likely be higher. Depending on which part of the world this hypothetical organization operates in and the prevailing loaded labor rate, we can translate the effort into dollar value. The assumed three releases could mean anywhere from $9000 to $10,000 in North America, or $3000 to $10,000 in India, will be spent on managing the third-party content (see the table).
During the process of building the BoM and checking the licenses, export control obligations, and security vulnerabilities, invariably 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 $5000 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.
Managing The Cost Of Third-Party Code Adoption
Obviously, the use of OSS should not be avoided based on the costs above. But there are steps that organizations can take to mitigate these costs. A structured OSS adoption process can be put into place with policies that dictate which OSS packages are acceptable for use in the organization. A structured OSS adoption process typically includes:
• A systematic assessment of the practice of bringing and using third-party code leads to a process that ensures policies are in place to minimize the back-end effort and that those policies are adhered to. A structured open-source adoption process (OSSAP), for example, helps with identification of stakeholders in an organization, definition of policies, and communication of policies within the product group.
• Many of the tasks required for identifying and managing the third-party code can be automated. Policies can be defined and captured digitally, software packages can be pre-approved by properly using an automated workflow solution, the discover process can be reduced by many orders of magnitude, and license obligations and license compatibilities can be tabulated using automated code analysis and open-source software license management solutions.
• Full integration of these automated solutions with the organization’s tools (for example, integration with the libraries and build environments) are possible, so to a large extent all of the above activities can be carried out automatically and transparently. Further, the automated solutions can raise red flags if an unknown code that violates the organization’s policy finds its way into the final product.
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 ensure obligations are met and vulnerabilities are eliminated.
