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.
Increasingly, organisations are 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. Along with the advantages realised by using third-party code, there are a few challenges that can arise. Governing the quality, security, licensing and other intellectual property (IP) attributes are imperative to avoiding 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.
The Hypothetical Organisation
As an example, this article will look at costs in terms of person days and dollars, associated with managing third-party code in a hypothetical single-product organisation of less than 200 people.
The organisation releases a new version of their 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 cost associated with fixing potential third-party quality or compliance issues and the revenue lost while fixing those problems will also be examined. The article will then detail ways to optimise this process to minimise the pain and maximise the benefits of using OSS and other third party content.
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 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 is typically 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 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 (for example, 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 0.5 to two person days to complete.
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 organisation operates and the prevailing loaded labour rate, we can translate the effort into dollar value. The assumed three releases could mean anywhere from £9-10K in North America or £3-10K 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, 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 £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.
Managing the cost of third-party code adoption
Obviously the use of OSS should not be avoided based on the costs above. Luckily, there are steps organisations 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 organisation. 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 minimise the back-end effort and that and those policies are adhered. 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 proper 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 organisation’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 organisation far outweigh that of managing the third-party code effectively. We have described some representative costs of managing outside code in a product. 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.
Lacey Thoms is a marketing specialist and blogger at Protecode (www.protecode.com) and has written many articles on open source software management. Lacey has a Bachelor’s Degree in Mass Communications from Carleton University. Follow @Protecode on Twitter.