How to Create an Open Source Management Policy

How to Create an Open Source Management Policy

Creating an open source software policy is a strategic imperative for organizations in the software industry. But what does a strategic policy include, and how can you implement one?

What is an Open Source Software Management Policy?

Let’s start by defining an open source management policy. It is a set of rules and guidelines for using and managing open source software (OSS) in your organization. To be effective, it must cover all the essential aspects of managing open source software, yet it must be succinct and easily understood, otherwise nobody will read it, much less follow it. My rule of thumb is that policies should be five pages or less, and reflect the way software is developed and delivered in your company specifically — general rules are not likely to apply directly to your requirements and processes, so the results are likely to be approximate and inefficient.

Open Source Management Policy Development Process

There are four key steps to developing an open source management policy:

  1. Identify key stakeholders
  2. Obtain an organizational commitment
  3. Draft the policy
  4. Review and approve the policy

Step 1: Identify Key Stakeholders

Identifying and including important stakeholders should be first on your list. These functional responsibilities may include software architects, software developers and engineers, quality assurance and release management personnel, the legal team and product and business managers. In addition, organizations with sensitive data or which may be using open source in products that transact sensitive client or customer data should include someone from the CISO’s office or other security stakeholders responsible for software entering the organization and being released from the organization.

Step 2: Obtain an Organizational Commitment

This is the most important success factor! Securing a commitment from stakeholders to contribute the time and effort to the policy and sharing an understanding of the policy’s importance can make or break your efforts. Experience shows that policy development teams are most effective when they work from a clearly articulated statement of the company’s OSS strategy, including statements of the benefits the company wishes to realize and the risks the company wishes to manage.

An effective way to solidify this commitment is collecting and disseminating information about your organization’s use and plans for OSS. Share documents that include:

  • Existing OSS policies and processes
  • Comprehensive lists of OSS currently used within the organization
  • Existing license compliance requirements and procedures
  • Any security issues associated with any of the OSS currently used
  • All agreements and business relationships related to OSS
  • New and future initiatives that may involve OSS

Step 3: Draft the Policy

Policies are typically developed in a series of meetings of the relevant stakeholders. This is where the trade-offs inherent in any policy must be discussed and resolved, and include:

  • Controlling risk vs. development productivity
  • Creating broad, simple rules vs. specific, more complex rules
  • Self-checking vs. independent checking
  • Using judgment calls vs. detailed prescriptions

To speed this process, you may wish to consider using a facilitator with extensive OSS policy development experience.

The General Counsels' Guide to Open Source SoftwareWe recommend that open source policies include the following eight elements:

  1. Program Administration and Management

    Determining responsibilities for the policy itself and overseeing the program’s management. Consider assigning tasks to individuals or creating an Open Source Management Board.
  2. OSSA-2x-100.jpgDiscovery, Acquisition and Evaluation

    Efficiently finding and properly evaluating new software packages helps avoid future problems and risks. As such, OSS policies typically recommend certain sources of code (including the code already in-house) and establish evaluation criteria for use throughout the organization. Such policies should further evaluate the need for and deployment of automated OSS component tracking tools in order to fully identify all components that an organization is using. Simply relying on engineers to report what OSS they are using and where typically does not tell the full story, as OSS enters an organization via a number of avenues and hence much may  go undetected and untracked.
  3. Review and Approval

    This policy specifies how an OSS component evaluation is reviewed and who may approve it for specified use. Typically, policies establish an OSS Review Board consisting of key stakeholders who can inform decisions, although sometimes a simpler approval cycle can be established for already approved components and reuse needs.
  4. Software Procurement

    Embedded OSS is subject to the same license compliance requirements, security risks and potential operational risks as downloaded OSS. OSS policies should require suppliers to report each OSS element embedded in their deliverables, any modifications and known security risks in addition to any license and compliance terms.
  5. Code and Documentation Management

    Policies should specify that original source code, build files, documentation and license declaration for each OSS component must be archived and all internal modifications must be tracked. Most organizations require that OSS archives are kept up-to-date with internal bug fixes and enhancements. In addition, you should also require tracking in order to generate reports identifying all uses of OSS components.
  6. Vulnerability Remediation

    Identify a responsible party for continuously tracking security vulnerabilities and bugs, notifying users of updates and applying fixes as necessary.
  7. License Compliance

    Ensuring compliance with relevant OSS licenses is a critical element of OSS management. We recommend auditing each release to verify that no undocumented or mis-documented OSS is included and that all compliance requirements are met.
  8. Community Participation

    For OSS acquired from communities, often the source of support is through community participation. OSS policies should specify the kinds of community participation permitted (or required) and the standards and controls for these activities — whether your company mandates no community participation or active participation, or some level between, articulating these expectations is key.

Step 4: Review and Approve the Policy

Circulate the policy among stakeholders for review and approval. Most organizations are able to develop a final policy document after two or three revisions.

And remember: no policy remains unchanged —   most companies will go through several rapid revisions as they gain experience during implementation, and after that, it’s useful to periodically review and fine-tune the policy.

(Revised from a 2012 post.)

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Software Licensing Decisions: Consider Dual Licensing

| Feb 23, 2017

This post was co-authored by Benjamin Rosen. Selecting the optimal model for licensing software is a fundamental determination that, if successful, may drive business, encourage innovation, and provide safeguards for valuable intellectual property rights. As a copyright holder, the owner of a

| MORE >

8 Insights, 8 Sessions: Black Duck Flight16 Legal Compliance Track

| Oct 21, 2016

This track examined strategies on how general counsels and legal firms can proactively help clients understand code integrity, identify applicable open source licenses and surface security vulnerabilities. The topics and interactive sessions were far ranging and brought many new insights for

| MORE >