Home | About | Recent Issue | Archives | Events | Jobs | Subscribe | ContactBookmark The Sterling Report


    

What phase of the product lifecycle will the enterprise software industry be in by the year 2017?

Introduction

Growth

Maturation

Decline


Guidelines for Mitigating Risk with Open Source Governance

By Steven L. Grandchamp, CEO, OpenLogic, Inc.

It’s an all-too-common scenario: A programmer at a Global 2000 organization faces a looming deadline. After some research, he selects an open source software package that meets his technical needs and will allow him to get his job done quickly and efficiently. He downloads the selected software and goes to work, unaware of the potential implications of his choice. As in the scenario above, open source software often comes into an organization with no further consideration than whether it can do the job at hand. While open source software provides a funtional, flexible and cost-effective option for enterprises, there are issues to consider that can have a significant impact on a business.
How will we get support for this?
Will we be able to get the service levels we need for support?
How might the license impact our company?
What will we need to do to stay in compliance with the license?
What IP protections do we need to put in place?
Will the project still be active over the years to come?
How will we manage potential changes to source code?

Making Open Source Successful in Your Organization
Many companies are simply not aware of the extent of their open source usage. Most open source packages are downloaded by programmers, bypassing the normal controls of the procurement process, coming in through ‘the back door’ of IT. Unbeknownst to some enterprises, they have dozens to hundreds of open source solutions in use without an appropriate level of review.

Creating an effective policy to govern the adoption and use of open source in your organization will mitigate potential legal, financial and operational risks and is a critical step towards making open source successful in an organization.

An open source policy establishes a framework for communication between business management, legal teams, IT managers and developers about how open source will be deployed in their organization. A policy can help direct and monitor IT plans by ensuring that investments in IT generate the desired business value and ROI. When a policy is enforced, it will mitigate and manage legal risks, including intellectual property infringements and license violations. And finally, a policy ensures that companies can continue to meet operational cost and uptime requirements whenever open source is deployed.

You Don’t Get Something for Nothing
When creating an open source policy, consider the choices your business may face in balancing risk reduction with business demand. Keep in mind that software is software. All software – both open and closed source – comes with responsibilities and requirements that businesses can’t ignore. Management needs to devote resources to developing, deploying, managing and supporting software assets. And, although you can cut costs significantly by moving to open source solutions, you will need to invest in open source governance to avoid unnecessary legal disputes, unexpected costs and unforeseen operational issues. The software may be free, but you need to be vigilant about what you’re using and how it’s being used.

How Open Source Differs
Although open source software is ‘just software,’ there are some critical differences to consider for governance purposes:

1. Know Your Open Source Licenses
The most popular open source license is the GNU Public License (GPL). In addition, there are over fifty open source licenses approved by the OSI (Open Source Initiative) and various other licenses that have not been approved by the OSI. In each case, your legal staff must familiarize themselves with the terms of the license being considered to determine whether it is compatible with the use that your enterprise is planning. You will also need audit and control processes to essure that your organization complies with all of the terms of the license.

2. Protect against Intellectual Property Violations
Because open source software is typically created by several independent authors, there is some risk that an author might have infringed on another’s intellectual property. There have been a few highly publicized lawsuits around such intellectual property infringements, and – though many are without merit – companies that use open source are concerned about the costs of potentially defending these suits. Fortunately, there are several open source solution providers that offer indemnification for the open source software packages they support, giving companies some financial protection in the case of a legal action.

3. Have the Appropriate Procurement Processes in Place
Your worst enemy is a recurring ‘don’t ask, don’t tell’ situation where developers assume that using a minor open source component does not require approval. Sweeping the acquisition of open source under the table to speed development will impede overall knowledge of what your organization is using and how to best leverage your open source tools.

Governing Your Open Source Software Usage
The following points will help you reap the benefits of an efficient, scalable open source policy:

a) Before You Can Manage, You Must Measure
The first thing to recognize when creating your policy is that you’re probably already using open source. However, you can’t manage it if you don’t know about it. Start by performing an inventory. There are free tools that scan multiple computers for open source components and provide an inventory of what’s installed.

b) Mitigate, Rather than Eliminate Risk
Just as with traditional proprietary software, you can’t expect to eliminate all risk associated with open source software. Instead, evaluate the level of risk you’re already carrying and the level you are willing to carry. Make informed choices about acquiring open source based on a risk assessment.

c) Governance is Ongoing
Like any compliance program, open source governance is not ‘once and done’. Once you have identified and inventoried the installed open source on your system, keep up-to-date audits for posterity and upper management. Your policy will need to evolve over time, so establish the appropriate processes for doing so.

Write an Effective Policy
Now that you understand how your organization uses open source, you can follow these steps to draft a clear and efficient policy to govern its use:

1. Define Objectives and Strategy
Be pragmatic. Ask yourself: What are the legitimate concerns here? What are my organization’s goals? Where do these intersect? You can develop specific procedures and controls that are case specific based on your answers. Don’t be afraid to focus on the bottom line. IT teams need to know that business goals are not only driving development, but your open source policy as well.

2. Divide Policy into Three Distinct Areas
Your policy should address three distinct areas: The acquisition of open source, what you do with open source within your organization and the rules by which you interact with the open source community.
  • Acquiring Open Source
    Determine guidelines for reviewing and adopting open source software and then apply these rules to your whole organization. Find a balance between too much and too little control. For example, your policy might allow developers to download open source software for evaluation and experimentation, but require approval when it is chosen for use in a production application.
     
  • Using Open Source
    Determine guidelines for the level of risk you are willing to carry and decide under what circumstances developers are allowed to change and modify source code. You will also need audit and compliance processes to ensure that the approval process is being followed and that you are complying with the terms of the open source license.
     
  • Interact with the Community
    Ask yourself how your organization will converse with the community: Will you be active forum participants, contributors, evangelists? If you choose to become a contributor, make sure that all levels of your organization are on the same page when it comes to community attitude and interaction.
3. Are You Using Linux?
Many companies find Linux to be the gateway to other stable open source projects, and structure their use of open source around their policy for Linux. If you’ve already deployed Linux in your company, determine whether all or part of that policy can be expanded to open source in general.

4. Bring on the Lawyers
You will need adequate legal advice when you create and implement your open source policy. They can ensure that your policies are based on specific license types and versions and research common legal problems that have surfaced in the past.

5. Don’t Hide Your Policy
When your policy is complete, make it known. Identify a central repository for all of the knowledge and information you gather: It’s one of the most important things you can do for successful open source governance.

6. Software is Software
As mentioned earlier, software is software. You’ll save time by creating an open source policy that mirrors whatever guidelines are already in place for reviewing, managing and governing proprietary software. By measuring open and closed source solutions with similar metrics, you’ll maintain consistency in your overarching software policy.

7. Find or Create a Library
One of the top challenges in evaluating open source in the enterprise is ensuring that the code comes from a trusted, stable source. By implementing a central library or repository of vetted open source projects, you can reduce risk and be assured that you have mature, tested and proven open source code. Some open source solution providers provide subscription access to pre-screened, supported, certified open source code repositories – an attractive choice for many enterprises.

Conclusion
Creating a policy for governing open source in your business requires diligence, communication and ongoing maintenance. Once you’ve developed an effective, scalable policy, you can incorporate it into your daily development and management practices and into your company culture. Your policy will determine how your business adopts, uses and contributes to projects and the larger open source movement and will establish lines of communication for constant feedback from programmers. In addition, opening channels for feedback between business management and IT development teams will keep open source usage in line with business objectives and responsive to development goals.

The bottom line: Remember that the amount of risk you carry doesn’t depend on presence of open source in your business, but on how well you understand and manage it.



Steven L. Grandchamp is CEO of OpenLogic, Inc, a provider of software, stacks and services that help enterprises to maximize the value of open source software. He has over twenty-five years of experience in the software industry, where he has served in executive roles for both vendor and IT customer organizations. Steven was formerly President and CEO of Information Management Research where he led the company’s move into Enterprise Content Management. Prior to that, he was Vice President and a principal shareholder at American Fundware, responsible for the company’s software development effort. Steven was also a Founding Partner of Formation Technologies Inc, a software company for the banking industry that emerged as a leader in the loan origination segment. He also held various senior management positions with Microsoft, including the application development segment of Microsoft Consulting Services. Steven spent the early part of his career in progressively responsible IT roles in the banking industry. For article feedback, contact Steven at steve.grandchamp@openlogic.com 


Click to email this article to a friend     Back



Back




  Home | About | Recent Issue | Archives | Events | Jobs | Subscribe | Contact | Terms of Agreement
© 2006 The Sterling Report. All rights reserved.