Open Source: Swimming with the Tide

You may not know it, but somewhere in the recesses of your organization, a team of software developers is probably creating a critical application using one or more types of open source software. Perhaps it’s Linux or Apache two of the most popular open source options widely deemed to be safe, or perhaps it’s a little-known utility designed to track issues during the software process or provide strong cryptography for the Apache Web server.

Experts believe that virtually every organization uses open source software in some form or another, and the use regulated or not will continue to grow as it becomes more accepted and less feared. In fact, Linux alone, arguably the most popular open source code in use today, has grown exponentially and will continue to grow at a rate that outpaces many proprietary operating systems, according to International Data Corp. of Framingham, Mass (a sister company to CIO.com’s publisher CXO Media Inc.).

Given these realities, CIOs and their executive counterparts must not only recognize the inevitability of open source, but educate themselves and their team members on what constitutes open source. Once they have surveyed the field, they must then decide what they consider acceptable use of open source within the organization and find a way to monitor its use on an ongoing basis. Failure to do so will not only lead to chaos within the organization, but may even lead to legal issues and loss of intellectual property.

Open Source 101

Although many executives think of all open source software as relatively equivalent in terms of safety and use, there are actually three main categories of open source software, each with its own benefits and challenges.

The first category, Tier 1, consists of “Best of Breed” open source offerings. This category includes products like Linux, the Apache Web Server, Samba, the Mozilla Firebird browser, and the Perl scripting language. These products, widely tested and largely believed to be virtually risk-free, are commonly chosen for their technical strengths. Most consider these products to be safe, and many companies today use them with few problems. In fact, many consciously choose such products over commercial proprietary alternatives regardless of price.

Tier 2 consists of somewhat lesser-known products that have achieved a large degree of recognition for their quality. One example is MySQL, a database that frequently competes with powerhouses like Oracle and SQL Server. Other examples include Jboss, CVS and OpenOffice. In most cases, stable releases are available with accompanying documentation, and in many cases, support and other services often are available. However, not all of these products have achieved dominance or technical superiority over commercial proprietary competitive products. Some users of open source follow the rule of thumb that if you can buy a book on the product from Amazon.com or a similar bookseller, it’s probably mature enough to use within the organization. If software in this category suits your needs best, it may be worth considering.

The third tier contains virtually everything else. This tier, clearly the broadest, also holds the most appeal for the developer, who may reason that he or she will save time by using the code. In many cases that’s true-but it also poses more risk to the organization, should the code fail or support be difficult to find.

Although open source is here to stay, there are challenges that may impact your decision on whether to use open source software-or how to limit the types of open source software you allow into your organization. These challenges include:

• Open source is not warranted, although warranties can sometimes be obtained from third parties.
• Depending on the popularity of the open source tool, qualified developers can be hard to find.
• Open source license terms require careful study to ensure compliance. By modifying the code without reading the licensing terms carefully, for example, you could put your organization in a situation where your “proprietary” software is no longer proprietary.
• Documentation can be substandard, especially in Tier 3.
• Hidden costs may arise. Although many focus on the lack of licensing fees when deciding to move toward open source, users may incur a variety of hidden costs, such as training or hiring competent software developers to support and maintain the code, application availability and performance issues. To mitigate these issues, make sure you consider the entire Total Cost of Ownership before making your choice.

Many of these challenges may seem insurmountable, especially if your management team tends to be somewhat risk-averse. However, in many cases, the benefits can outweigh the risks. Benefits include:

• Access to source code.
• Lower costs, due to the lack of a licensing fee and the highly configurable, reusable nature of the code.
• Quality and security advantages due to extensive peer review of source code over time. The law of large numbers applies here. If, for example, 1,000 people have looked at a piece of code, it is likely to be of higher quality and more secure than code examined or used by ten developers.
• Freedom to redistribute or replicate software without incurring additional costs.
• Continued innovation by large communities of users.
• Conformity with open standards.
• Excellent support and documentation for Tier 1 open source products.

Creating a policy

Based on a careful evaluation of the pros and cons, the next step is determining what you’ll allow to be used within the organization and what is unacceptable. To convey your rules and boundaries clearly, develop a comprehensive policy document on open source usage that is reviewed and updated regularly. This policy should clearly outline what is acceptable and what isn’t-and what rules must be followed in each case. An effective policy will balance the risks inherent in using open source software with the very real benefits using such code can bring.

When developing your policy, consider the following questions:

• What will we gain by using open source within our organization?
• Do you believe a distributed group of highly motivated developers can produce software that is equivalent to or better than proprietary equivalents?
• Do you believe in the short to mid-term viability of open source?
• Could you operate tomorrow without using open source software?
• How technically conservative is your organization?
• From a security perspective, how do you feel about having software running on your servers whose author you can’t identify?
• Can you tolerate higher costs to ensure that a reputable brand stands behind the software you’re running, guaranteeing that it doesn’t contain any malicious security holes?

Here are several possible scenarios:

• Ban all open source software. In many cases, this is impractical, because your organization probably already relies on open source in one or more situations. If, however, your company is technically conservative, this is a consideration.
• Allow only Tier 1 open source software. Since Tier 1 software is generally believed to be risk-free and safe, some organizations go this route. Before choosing this path, however, consider the opportunity cost lost by not considering Tiers 2 or 3. For example, the opportunity costs of using Tier 1, and to a lesser extent, Tier 2, are small compared to using no open source software at all. The key is striking an acceptable balance.
• Allow only Tiers 1 and 2. This is a popular choice. Again, evaluate the opportunity costs before making this choice. And if you choose this path, make sure developers understand that they must create an approved exit strategy in case the software is too difficult to manage or maintain, or if licensing or other legal issues necessitate its removal.
• Allow all open source software, providing that the users create an adequate exit strategy. Although this provides the broadest set of possibilities, it also creates the most risk. In many cases, it’s very difficult to manage the array of little-known Tier 3 tools, so spelling out the rules explicitly is extremely important. And when incorporating Tier 3 open source software into your environment, requiring a detailed exit strategy is imperative.
• Allow all open source software, but only for internal use. Another option is mandating that open source software can be used by internal teams only when the software is used for development and other internal use. This type of policy would stipulate that open source software-or just Tier 2 and 3 open source software-should never be used for customer-facing mission-critical applications.

Finally, to ensure that the policy remains in force and that no unacceptable open source software is being used within the organization, consider appointing an open source expert within the company. This person or team is responsible for creating an inventory of all open source software used within the company, keeping on top of the latest open source news, training staff on key open software products, providing an internal communications channel for open source users to share information and experiences, reviewing open source compliance with license terms, and keeping current with the latest rulings in the area of licensing and intellectual property.

Wick Keating is senior vice president and chief technology officer at American Management Systems, Inc. Keating has more than 25 years of experience in the application of information technology. He is currently responsible for identifying technologies that will bring business benefits to AMS customers, and for driving those technologies into AMS’s system design and development activities.