Executive Briefing: Four Steps to Creating an Effective Open Source Policy Greg Olson Sr. Director OSS Management Olliance Group
Speaker Greg Olson Sr. Director, Open Source Management Over 30 years of software industry experience Managed delivery of over 150 engagements at Olliance Group Founder and chairman of Sendmail, one of the first commercial open source companies VP of Strategy and Business Development, Sybase CTO, Britton Lee, Inc. Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 2
Olliance Group, a Black Duck Company Ten years, 500+ engagements Leading global FOSS strategy development, planning, and implementation firm Business Technology Governance Community Founder and host of the Open Source Think Tank See thinktank.olliancegroup.com Acquired by Black Duck Software December 2010 Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 3
Agenda Why Use Open Source Software? How is the use of Open Source best managed? The Policy Development Process Implementation Summary and Conclusions Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 4
Why Use Open Source Software? Best-in-class software in some areas is OSS Your product must interoperate with other OSS, e.g. Linux Your customers favor or even require OSS OSS came with a corporate acquisition It is a lower cost alternative to traditional commercial packages You will need to customize externally sourced software Faster time to market by avoiding development and testing of new code Lower development costs by using free, already de-bugged code Lower code maintenance costs by taking advantage of community maintenance Your code-base already contains significant OSS Sixty-two percent of organizations surveyed indicated that their usage of open source software in deployed software portfolios would exceed 25 percent in the next 18 months. And a full 17 percent of organizations expect their portfolios to be 50 to 74 percent made up of open source software. in their deployed software portfolios. Laurie Wurster, Gartner Group, March 2011 Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 5
The Open Source Revolution Commercial Software Package Commercial Software Package OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS Negotiated Procurement OSS OSS OSS OSS OSS OSS Mostly Custom Development Download Mostly Integration This new approach creates new challenges Higher volume of code acquisition decisions Maintaining code and version consistency across an organization Managing support for many external elements Managing participation in public communities Insuring license compliance for many elements at distribution time Copyright 2011 Black Duck Software, Inc. All Rights Reserved.
Open Source Management Goal: Manage the complexity and risk inherent in the use of open source software without reducing its productivity advantages What it takes to achieve this goal Strategy and a clear understanding of objectives at the business level A Policy A Governance Process Ongoing audit and tuning Open Source Management works best when it is a natural part of the software development process "Companies must have a policy for procuring OSS, deciding which applications will be supported by OSS, and identifying the intellectual property risk or supportability risk associated with using OSS. Once a policy is in place, then there must be a governance process to enforce it." Laurie Wurster, research director at Gartner Group Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 7
What is an OSS Policy? A set of rules and guidelines for using and managing OSS in your organization An effective OSS policy must Cover all the essential aspects of managing OSS Be succinct and easily understood Reflect the way software is developed and delivered in your company Image CC Fotolia_14119067_M Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 8
Developing and Open Source Policy Step 1: Identify key stakeholders and get their commitment Step 2: Prepare for discussions Step 3: Draft the policy Step 4: Review and update the policy Identify Prepare Draft Review Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 9
Step 1: Get Commitment of the Stakeholders In most organizations the important stakeholders represent the following functions: Software Architecture, the role that specifies what elements are included in a software project Software Development, the engineers who build the software QA and/or Release Management, those responsible for checking the quality and contents of project releases Legal, who is responsible for upstream and downstream agreements and license compatibility evaluation Product or Line of Business Management, the role responsible to the business for the success of the software Organizations with sensitive data may also have a Security stakeholder, responsible for the security of software Entering the organization Being deployed or released Getting stakeholder commitment to developing an OSS policy is a critical success factor Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 10
Step 2: Prepare for Discussions Establish a shared base of understanding Collect and disseminate information about your organization's use and plans for OSS, documents such as: Existing policies or processes related to OSS Inventories of OSS currently used within the organization Existing license compliance requirements and or procedures Upstream or downstream agreements or business relationships that involve OSS New initiatives that might involve the use of OSS Current problems or issues related to the use of OSS Prepare a clearly articulated strategy for using OSS What benefits does the company most want? How will the company insure they are realized? If a strategy does not exist, it may be the first assignment of the stakeholder team Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 11
Step 3: Draft the Policy An OSS Policy is typically developed in a series of interactive meetings of the stakeholders Many companies have found that using a facilitator with experience in OSS policy and its operational implications can speed the results An OSS policy should address the following elements: 1. Program administration and management 2. Discovery, acquisition and evaluation 3. Review and approval 4. Software procurement 5. Code and documentation management 6. Support and maintenance 7. License compliance 8. Community participation Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 12
Policy Detail: Program Administration Who will be responsible for the policy itself? Who will oversee the OSS management program? Most companies define some additional rolls, as well OSS component owner Review and approval decision authority Is the policy is confidential or shareable, and how it will be published? Training policy is a critical implementation success factor Review and update plan Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 13
Policy Detail: Discovery and Evaluation Where the most leverage exists in OSS management Engineers will be much more effective in choosing OSS when they have evaluation criteria and guidelines to work with Class of use Architectural compatibility License compatibility Will the component need to be modified? Quality of code Stability and maturity of code Security evaluation Quality and completeness of documentation Availability of support Activity level of the community or health of commercial support vendor Maturity of project and its originating community IP risk evaluation Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 14
Policy Detail: Review and Approval No process can be considered reliable unless it is checked Specifies how an OSS component evaluation is reviewed and who may approve it for a given use Typically a policy establishes an OSS Review Board, typically including Architecture Software development Product management Legal A simpler approval cycle may be established for Reuse of an already approved component Approval of a new release of an already approved component Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 15
Policy Detail: Software Procurement Much OSS enters companies through third-party software deliveries These are subject to the same license compliance requirements and operational risks as downloads An OSS policy should provide guidance to procurement Require suppliers to report each OSS element embedded in their deliverables Whether it has been modified Its license Its license compliance terms For code that will be re-distributed, the policy may require A warrantee and indemnification, or Code scanning to verify the contents and compliance terms Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 16
Policy Detail: Code and Doc Management Specify how to managing the operational risks that come with OSS Hundreds or even thousands of outsourced OSS components Multiple versions in multiple deployments Policy should specify that Archives are created for each OSS component, including Source code Build files Documentation License declaration All internal modifications must be tracked Bug fixes are shared among all applications/users All uses of a given OSS component are tracked For addressing vulnerability reports For sharing bug fixes Identify all OSS used in a given application or system For producing lists of compliance requirements for a distribution Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 17
Policy Detail: Support and Maintenance Open Source from communities is typically under a selfsupport model Policies typically require specification of a support plan at time of component approval Policy should require identification of a responsible party for Tracking security vulnerabilities and bugs Notifying other users of the component within the organization Applying fixes as necessary Evaluating new releases and deciding whether to adopt This role is typically called a "Component Owner" or "Code Owner" within an organization. Where commercial support is purchased for an OSS Component, the Owner is typically the support contact for the organization. Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 18
Policy Detail: License Compliance Fundamental: the company will acquire and use OSS in compliance with its licenses For software that is not distributed, this is simple For distributed software a compliance regimen should be specified Audit to insure a correct component list for each release Identify OSS license obligations for each component Identify customer obligations regarding OSS Verify each obligation is met before each release Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 19
Policy Detail: Community Participation An OSS policy should specify: The kinds of community participation permitted (or required). The possible levels of participation include: No community participation Participation only through a commercial intermediary Participation from personal account with no organizational attribution Participation with organizational attribution Presentation at conferences Contribution of bug fixes Contribution of documentation Contribution of new functionality Creation of a new OSS project The standards and controls for each allowed level of participation The company's strategy for using OSS and its business goals should dictate the kinds of participation allowed by the policy Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 20
Step 4: Review and Update the Policy Produce a draft policy document Circulate for review of the stakeholders Two or three iterations are typical Update draft on each revisions Seek approval of stakeholders and other required executives Plan to review and update policy at regular intervals, typically On completion of initial implementation Annually thereafter Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 21
Implementation The next step is to implement the policy through a set of processes Good processes facilitate both efficient software development and effective OSS management, making it easy to "do the right thing." These process must also contain adequate checks to make sure that the OSS policy is consistently followed Training is a key success factor for OSS Management implementations For all participants in the policy and processes Even the best-intentioned individuals cannot follow rules and processes they don't know and understand Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 22
Summary and Conclusions There are many compelling reasons to use open source software, but this use entails new risks that must be managed An OSS policy is your primary specification for managing your OSS use There are four proven steps to developing an OSS Policy Step 1: Identify key stakeholders and get their commitment Step 2: Prepare for discussions Step 3: Draft the policy Step 4: Review, update and approve the policy The dimensions of an effective OSS Policy are well understood and proven best practices exist An experienced facilitator can increase the speed and improve the quality of this development process Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 23
Contact Us For questions about this presentation Greg Olson Sr. Director, OSS Management Olliance Group a Black Duck company golson@olliancegroup.com 650.493.3800 x207 For general information Andrew Aitken SVP & GM Olliance Group a Black Duck company andrew@olliancegroup.com 650.493.3800 x301 Copyright 2011 Black Duck Software, Inc. All Rights Reserved. 24