FOSS Management Study

Transcription

1 FOSS Management Study Study 2012

2 FOSS Management Study BearingPoint GmbH Table of Contents 1 Preface... 3 Executive Summary... 5 Overview FOSS definition FOSS management Survey Analysis Stance towards FOSS in products Reasons for using FOSS in products Reasons for evaluating usage of FOSS in products Reasons for contributing to FOSS projects Reasons for leading and starting FOSS projects Existing process governance Supplier management Support through process tools FOSS Management Mitigate Risks and Maximize Cost Benefits Tool Based FOSS Management Why govern the use of FOSS? FOSS challenges FOSS governance Summary Conclusion and Outlook Appendix: The Open Source Definition

3 1 Preface 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 prioritizing 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 recommendations 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 3

4 FOSS Management Study BearingPoint GmbH 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 available 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. 1 FOSS means software for which the source code is freely available and therefore can be changed and adapted by everyone. For a more precise definition see chapter

5 Executive Summary 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) 2 BearingPoint 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 development. 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 2 Alexy, Henkel: Intraorganizational Implications of Open Innovation: The Case of Corporate Engagement in Open Source Software, October 28,

6 FOSS Management Study BearingPoint GmbH 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 influence 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 fifth 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 specifications, 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 significant overhead effort. 6

7 Executive Summary 7

8 FOSS Management Study BearingPoint GmbH 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. This survey is dedicated to exploring FOSS integration into products in the automotive industry. 8

9 Overview 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 extensions 3 See Appendix A. 9

10 FOSS Management Study BearingPoint GmbH 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 benefits of using FOSS, please see the survey questions analyzed in chapters 4.2 to 4.5. FOSS deployment in products can create several specific 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 identified to date (as of January 2012, source: Black Duck Software). Licenses define the conditions you must meet in order to legally use the particular FOSS component. Noncompliance with license conditions can lead to preliminary injunctions, recalls, damage complaints, or profit skimming, among other legal issues. These risks are real and alarming because their materialization negatively impacts business. The good news is that they can be mitigated by proper FOSS management. Figure 1: Basic FOSS processes Selecting FOSS components Developer Deploying & fulfilling license obligations FOSS Product FOSS Customer Supplier FOSS Screening deliveries from suppliers 10

11 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 flow 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 sufficient 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 fulfilled. 11

12 FOSS Management Study BearingPoint GmbH 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 components 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. 12

13 Survey Analysis Question: What is your company s relationship to using Open Source Software in products? We use it 59 % We are evaluating use 35 % We contribute to it 21 % We do not use it 15 % We have started one or more projects We are head of one or more projects Other 6 % 6 % 9 % 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 13

14 FOSS Management Study BearingPoint GmbH 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 confidently 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 prediction 4 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 benefit 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 significant number of companies report that developers introduce FOSS without permission. Question: Why are you using Open Source components in your products? Helps us focus our resources 60 % Cheaper than closed source alternatives 55 % Easy customization 45 % We can avoid dependency on closed source alternatives 45 % There is no closed source alternative 30 % Customer request 25 % Non-permitted incident 20 % Have better features than closed source alternatives 15 % Developer request 10 % Higher quality than closed source alternatives 10 % Other 5 % 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 financial 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 fit their own needs 4 Mark Driver: Key Issues for Open Source Software, Gartner Research,

15 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 figure 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 requirements, 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? Helps us focus our resources We can avoid dependency on closed source alternatives Cheaper than closed source alternatives Easy customization There is no closed source alternative Have better features than closed source alternatives Higher quality than closed source alternatives Non-permitted incident Developer request Customer request Other 0 % 0 % 0 % 0 % 8 % 8 % 17 % 42 % 42 % 50 % 58 % 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 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 integration While 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. 15

16 FOSS Management Study BearingPoint GmbH 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? Lets us create standard Motivates the sharing of knowledge Helps us to create viable alternative Helps us to avoid local diverging version Customer request Non-permitted incident Developer request It makes us a good FOSS citizen Other 0 % 0 % 0 % 0 % 14 % 29 % 29 % 43 % 57 % 0 % 10 % 20 % 30 % 40 % 50 % 60 % 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 configuration management resources on creating and maintaining 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 permission, 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. 16

17 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 influencing projects, market advantages for existing products and platforms, and costcutting. Question: Why are you leading Open Source projects? Influence project for product needs 100 % Strengthen market position 50 % Non-permitted incident Developer request Dependence on project Visibility for company's products Other 0 % 0 % 0 % 0 % 0 % 0 % 20 % 40 % 60 % 80 % 100 % 120 % Question: Why did you start an Open Source project? Marketing for products 67 % Helps us to save development costs 67 % Helps us to create viable alternative 33 % Non-permitted incident 0 % Developer request 0 % Other 0 % 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % Of the interviewed companies that contribute to FOSS projects, 50 % have started and 33 % lead such projects. All of these companies report that influencing the market position of their products is a critical part of their commitment to FOSS projects. Other important points include influencing projects for the company s needs and utilizing community resources. Based on these answers, we assume that all responding companies made a strategic decision based on a business model that strongly involves FOSS. 17

18 FOSS Management Study BearingPoint GmbH 4.6 Existing process governance Synopsis: While there is room for improvement concerning processes for development and requirements management, 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: Developing software 88 % Managing Requirements 71 % Selecting third-party components 53 % Screening supplier components Deploying FOSS components Selecting FOSS components Auditing suppliers Contributing to FOSS projects Leading FOSS projects Starting a FOSS project Other 21 % 18 % 15 % 12 % 9 % 6 % 3 % 0 % 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 100 % Question: How do you ensure compliance with the defined processes? Perform random project audits 65 % We use tools for process automation and control 38 % We use workflow engines to enforce the process 27 % We do not check for compliance 12 % Other 3 % 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 18

19 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 fulfilling 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 fulfilled 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 thirdparty 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 components, only 3 % have documented processes for these activities in place. 38 % of respondents say that they use tools or workflow engines (27 %) to support their defined processes, 44 % use both. The majority rely on random audits (65 %) and good faith (12 %). 19

20 FOSS Management Study BearingPoint GmbH 4.7 Supplier management Synopsis: Most respondents check deliveries against specifications, 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? Check against contracutally agreed-upon specification 68 % We perfom supplier audits Stipulated supplier processes 32 % 36 % We require FOSS bill-of-material 24 % Check for FOSS components 9 % Other 3 % 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % Monitoring suppliers is essential since companies usually do not have influence on the development approaches of suppliers. 68 % of respondents reported that deliveries from suppliers are checked against the previously agreed-upon specifications. Some companies go further and perform supplier audits (36 %) or define 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 configuration. 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. 20

21 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: Bug tracking Software configuration management 94 % 91 % Requirements management 68 % Open Source compliance management Other 0 % 3 % 0 % 20 % 40 % 60 % 80 % 100 % Tools widely used by the surveyed companies included: bug tracking systems (94 %), configuration management tools (91 %) and at least 68 % support requirement management with tools (85 % use configuration 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 efficiently 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. 21

22 FOSS Management Study BearingPoint GmbH An effective and efficient 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 benefits from using FOSS. The general rules for dealing with FOSS should be defined 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-specific training will enable developers and other stakeholders (e. g. legal department) to do things the right way. Creating awareness for FOSS risks and benefits throughout the organization is key for success. Implementing an effective FOSS management infrastructure is a considerable project and requires careful planning that considers various constraints (e. g. available budget, product release schedule, external requirements). Therefore, creating an implementation roadmap which defines 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 efficiently utilize the benefits of FOSS. Consistently increasing the FOSS management maturity level not only reduces the risks associated with FOSS use, but also provides opportunities for additional and sustained cost savings through increased in-house reuse of FOSS components and the automation and centralization of license compliance management processes and activities. 22

23 FOSS Management Mitigate Risks and Maximize Cost Benefits 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. development process) and controlled as part of regular quality assurance procedures. Additional practical guidelines can significantly reduce the FOSS compliance-related overhead for developers and other stakeholders. Strict attention must be paid to all interfaces where software flows 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 deliveries using an automated tool). Supplier selection and audits must include FOSS-related criteria. Once the risks are under control, FOSS coordination allows significant cost reduction from FOSS usage. The following elements are typically implemented: FOSS approval board and approval workflow Whitelists and blacklists of approved/denied FOSS packages and licenses Usage tracking of FOSS components and consolidation of packages/versions Community and security vulnerability monitoring Most of the FOSS coordination tasks can be automated using specialized tools, as outlined in the next chapter. 23

24 4 Steps to Succe Free and Open Source FOSS enables you Scan code nightly to to innovate No need to (re-)develop commodities Resources concentrate on competitive features the customer really pays for to cut costs Re-use instead of new development Faster time-to-market to standardize FOSS standards can change whole industries (e.g. Google s Android) FOSS requires Management to mitigate legal risks Non-compliance with FOSS licenses production 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 avoid hidden costs Security vulnerabilities Quality and documentation Sustainability, warranty and support FOSS MANAGEMENT MATURITY LEVEL Consolidate and re-us Maintain centralized Install FOSS Authority Certify and audit supp Inspect deliveries (di Provide contractual a Create checklists for l Establish technical & Add FOSS Manageme Perform code scan, re Educate all stakehold Develop FOSS Policy g 24

25 ssful and Mature Software Management maintain compliance e FOSS Packages FOSS Coordination FOSS Policy How to deal with FOSS FOSS Inventory and track usage Processes Guidelines Tools Secured supplier Interface Mechanisms for sustained enforcement Board Broad awareness Role specific Training liers using standard interfaces FOSS Supplier Management Developer FOSS sclosure document, SPDX) Your Product FOSS Supplier greements governing FOSS Tools FOSS icense compliance FOSS Processes Blacklist On the blacklist Usage denied legal approval criteria / workflows Initial assessment by developer Not listed Request to FOSS Authority Board (FAB) FOSS examination by FAB nt elements to R&D processes solve compliance issues ers overning FOSS usage On the Whitelist Release Whitelist FOSS Strategy, Awareness Contact foss-management@bearingpoint.com BearingPoint GmbH Speicherstraße 1 D Frankfurt am Main Germany 25

26 FOSS Management Study BearingPoint GmbH 6.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 potential 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. 5 Black Duck Software, the leading global provider of strategy, products and services for enabling enterprise scale adoption of Open Source Software (OSS), provided insight for this chapter. For more information, please visit 26

27 Tool Based FOSS Management 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 risks Every 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. 27

28 FOSS Management Study BearingPoint GmbH Figure 2: The major processes for application development and FOSS governance across the lifecycle. Application Development Lifecycle Plan Code Build Test Release FOSS Governance Acquire Approve Catalog Validate Monitor 6.3 FOSS governance To effectively manage FOSS and optimize the benefits, five 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 finding code that meets requirements often benefits 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 components. 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 components 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 reflects 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 that are already deployed and thereby decrease component (and version) proliferation. 28

29 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, confirming that developers followed upstream processes. Automated validation tools scan source code and binary files to discover unknown and unapproved software, automatically comparing the scanned code base to the known universe of Open Source code in a knowledge 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 lifecycle. Problems can arise post deployment, including the discovery of security vulnerabilities, bug fixes 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 identification of FOSS and other code are efficient 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 file 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. 29

30 FOSS Management Study BearingPoint GmbH 7 Summary 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. 30

31 8 Conclusion and Outlook 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. Consistently 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 consequences. 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. 31

32 FOSS Management Study BearingPoint GmbH 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 Benefits 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 first 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 define 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 components and applicable licenses and proof that all license obligations are fulfilled. 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 efficiency of FOSS deployment. 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 qualified (e. g. architectural fit, code quality, documentation, license and obligations) and, most of the time, be modified 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 functionality, the organization should establish and maintain a FOSS repository within the organization to provide pre-qualified and approved components. Developers must first evaluate the fit 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 qualified and added to the reposity when valid technical reasons exist (e. g. features, footprint requirements). Licenses should be managed similarly to FOSS components. A repository of already analyzed licenses should be created, categorizing each license into one of the three categories approved, conditionally approved, and 32