Open Source Best Practice Tips  

Enterprises can learn from shared experiences and insights on the best ways to manage and maximize the value of open source deployments. OLEX provides you with best practice tips, resources, and recommendations to implement in your organization.

Tip: Define Procedures for Open Source Support

Enterprises today have deployed a wide range of open source software for uses ranging from development environments to mission-critical production applications. As a result, enterprises typically have varying needs when it comes to technical support for open source. Some open source package deployments may necessitate 24x7 commercial-grade support, while other deployments may require nothing beyond the mailing list support available on most open source project websites.

Although support procedures may differ depending on the open source package, an enterprise open source policy should address all possible options and scenarios to ensure that technical personnel correctly utilize the available resources when support is needed. For example, if technical personnel are permitted to seek support assistance through open source community mailing lists, the enterprise policy should provide guidelines that prevent employees from divulging confidential information. The policy should explain which community sites are acceptable, the types of issues that can be submitted to mailing lists, any restrictions on information that can be revealed, and procedures for escalating issues that aren't resolved through mailing lists.

For open source packages that require commercial-grade support, the open source policy should outline the processes for purchasing support incidents, list any preferred support vendors, and detail the procedures for submitting issues to support vendors. If component-level support contracts are purchased from diverse support vendors, the open source policy should also outline procedures for escalating integration problems that may involve more than one support vendor. Similarly, the open source policy should establish procedures for internal knowledge-sharing so that different teams within the enterprise can benefit from the lessons learned by others using the same open source packages.

Tip: Work with Legal Personnel, Not Around Them

Developers know open source software better than anyone else in the enterprise, but most will readily admit that they're not legal experts. However, in some cases developers create open source policies--either formal or informal--with little or no input from legal and compliance personnel for fear of slowing down or complicating the process. But getting legal and compliance personnel involved up front can prevent disruption later on and greatly reduce potential risks to the enterprise.

Legal and compliance personnel are essential when it comes to addressing the potential impacts of using different open source licenses. In addition, they can help ensure that the policy covers all aspects of enterprise open source usage including acquisition, usage, and contributions. By working together, developers and legal personnel can develop a strong policy that addresses all aspects of open source in the enterprise and that everyone can agree on.

This best practice topic was discussed by a panel of enterprise open source thought leaders at the 2007 OSBC conference in San Francisco. Some notable comments on this topic include:

• Jon Stumpf, AIG: "The policies that you need to create need to address three distinct buckets: the acquisition of the technology, governing what you will do with open source technology inside your company, and the rules by which you will give back to the community."
• Tim Golden, Bank of America: "You need legal advice through all of this. If you have a bunch of technologists sitting around creating a policy and they think they are doing the right thing and they think they are acting on behalf of the legal department, when you actually go to enact the policy, the lawyers are going to show up and you're going to slow down. Have a process where lawyers are engaged, early and often, and you usually have a much better outcome."

Tip: Leverage Existing Processes and Ensure Scalability

Effective open source policies determine the process by which open source software is selected, approved, and deployed within the enterprise. Repeatable, scalable, and easy-to-follow processes ensure consistency in open source adoption and prevent use of non-approved open source packages.

While open source software is different than commercial software in a variety of ways, the processes that dictate its intake and usage don't have to be unique. Existing processes should be leveraged whenever possible to prevent confusion and unnecessary overhead. Subjecting open source software to existing processes can also save time during policy formation and help uncover improvements that should be made to those processes.

This best practice topic was discussed by a panel of enterprise open source thought leaders at the 2007 OSBC conference in San Francisco. Some notable comments on this topic include:

• Jon Stumpf, AIG at OSBC 2007: "In dealing with the minor variations that open source brings, the majority of the processes you're supposed to have will suit you well when bringing new technology in. We don't have a specific open source review board.... We forced open source into the processes that we had. Looking at open source as being a technology that will flow through these processes will tend to expose gaps or deficiencies in the processes you have for closed source. It actually helps improve those processes. Using the processes we had was more cost effective."
• Tim Golden, Bank of America: "I don't think we can emphasize enough: open source software is the same as proprietary software in almost every way except your relationship to the software. You can use almost every existing process that applies to software and some lifecycle management within any kind of a company."

Tip: Create Policies That Support Culture & Sharing

Enterprise open source policies are essential for minimizing potential legal risks, ensuring consistency with sourcing and selection, and enabling efficient tracking and auditing. While these are important aspects of enterprise open source policies, it's also essential to consider corporate culture and knowledge-sharing processes when formulating or revising your policy.

Open source policies are only as effective as their adoption, and policies that run counter to the corporate culture are bound to be less effective. Similarly, it's important to create processes that foster knowledge-sharing so that personnel can easily collaborate, which helps to reinforce the corporate policy.

This best practice topic was discussed by a panel of enterprise open source thought leaders at the 2007 OSBC conference in San Francisco, and it's also a topic that Attorney Jason Haislmaier recently addressed on his Thinking Open blog. Some notable comments on this topic include:

• William Hurley, BMC at OSBC 2007: "I would say the most important thing around policy is having some sort of central repository for all of this knowledge and information that is easily accessible so you have a policy that empowers the individuals to adopt open source and drive things forward."
• Attorney Jason Haislmaier on his blog: "An open source policy, like any company policy, should be tailored to the company. Certainly this means that the policy should be designed to work within and leverage the existing organization and structure of the company. It also means taking into account the business, competitive and regulatory environments in which the company operates. Perhaps more importantly, any open source policy should also be drafted to fit the unique culture of the company. If the company is one heavily oriented around policies and procedures, then the open source policy can follow suit and include greater levels of detail. However, if the corporate culture is not one to adopt and follow rigorous policies in other areas, the open source policy should not try to break this mold. The idea is to prepare a policy that fits the corporate culture in which it will be implemented--and this idea is often the key to the successful adoption of the policy."

Tip: Make Open Source Approval Criteria Repeatable

Repeatable approval processes give technical personnel the confidence that their approval requests will be handled consistently and in a timely fashion, making it less likely that individuals will go around the process and introduce unapproved open source packages.

In addition, re-using your approval criteria will save you time, by allowing you to quickly approve or reject requests based on previous decisions.

This best practice topic was discussed by a panel of enterprise open source thought leaders at the 2007 OSBC conference in San Francisco. Some notable comments from this discussion include:

• Tim Golden, Bank of America - "A [open source policy] review board has to learn to templatize their behavior. If they've done a pattern once, then that pattern has to be wholly applicable to everything that comes afterward."
• William Hurley, BMC - "You also should have a way of keeping track so that you don't get a lot of situations where the same thing is created over and over again."

Tip: Treat Open Source Like Proprietary Software

Open source software differs from proprietary software in the way it's licensed, developed, and distributed, and these differences often affect the way it's perceived by enterprises. However, open source can provide enterprises with increased cost savings, improved functionality, and greater flexibility than proprietary software. In order to weigh the benefits of an open source package against comparable proprietary software applications, it should be evaluated using the same criteria.

This best practice topic was discussed by a panel of enterprise open source thought leaders at the 2007 OSBC conference in San Francisco. Some notable comments from this discussion include:

• Jon Stumpf, AIG - "What I think is most important is to just recognize open source as being no different than closed source technology coming in the door. It's all about license, compliance and understanding where you can deploy technology. In dealing with the minor variations that open source brings, the majority of the processes you're supposed to have will suit you well when bringing new technology in."
• William Hurley, BMC - "Software is software is software. There is absolutely no difference in managing the proprietary use of software within your company than there is the open source. You have the same issues of scale, interoperability, licensing and so on and so forth."
• Tim Golden, Bank of America - "I don't think we can emphasize enough: open source software is the same as proprietary software in almost every way except your relationship to the software. You can use almost every existing process that applies to software and some lifecycle management within any kind of a company."