The appeal of free and open source software is undeniable - after all, who doesn't want to take advantage of OPM (other people's money) to develop a finished software product or platform that would otherwise require long lead times, dedicated programming resources and significant cost?
26 helpful open source network management tools
Indeed, judging by the explosive growth of free, open source software (FOSS) initiatives, organizations are lining up like followers of the pied piper to take advantage of products they did not have to pay to develop, which can be put to use immediately. Or at least as soon as the in-house developers get a handle on the code base and customize the package for the company's needs.
And did someone mention perhaps the need to see if there are any maintenance costs, license restrictions, security risks, or if the adoption of open source code could have any impact on the company's intellectual property? Hidden costs, licensing issues and other risks can create unexpected roadblocks for commercial enterprises.
Perception vs. Reality: "Free" and "Open" -- with a few strings attached
The business case for open source software at first blush can seem compelling. Finding an open source application that seems to closely match a company's needs can be a little like discovering hidden treasure, and some jump in with few questions asked. But the reality is that the "free" part of FOSS often ends up meaning just "free to download," as the costs to actually deploy the application or platform may in fact be substantial. And "open" is subject to interpretation, under seemingly simple licensing terms that may turn out to be difficult to interpret legally.
The overarching concept for the mainstream open source licensing model is to allow the free use, modification and redistribution of source code developed (or modified) under the license, so long as any derivative works are released under the same license, with the same notices, rights and access to the source code. The Open Source Initiative (OSI), a California non-profit advocacy group for open source software, has established specific requirements that it maintains must be met for compliance with the industry-supported Open Source Definition (OSD).
A number of licenses have been approved by the OSI under its licensing review process. These include familiar names and acronyms such as BSD, Apache, CPAL, GPL, MIT and many others. Yet there are an untold number of licenses that have not been approved under the OSI licensing review process, either due to non-compliance with the OSD, or perhaps simply because the vendor does not subscribe to the approval process. In any case, licensing terms vary considerably from license to license. Some software vendors playing fast and loose with the rules have slapped an "open source" label on software that in fact turns out to be a "free to download and use" version of proprietary software that cannot be altered or distributed. It's all in the licensing fine print, and this is where the first important tenet of open source risk management comes into play.
1. Understand the license and any restrictions
Almost all open source developers retain the copyright to their work. Therefore by definition, open source licenses are limited in scope and full ownership can never be claimed by others, except in circumstances such as a merger or acquisition of the copyright holder's business, where a legal transfer of ownership rights would be conveyed by contract. The rule limiting ownership rights applies under almost every open source license, no matter how extensively the code is altered by downstream developers.
Licenses attached to open source projects may also be restricted by use. There is an increasing industry trend to restrict the CE (community edition) of an open source product to a small subset of users, perhaps defined by a single domain, single server or for academic use only. The obvious goal of these restrictions is to reserve the CE for a very small user base, while driving most commercial users to the vendor's closed-source offerings.
The best way to avoid licensing problems is to read and understand all licensing terms and restrictions before deploying the product. If licensing terms seem unclear, it may be wise to seek a legal opinion.
2. Understand the business model of open source
Creators of open source software tend to be altruistic types by nature, and may contribute thousands of hours to a project, sometimes earning less than minimum wage (if they are paid at all), just to donate software for the common good. But keep in mind that most of these talented developers aspire, at least eventually, to profit in some way from their work. The "for profit" model can be pursued in a number of ways. The primary road to profits is through the sale of software support and customization, and driving customers steadily toward the commercial, closed-source version of the product.
This explains why the open source version of some products may offer complex installation routines, confusing or incomplete documentation, and technical support so incoherent or indifferent that users quickly realize that if they need actual help they will have to pay for it. One FOSS vendor, instead of supplying useful answers to support questions, shamelessly informs hapless users that he can help them for a starting fee of just $80.
Larger, established open source projects usually have a commercial customer base adequate enough to obviate the need for such gimmicks, but even with an established open source product, when the app or upgrade crashes your web server and you need immediate assistance, without a paid support plan you are still on your own. This means that FOSS adopters must supply their own subject matter experts, sometimes to the tune of hefty salaries or high hourly rates. As a result, some companies have adopted strict policies against using the community version of any software product, opting instead for the safety net and predictable cost provided by the vendor's commercial support plans.
How much customization and at what cost?
Organizations who adopt FOSS products frequently discover the need to customize the software to meet specific needs or to comply with enterprise policies. For well-established content management systems such as Drupal, Joomla or Word Press, adding new pages and changing the overall look of the application can easily be accomplished by a power user having few or no programming skills. However, once customization needs go beyond the built-in interfaces provided by the vendor, advanced programming skills are typically required to make changes. If staff programmers are not up to speed with a particular open source app, the organization finds itself facing the costs of both learning curve and customization, resulting in additional expense and delays.
3. Factor in increased security risks
Reports surface almost daily pointing out the security loopholes in open source projects, some of them quite serious. Factors that increase the security risks with open source:
• The source code is readily available for hackers to analyze and exploit, thus increasing the attack surface of the product
• Vulnerabilities reported by users on public support forums are also open to scrutiny and exploitation
• Users who install open source using default options frequently fail to implement even rudimentary security precautions, such as changing the default password or removing the install directory which may point to sensitive database or network information
• Because of the community development of open source projects, inadequately screened third parties may be allowed to submit add-ons or even make changes to the production code base, hiding viruses or root kits that can spread quickly and infect many customer systems before the vendor can discover them and fix the problem
• The CE version of a FOSS product provides no guarantees as to the timing or adequacy of security fixes, or any recourse for customers on the receiving end of an exploit
To be fair, no software is ever released totally free of security vulnerabilities and FOSS vendors usually rush to close security holes as soon as they are discovered. Still it is important to factor the increased risks into the decision-making process and take steps to close as many security holes as possible by changing default installation directories and passwords, hardening or even isolating severs hosting open source content, and repeating the same process for any database components. If taking these steps does not produce a code base that complies with corporate security policies, you may need to switch to a commercial, closed-source license.
4. Beware of the potential impact on intellectual property
While No. 4 on this list, analyzing the impact of FOSS products on intellectual property may in fact weigh in as the No.1 consideration for corporate decision-makers. "It's all about copyrights," says independent intellectual property expert and attorney Jill Bowman. "Incorporating open source can dramatically affect the value of intellectual property and may diminish or destroy the value of the product that incorporates open source." Among the legal hurdles she cites:
• Open source licenses written colloquially, with the original intent of conveying clarity, may actually be more difficult to interpret legally.
• Performing due diligence and tracking genealogy is more challenging on a code base that may contain multiple authors and open source licenses.
• Open source licenses raise serious legal questions about how and under what terms, or even if, the licenses may be assigned.
• Difficulty in determining the compatibility of multiple licenses contained in a single product, and ensuring that the outbound license doesn't convey more than the inbound license
"It's really a matter of choosing the correct open source license," Bowman says. "Buying a commercial license can solve many of the legal issues."
Despite its challenges, FOSS has been shown to offer substantial benefits for organizations under a great variety of business models. The key to successfully managing open source is to fully explore not just the benefits, but also the risks and hidden costs, preferably before committing substantial time and resources to open source initiatives.
Perschke is co-owner of two IT services firms specializing in web hosting, SaaS (cloud) application development and RDBMS modeling and integration. Susan also has executive responsibility for risk management and network security at her companies' data center. She can be reached at susan@arcseven.com.
Read more about software in Network World's Software section.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.