eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Over the past decade, I’ve served as CTO of three different Fortune 500 companies. In each of those companies, one of my primary responsibilities was to mitigate risks associated with technology. During the same period, open-source software has gained growing acceptance in the enterprise. Properly sourced, open-source software can bring so much to the table: lower cost solutions, high-quality software and all the other benefits that come from active and altruistic developer and user communities.
However, there is a long-established, risk-averse mindset within many large companies. Companies have established software procurement practices which depend upon an interaction and relationship with a vendor. This has slowed the adoption of open-source software which, similar to commercial software, still has to be adopted under certain guidelines.
A few short years ago, I worked with a company that had a “no open source” usage policy. Fast forward to today, where average Fortune 500 companies are using more than 100 open-source projects each. Some companies are more conservative than others, but I still see four basic phases of open source adoption in corporate America:
Phase No. 1: No awareness
There aren’t many of these companies left, and when you do find them, they tend to be smaller organizations. They don’t yet know what open-source software is used in their organization and they certainly haven’t developed any policies regarding it.
Phase No. 2: Denial and prevention
These companies often are risk-averse. They have yet to try to understand how open source works or do a risk-benefit analysis. They realize that open-source software could contain risks, so they ban it outright or put huge barriers in the way of developers who want to use open source.
Phase No. 3: Limited, safe usage
This is probably where most companies are today in the adoption of open source. Enterprises start by getting Linux from a large, trusted source such as IBM or another enterprise vendor. The vendor provides key services including indemnification and support.
Phase No. 4: Smart governance
The optimal phase of open-source software is where enterprises use open-source software in accordance with policies and architecture blueprints. In this phase, companies realize that they need to put the same processes and controls in place for open-source software as they have with proprietary software. These controls enable companies to gain the benefits of open source while mitigating risks.
As companies move towards “smart governance” of open source, they will need to address several gaps that exist between open-source software and the proprietary software they are used to. Luckily, there are now a wide variety of vendors that wrap open-source software with a set of offerings that help enterprises close these gaps.
Tips for Using Open-Source Software
Five tips for using open-source software
Over the past decade, I’ve come to see what makes open-source software thrive in an enterprise. Simply put, once enterprises put in place the same governance, policy and support processes around open-source software as they do with proprietary software, there is no limit to how much open-source software they can bring into their organization-or how much money they can save.
Here are five tips on how to close the gaps and allow open source to come into your organization in a way that maps to your corporate risk factors, making open-source software no more or less of a risk than proprietary software:
Tip No. 1: Service-level agreement (SLA) support
One of the greatest things about open-source software is that it is backed by an active and responsive community. However, like many CTOs and CIOs, I don’t like uncertainty and will pay to mitigate risk. When it comes to mission-critical software, you can’t guarantee that the community will provide support in the time period you require. Whether you download software or buy it from a commercial open source vendor, you need to have SLA support contracts. Support is available from several commercial open source vendors.
Tip No. 2: Indemnification
Lawsuits happen in the software industry, whether it’s proprietary or open-source software. Some legal actions you hear about, some you don’t. It is critical, especially if the software you are using is important to your business, that you have indemnification to protect you from legal actions that could preclude you from further use. Indemnification is available from many of the commercial open source vendors.
Tip No. 3: Open source licenses: compliance or violation
One of the key differences between proprietary and open-source software is the license used. Each organization has its own risk threshold that dictates which open source licenses it allows into its organization. Once you’ve decided that a particular open source license is allowed, you still must comply with the license. It’s important to have processes to ensure compliance with open source licenses-just as you would with proprietary licenses. Your legal department can guide you in understanding license obligations and ensuring compliance.
Tip No. 4: Procurement
In the early days of enterprise open source adoption, we were looking for open source projects that were bits of code we could embed into larger solutions. Today, we see open-source software transitioning into full-blown open source solutions. As the open source community continues to develop full-featured solutions, it becomes imperative to have a procurement process in place that ensures you are selecting software from mature and active communities. Just like you need to evaluate viability of a software vendor, you need to evaluate viability of a community or open source project.
Tip No. 5: Governance
Lastly, you need to develop and enforce a comprehensive governance program that tracks your open-source software from the cradle to the grave. What are your policies for allowing software into the organization? Who will approve it? How do you track when and where software is used? What are the conditions by which you will look to retire or replace the software? How can you assure that the use of the software conforms to your interoperability requirements? You can build your own processes and tools, or there are several vendors that provide open source governance or management platforms to automate this process.
Carol J. Rizzo is a technology consultant with more than 25 years of health care and financial industry experience, having served as CTO of Kaiser Permanente, AIG and CitiGroup. Currently, Carol is consulting software companies in the health care, financial and media industries. She has managed a variety of technology functions including infrastructure operations, engineering, interactive software development, product development and telecommunications. She can be reached at caroljrizzo@yahoo.com.