Study | 2012
FOSS Management
Study
1 Preface
. . . .
3
�
Executive Summary
. . . .
5
�
Overview
. . . .
9
3 .1 FOSS definition. . . .
9
3 .2 FOSS management. . . .
10
�
Survey Analysis
. . . .
13
4 .1 Stance towards FOSS in products
. . . .
12
4 .2 Reasons for using FOSS in products
. . . .
14
4 .3 Reasons for evaluating usage of FOSS in products
. . . .
15
4 .4 Reasons for contributing to FOSS projects
. . . .
16
4 .5 Reasons for leading and starting FOSS projects
. . . .
17
4 .6 Existing process governance
. . . .
18
4 .7 Supplier management
. . . .
20
4 .8 Support through process tools
. . . .
21
�
FOSS Management – Mitigate Risks and Maximize Cost Bene
fit
s
. . . .
23
�
Tool Based FOSS Management
. . . .
27
6 .1 Why govern the use of FOSS?
. . . .
26
6 .2 FOSS challenges
. . . .
27
6 .3 FOSS governance
. . . .
28
7 Summary
. . . .
30
8 Conclusion and Outlook
. . . .
31
Table of Contents
Every mechanical and electrical engineer knows that reinventing the wheel does not make sense in terms of cost, time-to-market and product quality . Thus, generations of engineers have been motivated to take advantage of reusing standard parts or assemblies wherever possible . Likewise, the manufacturing industry has implemented organizational structures, processes and IT-tools around the management of physical parts reuse .
The same should be true for software engineering regarding the deployment of Free and Open Source Software (FOSS) . As FOSS continues to gain traction as the foundation for increasing efficiency in software development, software engineers can reduce development costs for commodities and enable software engineers to focus on real innovation . FOSS can even be key to setting standards, which drives competitive advantage (e . g . Google’s Android) .
But gaining all the benefits of FOSS also requires well-defined governance and coordinated processes to manage the associated legal risks and hidden costs . Given the high impact FOSS can have on development efficiency, on the one hand, and risks and compliance issues on the other hand, it is astonishing that many enterprises have not yet considered their basic FOSS management framework as a high priority topic .
From the perspective of optimized product lifecycle management, we wondered why organizations weren’t prior-itizing FOSS management and wanted to understand more about the obviously missing awareness .
In this international study, we explore how enterprises in the European automotive industry presently perform FOSS management and discuss current and future trends and business drivers . This study further includes recom-mendations and best practices based on our consulting experience in this field . In addition, the survey provides a unique opportunity to benchmark an organization’s FOSS management policies against other enterprises and to determine potential areas for improvement . We hope this study will provide a holistic approach to establishing both an effective and risk-mitigating FOSS management process .
We would like to thank Prof . Dr . Dirk Riehle, head of the Open Source Institute at the University of Erlangen/ Nuremberg for his scientific guidance and Black Duck Software for sponsoring the study . Most importantly, all participants of the study for their highly valuable input . And we hope this study will shed some light onto what is increasingly becoming an important asset within all enterprises utilizing software in their development process, as well those acquiring or distributing software .
Dr . Alexander Krzepinski
BearingPoint, Partner Product Lifecycle Management
1 Preface
Software development is on the move . While over the years, traditional proprietary in-house development has
been losing significance, the trend towards extensive code reuse has been gaining traction . Of special interest and growing importance is the reuse of Free and Open Source Software (FOSS)1, which is freely and prominently
avail-able on the internet; in fact, according to Black Duck Software, as of January 2012, there were more than 570,000 projects across 5,300 sites using 2,100 software licenses, totaling more than 100 billion lines of Open Source code available . Android has gained popularity as a hot FOSS project, and now the automotive industry is following suit, shifting its traditional development paradigm towards embracing FOSS . The GENIVI Alliance, for example, is creating a platform enabling OEMs and their suppliers to commercially and strategically profit from FOSS in the In-Vehicle Infotainment (IVI) space .
Researchers have identified three stages of engagement with FOSS:
•
Sourcing (allowing FOSS code to be brought into a company)•
Contributing (giving back internal knowledge to FOSS projects)•
Initiating (setting up and managing FOSS projects)2BearingPoint conducted this study to gain insight into FOSS usage and FOSS management in the automotive industry, and found that the vast majority of surveyed companies are already deploying FOSS in product develop-ment . The extent of engaging with FOSS ranges dramatically across all three stages .
Companies usually start with sourcing and evolve towards initiating, while recognizing at the same time the additional benefits of being an active part of the FOSS community . The three main drivers for using FOSS in products are gaining competitive advantage, reducing development costs and avoiding lock-in to specific software
�
Executive
Summary
2 Alexy, Henkel: “Intraorganizational Implications of Open Innovation: The Case of Corporate Engagement in Open Source Software,”
vendors . Companies choose to contribute to FOSS projects because they can create standards, avoid maintaining a local and diverging version of the FOSS component and create an alternative to existing closed source solutions .
Social aspects such as being a good Open Source citizen or giving something back are not cited as relevant for
these decisions . The few companies that started or lead a FOSS project did so to infl uence projects, gain market advantage and reduce costs .
Although most responding companies have implemented processes for software development and requirements engineering, the processes governing the use of FOSS components can be called patchwork, at best . In fact, only a fraction of companies that have processes for using third-party components also have processes for using FOSS .
While the risks associated with using third-party components are essentially the same as those associated with using FOSS, the awareness of these two similar issues is entirely different . In fact, one fi fth of the respondents report that developers brought in FOSS without permission – proof developers turn to FOSS on their own .
Many companies check deliveries from suppliers against the contractually agreed upon specifi cations, but only a few require proof or challenge suppliers’ assertions . Only one quarter of the companies’ requests from the supplier include the disclosure of all integrated FOSS components .
Not even one participating company uses FOSS management tools that address all the required processes described in the following chapter 3 .2 – an alarming statistic, given the plethora of FOSS licenses and obligations that, due to their sheer complexity, can only be managed properly with comprehensive, automated tools .
We discovered a substantial gap between the current FOSS management practices in participating companies and what is considered necessary to effectively mitigate the business risks associated with FOSS deployment in products . However, we found good starting points allowing FOSS management maturity to be increased without
Today, Free and Open Source Software (FOSS) can be found everywhere . While desktop applications like Firefox and Open/Libre Office are visible and well-known, there is also significant FOSS penetration “under the hood” of commercial products . Android and GENIVI’s upcoming IVI platform demonstrates the increasing relevance of FOSS for the automotive industry .
3.1 FOSS definition
The Open Source Initiative (OSI) is commonly considered the steward of the Open Source Definition (OSD)3, and
the organization recognized for reviewing and approving Open Source licenses . OSI defines Open Source as “a development method for software that harnesses the power of distributed peer review and transparency process .” The most well-known attributes of Open Source are:
•
The source code is made available•
No license fees are charged for any usage pattern/purpose•
Its license allows for free redistribution•
Its license allows for modifications and extensions3 See Appendix A .
�
3.2 FOSS management
Many FOSS components are widely used, popular alternatives to commercial, proprietary solutions . There are a variety of components available for download at no cost . For examples of additional benefi ts of using FOSS, please see the survey questions analyzed in chapters 4 .2 to 4 .5 .
FOSS deployment in products can create several specifi c risks that must be addressed . The topic’s complexity is dominated by the diversity of Open Source licenses . While, at the moment, there are 69 licenses approved by the OSI, there are many variants of these, along with a large number of Open Source-like licenses; in fact, there are over 2,100 individual licenses identifi ed to date (as of January 2012, source: Black Duck Software) .
Licenses defi ne the conditions you must meet in order to legally use the particular FOSS component .
Noncompli-ance with license conditions can lead to preliminary injunctions, recalls, damage complaints, or profi t skimming, among other legal issues . These risks are real and alarming because their materialization negatively impacts
busi-ness . The good news is that they can be mitigated by proper FOSS management .
Figure 1: Basic FOSS processes
Product FOSS FOSS FOSS Developer Supplier Customer Selecting FOSS components
Screening deliveries from suppliers
Overview
The core elements of any FOSS management infrastructure are policies and processes that control the deployment of FOSS within the company and secure the interfaces to the suppliers . Figure 1 shows the typical fl ow of FOSS within a company .
FOSS is often introduced by software developers and external suppliers . If this happens without control, it puts the company at risk for license violations . At both entry points, it is necessary to check which FOSS components are introduced into the product and, later, delivered to customers . Relying on content assumptions, even by developers and suppliers, is not suffi cient to protect your product or your company . Rather, the most reliable method of detecting incorporated FOSS code is automated code scanning processes that search for both complete components and individual procedures or algorithms . Before making a product public, it is crucial to ensure that the obligations associated with all licenses in the FOSS code are met . Regardless of the source of the code, the distributor bears the responsibility for ensuring all license obligations are fulfi lled .
The survey was conducted with representatives from 25 companies in the automotive ecosystem, based in eight countries . These companies represent 50 % of the European automotive industry, as measured by turnover . Some questions were presented selectively (e . g . only those participants who selected “We use Open Source compo-nents” were later asked “Why do you use Open Source components?”) . In addition, multiple choice questions were based on a multiple selection criteria (e . g . “Check all that apply”), so answers often sum to greater than 100 % .
4.1 Stance towards FOSS in products
Synopsis: The majority of participating companies use FOSS in their products, or are evaluating future use of FOSS, although some respondents do not believe they are utilizing FOSS at all . Only about one quarter of respondents realize the benefits from contributions back to the FOSS community .
Question: What is your company’s relationship to using Open Source Software in products?
9 %
21 %
59 %
Other We are head of one or more projects We have started one or more projects We do not use it We contribute to it We are evaluating use We use it 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 35 % 15 % 6 % 6 %
�
Survey
Analysis
More than 85 % of the surveyed companies have one or more relationship with FOSS . While the majority, 59 %, say that they use FOSS, and 35 % are evaluating whether they should use FOSS components, at least 15 % believe that they do not use FOSS components in their products . Because none of the 15 % replied that they use a code scanner to identify FOSS portions in their code, we cannot confi dently report whether they, indeed, do not use FOSS components or code snippets from source code that is licensed under a FOSS license or whether they use such code and are simply unaware of it .
The percentage of companies reporting that they use FOSS components in their products was lower than expected, given Gartner’s prediction4 that in 2012, at least 80 % of all software development companies will be
using FOSS . An interesting discrepancy is that 27 % of the respondents did not check either “We use FOSS” or “We do not use FOSS” as an answer . Despite the growing awareness about the use of FOSS, there remains uncertainty regarding how FOSS is handled within organizations .
Only a few of the surveyed companies report interacting with or participating in the FOSS community . While at least 21 % of participants have contributed to the community and 43 % of those have started a FOSS project, only 29 % of these companies are leading a project . The majority (79 %) of FOSS users do not benefi t from the business opportunities that active involvement with the community would provide .
4.2 Reasons for using FOSS in products
Synopsis: While retaining the competitive advantage, cutting costs, avoiding vendor lock-in and customizability are the main drivers for FOSS use in products, a signifi cant number of companies report that developers introduce
FOSS without permission .
Question: Why are you using Open Source components in your products?
5 % 10 % 10 % 15 % 20 % 25 % 30 % 45 % 45 % 55 % 60 % Other Higher quality than closed source alternatives Developer request Have better features than closed source alternatives Non-permitted incident Customer request There is no closed source alternative We can avoid dependency on closed source alternatives Easy customization Cheaper than closed source alternatives Helps us focus our resources
0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 %
One might guess that saving money would be the main reason for integrating FOSS components in products; however, this study reveals that fi nancial considerations are only the second most important reason for using FOSS . The top reason (60 %) is to focus the company’s resources on competitively differentiating components, and not to lose time and resources on re-implementing commodity software components that do not add real customer value .
The next most reported answers include: cutting costs (55 %), followed by avoiding the lock-in on a particular commercial product or vendor, and the possibility to easily customize FOSS components to fi t their own needs
Survey Analysis
(both 45 %) . The other reasons listed seem to be less important for the surveyed companies . In fact, only 10 % indicated that they use FOSS expecting higher quality code than they would get with closed source alternatives .
Surprisingly, 20 % of the participants said that FOSS (with all its license obligations) was brought in by developers without corporate permission . This high fi gure underscores the importance of awareness and an effective FOSS management process with control mechanisms to identify unexpected FOSS usage and license obligations .
A full 25 % of respondents reported that they were required by their customers to use FOSS components in their deliverables, which is somewhat contradictory to the common contractual requirement of delivering software that is “free of third-party rights .” In the future, we expect continued growth of Open Source in customer require-ments, which will help streamline and enhance supplier contracts .
4.3 Reasons for evaluating usage of FOSS in products
Synopsis: Retaining competitive advantage, cutting costs, avoiding vendor lock-in and customizability are the most important features that drive the evaluation of using FOSS components in products . There is a noticeable difference concerning non-permitted incidents between the answers in 4 .3 and 4 .4 .
Question: Why are you evaluating the use of Open Source components in your products?
0 % 0 % 0 % 0 % 42 % 42 % 50 % Other Customer request Developer request Non-permitted incident Higher quality than closed source alternatives Have better features than closed source alternatives There is no closed source alternative Easy customization Cheaper than closed source alternatives We can avoid dependency on closed source alternatives Helps us focus our resources
0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 8 %
8 %
58 % 17 %
Compared to companies that already use FOSS in their products, the top reasons have changed only slightly .
Respondents report: focus on competitive advantage (58 %), followed by avoiding vendor lock-in (50 %) and cost savings, as well as easy customizability (both 42 %) . Similar to those companies that actively use FOSS, the quality of FOSS components is a crucial aspect for only a small percentage of respondents .
The biggest differences between companies that actively use FOSS and companies that do not can be segmented into three areas:
•
FOSS brought in by developers with permission•
FOSS brought in by developers without permission•
Customers asking for FOSS integrationWhile at least 24 % of the respondents who use FOSS components in their products selected one of these options, none of the participants who evaluate FOSS usage chose one of these three options as reason for evaluation . The different results regarding FOSS brought in by developers may be explained by ignorance of the actual handling of FOSS within the company, most likely due to the lack of processes for detecting and evaluating FOSS components introduced inadvertently . The apparent deviation concerning customer requests needs further investigation .
4.4 Reasons for contributing to FOSS projects
Synopsis: The key reasons for surveyed companies contributing to FOSS projects are: creating standards, avoiding a local diverging version, creating an alternative to a closed source component and motivating knowledge
sharing . In the future, with FOSS coming even more into focus, these points may shift . Question: Why are you contributing to Open Source projects?
0 % 0 % 0 % 0 % 14 % 43 % Other It makes us a good FOSS citizen Developer request Non-permitted incident Customer request Helps us to avoid local diverging version Helps us to create viable alternative Motivates the sharing of knowledge Lets us create standard
0 % 10 % 20 % 30 % 40 % 50 % 60 % 57 % 29 %
29 %
A majority (57 %) of participants who contribute to FOSS projects do so in order to create a standard to eventually reduce costs for all who are involved . An example of these efforts is the GENIVI Alliance, which is creating an Open Source platform for In-Vehicle Infotainment (IVI) systems, as discussed earlier . Motivation for knowledge sharing is important for 43 % of respondents, creating a viable alternative to a closed source component and avoiding maintenance of a local diverging version of a FOSS component are drivers for 29 % each .
The response rate of 29 % for avoidance of a local diverging version is surprisingly low . Because of the short release cycles of FOSS projects, companies waste confi guration management resources on creating and main-taining local adaptations and keeping a company’s version synchronized with community updates . There are two possible explanations for this observation: companies use FOSS components unchanged or they do not update to the latest version of FOSS components, which raises concerns regarding security vulnerabilities .
In contrast to the responses to question 4 .2, a surprisingly high number (14 %) of respondents are required by their customers to contribute to FOSS projects .
While none of the surveyed companies report that developers contribute to FOSS projects without permis-sion, this may not be accurately reported, since developers can contribute to Open Source projects outside of work using personal credentials . Since none of the participating companies reported concerns about being a “good Open Source citizen” through “giving something back,” their engagement in FOSS seems solely driven by commercial motivation .
Survey Analysis
4.5 Reasons for leading and starting FOSS projects
Synopsis: Only a few respondents decided, based on strategic considerations, to commit to or start FOSS projects .
The main reasons are infl uencing projects, market advantages for existing products and platforms, and cost-cutting .
Question: Why are you leading Open Source projects?
0 % 0 % 0 % 0 % 0 % 50 % 100 % Other Visibility for company's products Dependence on project Developer request Non-permitted incident Strengthen market position Influence project for product needs
0 % 20 % 40 % 60 % 80 % 100 % 120 %
Question: Why did you start an Open Source project?
0 % 0 % 0 % 33 % Other Developer request Non-permitted incident Helps us to create viable alternative Helps us to save development costs Marketing for products
0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 67 % 67 %
Of the interviewed companies that contribute to FOSS projects, 50 % have started and 33 % lead such projects . All of these companies report that infl uencing the market position of their products is a critical part of their commit-ment to FOSS projects . Other important points include infl uencing projects for the company’s needs and utilizing community resources . Based on these answers, we assume that all responding companies made a strategic deci-sion based on a business model that strongly involves FOSS .
4.6 Existing process governance
Synopsis: While there is room for improvement concerning processes for development and requirements manage-ment, the process environment around FOSS management needs the most attention . Responses indicate that Open Source code management is patchwork, at best; indeed, most survey participants report no solid structure of FOSS governance, but there are many starting points that enable a simple link between existing R&D related processes and FOSS management processes .
Question: Do you have a policy or documented process in place for:
0 % 3 % 9 % 12 % 18 % 21 % 71 % 88 % Other Starting a FOSS project Leading FOSS projects Contributing to FOSS projects Auditing suppliers Selecting FOSS components Deploying FOSS components Screening supplier components Selecting third-party components Managing Requirements Developing software 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 100 % 53 % 15 % 6 %
Question: How do you ensure compliance with the defi ned processes?
3 % 12 %
38 %
Other We do not check for compliance We use workflow engines to enforce the process We use tools for process automation and control Perform random project audits
0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 65 % 27 %
Survey Analysis
As expected, most participants said that they have processes in place for software development (88 %) and managing requirements (71 %) . The numbers for starting (3 %) and leading (6 %) FOSS projects are no surprise either, as today these are still rare activities, according to the responses to previous questions .
The remaining results are much more interesting . While at least 62 % of surveyed companies have processes for development and requirement management in place, almost no companies that have a relationship to FOSS have established basic FOSS management processes, such as deploying and fulfi lling license obligations (18 %), selecting FOSS components (15 %) and screening deliveries from suppliers (21 %) .
This gap is alarming . Since 97 % of the companies with FOSS relationships do not have a structured way to control FOSS deployment, these companies are not able to verify that all associated license obligations are fulfi lled in
their deliveries . Of the companies contributing to FOSS projects, not a single one has established these processes, therefore putting their IP at risk through uncontrolled contributions .
At least 29 % of the contributing companies have a process in place for contribution . This gap might be even more risky than without contributions . Only 28 % of the companies that have a process for selecting commercial third-party components (53 %) have a similar process for FOSS components (15 % in total) . Even though the associated risks of using software without having the required rights are the same for commercial and FOSS components, it seems that awareness is completely different, and FOSS does not seem to be a priority .
Another difference can be observed concerning internal FOSS usage versus FOSS introduced by suppliers . While 15 % of the surveyed companies have realized the necessity of controlling integration of FOSS during software development and 21 % realized the necessity of checking deliveries from suppliers for incorporated FOSS compo-nents, only 3 % have documented processes for these activities in place . 38 % of respondents say that they use tools or workfl ow engines (27 %) to support their defi ned processes, 44 % use both . The majority rely on random audits (65 %) and good faith (12 %) .
4.7 Supplier management
Synopsis: Most respondents check deliveries against specifi cations, but neither request proof or challenge suppliers about these reports . This suggests that most companies trust their suppliers to comply with their contracts .
Question: How do you audit your suppliers and their deliverables?
3 % 9 %
32 % Other
Check for FOSS components We require FOSS bill-of-material Stipulated supplier processes We perfom supplier audits Check against contracutally agreed-upon specification
0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 68 % 24 %
36 %
Monitoring suppliers is essential since companies usually do not have infl uence on the development approaches of suppliers . 68 % of respondents reported that deliveries from suppliers are checked against the previously agreed-upon specifi cations . Some companies go further and perform supplier audits (36 %) or defi ne processes which have to be followed by the suppliers (32 %) . It is surprising that only 24 % require a complete list of all incorporated FOSS components and licenses from their suppliers . Such FOSS disclosure documents are essential for knowing which license obligations to fulfill .
The next level of safeguarding the supplier interface is checking whether the supplied list of FOSS components represents the actual software confi guration . But this step towards license compliance is performed by only 9 % of respondents (and by 25 % of those who require a FOSS disclosure document) . Most companies seem to ignore the fact that they are responsible for the license compliance of the whole product, regardless of the origin of single components .
Survey Analysis
4.8 Support through process tools
Synopsis: While software development within the surveyed companies is well-supported by tools, only a minority uses tools to create and maintain FOSS license compliance .
Question: Which tools are you using in software development:
0 % 3 %
68 % Other
Open Source compliance management Requirements management Software configuration management Bug tracking
0 % 20 % 40 % 60 % 80 % 100 % 91 %
94 %
Tools widely used by the surveyed companies included: bug tracking systems (94 %), confi guration management tools (91 %) and at least 68 % support requirement management with tools (85 % use confi guration management and bug tracking tools, 61 % use all three) .
An extreme contrast is the low penetration of FOSS management (less than 3 %) . This is alarming, since the diversity of FOSS licenses and obligations, sometimes even within a single FOSS component, cannot be managed manually due to sheer complexity . In our experience, many companies rely on Excel spreadsheets maintained by developers . Unfortunately, these lists are often incomplete, inconsistent, and out-of-date . The resulting high risk of noncompliance can only be mitigated effi ciently by FOSS management tools with the code analysis capabilities to identify those hidden FOSS components, often brought in by developers without approval – something that happens in 20 % of the responding companies .
An effective and effi cient FOSS management infrastructure – consisting of several building blocks – not only reduces the risks associated with FOSS deployment in products, but also enables organizations to increase and sustain benefi ts from using FOSS .
The general rules for dealing with FOSS should be defi ned in a FOSS policy which is implemented with adequate processes, guidelines and tools . Adherence to the policy must be continuously monitored and enforced, and appropriate, role-specifi c training will enable developers and other stakeholders (e . g . legal department) to “do things the right way .” Creating awareness for FOSS risks and benefi ts throughout the organization is key for success .
Implementing an effective FOSS management infrastructure is a considerable project and requires careful plan-ning that considers various constraints (e . g . available budget, product release schedule, external requirements) .
Therefore, creating an implementation roadmap which defi nes the timeline and implementation sequence for various building blocks is highly recommended .
The BearingPoint FOSS Management Maturity Model (see Figures on page 24 & 25), a guideline for implementing FOSS management, was developed based on years of experience creating management infrastructures for our clients . The model guides users through the various risk mitigation steps while simultaneously demonstrating how to most effi ciently utilize the benefi ts of FOSS . Consistently increasing the FOSS management maturity level
Sustained license compliance can only be achieved if certain FOSS-related activities (e . g . component approval) and deliverables (e . g . completed checklists, approval documents) are added to the relevant processes (e . g . de vel-opment process) and controlled as part of regular quality assurance procedures . Additional practical guidelines can signifi cantly reduce the FOSS compliance-related overhead for developers and other stakeholders .
Strict attention must be paid to all interfaces where software fl ows in and out of the company . As part of the contract, suppliers must be given a set of rules and regulations regarding FOSS usage (e . g . allowed licenses, FOSS disclosure document delivery) and the adherence to these rules must be monitored (e . g . by scanning the deliv-eries using an automated tool) . Supplier selection and audits must include FOSS-related criteria .
Once the risks are under control, FOSS coordination allows signifi cant cost reduction from FOSS usage . The following elements are typically implemented:
•
FOSS approval board and approval workfl ow•
Whitelists and blacklists of approved/denied FOSS packages and licenses•
Usage tracking of FOSS components and consolidation of packages/versions•
Community and security vulnerability monitoringMost of the FOSS coordination tasks can be automated using specialized tools, as outlined in the next chapter .
�
FOSS
Management –
Mitigate Risks and
Free and Open Source Software Management
FOSS enables you …
FOSS Coordination
FOSS Supplier Management
FOSS Processes
FOSS requires Management …
FOSS Strategy, Awareness
Broad awareness Role specific Training
Secured supplier Interface Processes Guidelines Tools Mechanisms for sustained enforcement FOSS Policy
How to deal with FOSS
Initial assessment by developer FOSS examination by FAB Request to FOSS Authority Board (FAB)
On the Whitelist Release On the blacklist Not listed Usage denied Blacklist Whitelist
�
Scan code nightly to maintain compliance
Consolidate and re-use FOSS Packages
Maintain centralized FOSS Inventory and track usage
Install FOSS Authority Board
�
Certify and audit suppliers using standard interfaces
Inspect deliveries (disclosure document, SPDX)
Provide contractual agreements governing FOSS
�
Create checklists for license compliance
Establish technical & legal approval criteria / w
orkflo
ws
Add FOSS Management elements to R&D processes
�
Perform code scan, resolve compliance issues
Educate all stakeholders
•
No need to (re-)develop commodities•
Resources concentrate on competitive features the customer really pays for… to innovate
•
Re-use instead of new development•
Faster time-to-market… to cut costs
•
FOSS standards can change whole industries (e.g. Google’s Android)… to standardize
•
Non-compliance with FOSS licensesproduction stops, recalls, damage claims, profit skimming, criminal charges
•
Violation of 3rd party patents•
Free-of-charge licensing of own patents•
Involuntary disclosure of proprietary and differentiating software code (Viral Effect)… to mitigate legal risks
•
Security vulnerabilities•
Quality and documentation•
Sustainability, warranty and support… to avoid hidden costs
Contact
[email protected] BearingPoint GmbH
Speicherstraße 1
D-60327 Frankfurt am Main – Germany
FOSS
MANA
GEMENT
MA
TURIT
Y
LEVEL
Your Product FOSS FOSS FOSS Developer Tools Supplier4 Steps to Successful and Mature
Free and Open Source Software Management
FOSS enables you …
FOSS Coordination
FOSS Supplier Management
FOSS Processes
FOSS requires Management …
FOSS Strategy, Awareness
Broad awareness Role specific Training
Secured supplier Interface Processes Guidelines Tools Mechanisms for sustained enforcement FOSS Policy
How to deal with FOSS
Initial assessment by developer FOSS examination by FAB Request to FOSS Authority Board (FAB)
On the Whitelist Release On the blacklist Not listed Usage denied Blacklist Whitelist
�
Scan code nightly to maintain compliance
Consolidate and re-use FOSS Packages
Maintain centralized FOSS Inventory and track usage
Install FOSS Authority Board
�
Certify and audit suppliers using standard interfaces
Inspect deliveries (disclosure document, SPDX)
Provide contractual agreements governing FOSS
�
Create checklists for license compliance
Establish technical & legal approval criteria / w
orkflo
ws
Add FOSS Management elements to R&D processes
�
Perform code scan, resolve compliance issues
Educate all stakeholders
Develop FOSS Policy governing FOSS usage
•
No need to (re-)develop commodities•
Resources concentrate on competitive features the customer really pays for… to innovate
•
Re-use instead of new development•
Faster time-to-market… to cut costs
•
FOSS standards can change whole industries (e.g. Google’s Android)… to standardize
•
Non-compliance with FOSS licensesproduction stops, recalls, damage claims, profit skimming, criminal charges
•
Violation of 3rd party patents•
Free-of-charge licensing of own patents•
Involuntary disclosure of proprietary and differentiating software code (Viral Effect)… to mitigate legal risks
•
Security vulnerabilities•
Quality and documentation•
Sustainability, warranty and support… to avoid hidden costs
Contact
[email protected] BearingPoint GmbH
Speicherstraße 1
D-60327 Frankfurt am Main – Germany
www.bearingpoint.com
FOSS
MANA
GEMENT
MA
TURIT
Y
LEVEL
Your Product FOSS FOSS FOSS Developer Tools Supplier6.1 Why govern the use of FOSS?
As software development evolves towards greater and greater reuse, FOSS is growing in importance, and with that, the need to manage and control it also increases . As shown earlier in this study, when it comes to acquiring third-party commercial software, formal purchasing processes exist in most companies; FOSS, however, is by and large uncontrolled . Easy Internet access and the ability to download, copy and paste code has circumvented formal acquisition processes – a delight to many developers but a potential nightmare for development managers responsible for ensuring the licensing integrity, quality and supportability of their software and managing poten-tial exposure of the company . Unlike traditional purchasing organizations, most developers are not trained on the right questions to ask about the code they are acquiring on behalf of their companies .
6.2 FOSS challenges
Like all code, FOSS needs to be managed across the development lifecycle, but it also creates unique challenges that need to be addressed . According to a 2011 Gartner Group report, FOSS challenges include:
•
Technical failure and operational exposure•
Security and business exposure•
Legal and intellectual property risksEvery development organization, whatever its size, needs policies, processes and tools to manage its development lifecycle . In a start-up organization, a spreadsheet and free web resources may be all the tools required . But for companies with history, multiple locations and product lines, and perhaps some offshore resources, automation is critical . With the proper automation tools and processes for FOSS governance, these challenges can be managed and mitigated, and automation ensures that governance does not impede development .
�
Tool Based
FOSS
6.3 FOSS governance
To effectively manage FOSS and optimize the benefi ts, fi ve governance processes are typically implemented with associated tool automation: Acquire, Approve, Catalog, Validate and Monitor .
Acquire
There are tens of billions of lines of FOSS code available on the Internet from thousands of sites . The process of searching for and fi nding code that meets requirements often benefi ts from search tools optimized for code
search . When developers weigh FOSS alternatives, they need access to project metadata (e . g . language, license, number of contributors, maturity, release date, known vulnerabilities, etc .) to assist in their selection of compo-nents . A knowledge base of FOSS with associated metadata is an essential resource to support this process .
Approve
Acquiring external code, especially FOSS, should involve an approval process to ensure review and compliance with a company’s standards and legal policies . Many development organizations rely on ad hoc manual approval methods that are slow, with little or no visibility regarding status . With agile development and short iterations, speed of approval and visibility into the process is critical for success . Developers need automation to minimize delays and for submitting requests to multi-function approval boards (development, legal, security, etc .) which may approve, reject, approve with restrictions, or request more information . If information pertaining to the approval submission is captured in an internal catalog (see below), it encourages developers to consider compo-nents that have already been approved, and processes can be designed to take that into consideration . So, for example, a component that has already been approved for a similar use may be put on a fast track for further use .
Catalog
An internal catalog of FOSS allows organizations to capture, track and document component usage across an
enterprise . It facilitates reuse, standardization and collaboration within and between development groups . The catalog refl ects components that have completed the approval process and have been approved, rejected or are in-process . It also tracks where components are being used for remediation, updates, etc . When developers search for components, the catalog should be searched in parallel in order to encourage the use of components
Figure 2: The major processes for application development and FOSS governance across the lifecycle.
Application Development Lifecycle
Acquire Approve Catalog Validate Monitor
FOSS Governance
Tool Based FOSS Management5
Validation
Validation tools are needed to audit and ensure that the acquired and approved FOSS code is the same code that is used to build the software . Ideally this is just a rubber stamp, confi rming that developers followed upstream processes . Automated validation tools scan source code and binary fi les to discover unknown and unapproved software, automatically comparing the scanned code base to the known universe of Open Source code in a
knowl-edge base . In a continuous engineering process, validation tools automatically check each build and release .
In validation, in particular, a comprehensive FOSS knowledge base is an absolute necessity . The propagative nature of Open Source means that code is out “in the wild” for years . Developers can download any of half a million projects today and may reuse internal code that contains components that are no longer posted . So, it is essential for validation tools to utilize a knowledge base that tracks all of the many versions of every component available today and that has enough history to cover components that are no longer available .
Monitor
Once FOSS is acquired, approved, validated and deployed, it is important to monitor components over the full life-cycle . Problems can arise post deployment, including the discovery of security vulnerabilities, bug fi xes or other
issues . Unless it is a key building block, once a component is in the code, developers rarely track its trajectory . It is
important to have tools that monitor externally-sourced code to give development managers visibility into which components are deployed where, and enable developers to easily locate bugs, defects and security vulnerabilities across multiple code repositories distributed across the enterprise .
FOSS Discovery is the First Step: What’s in my code?
For many development organizations, FOSS has been used in an ad hoc and uncontrolled manner for years . When
FOSS governance is put in place, those organizations need a discovery process . Tools to automate the discovery
and identifi cation of FOSS and other code are effi cient and essential as they eliminate human error resulting from manual methods . When it comes to discovering FOSS in source and binary form, using a variety of analysis
techniques (snippet and fi le matching, string searches, dependency analysis, package name analysis), human and manual methods cannot compete with automated tools . The task is simply too vast and complex .
Software development organizations increasingly use a complex multi-source development process that takes advantage of the abundance of available FOSS components and building blocks . Fully leveraging the use of FOSS requires governance tools built around a comprehensive knowledge base, and their integration into development workflows in order to automate key processes related to FOSS management over the application development lifecycle . The benefits of automated FOSS governance include broader adoption, higher efficiency, lower costs, and richer collaboration . It is easier than ever to take control of FOSS usage and gain unprecedented visibility and control into what gets used without adding extra overhead to, or burden on, development groups .
In our daily work we witness similar scenarios as discovered during the course of this survey . Many automotive companies have already consciously decided to introduce FOSS into their commercial products . By doing so, these companies have recognized the business benefits from readily available, high-quality Open Source components which provide a wide variety of functionality that is required to build state-of-the-art automotive systems . Consist-ently using Open Source Software gives them a head start in innovation, because they no longer spend their substantial development resources on non-differentiating functionality, but rather, focus on the functionality that makes them unique and market leaders .
Unfortunately our observations also confirm the other side of the story . Due to the complex automotive supply chain, a plethora of challenges arise when it comes to managing FOSS deployment in a way that ensures license compliance and efficient deployment . These challenges are not met by the majority of companies - not even close .
The associated business risks – for example, the suspension of deliveries due to a preliminary injunction – have a crippling effect on the supply chain: the OEM who will be charged initially may have to take recourse on their suppliers (Tier 1), who in turn, may have to do the same to their suppliers (Tier 2), and continue until the license violation is first identified . And if the initial violating company does not have the necessary financial strength to
fix the problem and reimburse the others for their damages, each member of the supply chain will face conse-quences .
The impact on a brand’s image and market perception caused by bad press about a license violation and lawsuit is a serious threat to a company’s success . Therefore it is very important to safeguard all stages in the supply chain, requesting full transparency of deployed FOSS components and proof that all license obligations are fulfilled .
This can only be achieved by adequate processes supported by automated tools to handle the complexity and dynamics – similar to traditional auto manufacturing supply chains with practices like Lean Manufacturing and ISO-9000 processes and best practices .
Determine Strategic Business Drivers for FOSS
One of the first steps for any company that distributes products containing software is to think about their own stance towards FOSS . Questions like “What are our business goals concerning FOSS?” should guide the creation of a policy defining how FOSS is handled within the organization . After this policy is defined, role specific trainings should be provided to educate all relevant stakeholders about the policy and how it affects their daily work .
Without broad awareness about benefits, risks and their implications to daily work, it is nearly impossible to achieve and maintain license compliance .
Integrate FOSS into Supply Chain Management
After establishing a policy within the organization, the integration of FOSS management activities into existing R&D processes and developer-oriented guidelines bring the policy to life . Consistent technical and legal approval criteria for FOSS components helps control the variety of functionality and license implications . Often, the existing development processes allow an easy plug-in of FOSS management-related activities at milestones or within regular checks or tests . FOSS management checklists can provide useful information to developers and development managers .
Many companies we have worked with use Microsoft Excel to track the deployed FOSS components, licenses, and obligations and monitor usage in projects and products . This approach can work well for few components in a highly disciplined environment, but even then, it works only for a short time . The data becomes outdated and inconsistent and data quality erodes very quickly and quietly . Bad data or missing entries only surface when it is too late and license violations have been discovered . Fixing them can be costly and time-consuming, and may impact the overall schedule .
Unfortunately, it is only at this point that many companies realize they should have deployed specialized FOSS management tools which can handle this multi-dimensional complexity appropriately . Instead of implementing robust, automatic management policies at the start of development, companies often learn the hard way what it means to re-create a consistent data set and re-establish a compliance baseline .
Expand FOSS Use and Governance Across the Supply Chains to Maximize Benefi ts
After making in-house development teams “FOSS aware,” a company should widen its view towards the outside world and its suppliers . While FOSS may be well-managed within the development organization, the FOSS management maturity of the rest of the supply chain (see the FOSS Management Maturity Model on page 24 & 25) often remains in the dark . As mentioned before, license violations trickle down the supply chain and the OEM
is the fi rst to know when it comes to litigation . These risks can be mitigated only by safeguarding all stages of the supply chain . Contracts with suppliers must be reviewed and clauses added that defi ne the rules under which FOSS components can or cannot be integrated into software deliveries . All suppliers must demonstrate that their FOSS management maturity level is the same or higher .
The main element of supply chain security is transparency . Suppliers must disclose all deployed FOSS compo-nents and applicable licenses and proof that all license obligations are fulfi lled . To verify the accuracy of the data provided, automated source code scans should be carried out on all source code deliveries and the scan results be compared with the information provided . For all binary deliveries, adequate scan reports should be requested from the supplier . Only after a supplier has established a proven track record of compliance, can the frequency of these checks be reduced . One step further is to audit the supplier’s FOSS management infrastructure regularly by visiting the development sites to witness how FOSS management is done in practice . Simply requesting the process documentation is not enough .
Go Beyond Compliance to FOSS Asset Management & Deployment .
After managing compliance risks, FOSS management should focus on increasing the effi ciency of FOSS
deploy-ment . The central activities here are consolidation and reuse . Reducing the number of deployed FOSS packages for certain functionality, as well as the different versions of a FOSS package, not only reduces product complexity but also the maintenance overhead for FOSS deployment . Each and every FOSS component or version of a FOSS component must be qualifi ed (e . g . architectural fi t, code quality, documentation, license and obligations) and, most of the time, be modifi ed in order to integrate it in the rest of the product . Instead of letting developers choose from all available components on the internet, which would result in a diverse mixture of doubled func-tionality, the organization should establish and maintain a FOSS repository within the organization to provide pre-qualifi ed and approved components .
Developers must fi rst evaluate the fi t of components in the repository before they can suggest new ones . In this
way, heterogeneity in architecture can be decreased and quality increased, because only the selected components need to be monitored concerning quality, security and similar concerns . Existing software architecture can be optimized by replacing all FOSS components which are not in the repository with approved components . New components can be qualifi ed and added to the reposity when valid technical reasons exist (e . g . features, footprint requirements) .
Tool Based FOSS Management5
“rejected .” FOSS components with “rejected” licenses may not be used within any product . Licenses that are “conditionally approved” require additional approval only if the component is used in a way not already author-ized, e . g . if LGPL code is supposed to be used in non-library components . And FOSS packages with “approved” licenses can be deployed without restrictions .
Automate and Improve FOSS Supply Chain Practices
By utilizing specialized tools to manage FOSS component deployment and license approvals, overhead costs can be signifi cantly reduced . Manually maintained Excel spreadsheets are, again, not a good choice, since data consistency is hard to maintain with an ever growing number of packages and licenses .
As outlined in this chapter, while FOSS management is a complex task, there are proven methods and tools available for automotive companies to gain a competitive edge through Open Source Software deployment while managing risks and product complexity effi ciently and effectively .
INTRODUCTION
Open Source does not just mean access to the source code . The distribution terms of Open Source Software must comply with the following criteria:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources . The license shall not require a royalty or other fee for such sale .
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form .
Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge . The source code must be the preferred form in which a programmer would modify the program . Deliberately obfuscated source code is not allowed . Intermediate forms such as the output of a pre processor or translator are not allowed .
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software .
4. Integrity of The Author’s Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distri-bution of “patch files” with the source code for the purpose of modifying the program at build time . The license must explicitly permit distribution of software built from modified source code . The license may require derived works to carry a different name or version number from the original software .
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons .
Appendix:
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor . For example, it may not restrict the program from being used in a business, or from being used for genetic research .
7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties .
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program’s being part of a particular software distribu-tion . If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution .
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software .
For example, the license must not insist that all other programs distributed on the same medium must be Open Source Software .
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface .
Appendix:
Helping our clients get sustainable, measurable results
BearingPoint is an independent management and technology consultancy . Owned and operated by its Partners throughout Europe, BearingPoint provides its clients with the best possible value in terms of
tangible, measurable results by leveraging business and technology expertise . The company currently employs 3,200 people in 15 countries and serves commercial, financial and public services clients . BearingPoint offers its clients a seamless cross-border approach, strong focus on results, an entrepreneurial culture, profound industry and functional knowledge, as well as solutions customised to clients’ specific needs . The firm ranks high in client satisfaction, has long-standing relationships with reputable organisations and is seen as a trusted adviser .
BearingPoint has European roots, but operates with a global reach .
For more information, please visit: www .bearingpoint .com We are BearingPoint . Management & Technology Consultants
BearingPoint GmbH Speicherstraße 1
D-60327 Frankfurt am Main – Germany
www .bearingpoint .com
