How To Manage An Open Source Software

(1)

Executive Briefing:

Four Steps to Creating an Effective

Open Source Policy

Greg Olson

Sr. Director OSS Management

Olliance Group

(2)

Speaker

 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.

Greg Olson

(3)

Olliance Group, a Black Duck Company



Ten years, 500+ engagements



Founder and host of the Open Source Think Tank

–

See thinktank.olliancegroup.com



Acquired by Black Duck Software – December 2010



Leading global FOSS strategy

development, planning, and

implementation firm

–

Business

–

Technology

–

Governance

–

Community

(4)

Agenda



Why Use Open Source Software?



How is the use of Open Source best managed?



The Policy Development Process



Implementation

(5)

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.

(6)

The Open Source Revolution



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

Mostly

Custom

Development

Commercial Software Package Commercial Software Package Negotiated Procurement

Mostly

Integration

OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS OSS

OSS OSS OSS OSS OSS OSS

(7)

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."

(8)

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

(9)

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

(10)

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

(11)

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

(12)

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

(13)

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

(14)

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

(15)

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

(16)

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

(17)

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

(18)

Policy Detail: Support and Maintenance



Open Source from communities is typically under a

self-support 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.

(19)

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

(20)

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

(21)

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

(22)

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

(23)

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

(24)