Perhaps the business case for adopting open source software is an easy sell. After all, the software is free, and can be simply downloaded from the Internet and installed or customized as needed. Organizations interested in reducing the licensing fees of proprietary software, while also avoiding the penalties and legal liabilities associated with their illegal use, can definitely consider open source software a plausible alternative. However, less obvious than the cost savings but equally important are the barriers (“hidden costs”) of adopting open source software.
Open source software has created considerable excitement in the business world over the last decade. These applications, designed by groups of volunteer software developers, have the potential to break the current dominance of proprietary software and restrictive licenses for many business applications, reduce software development time and improve software quality, and most importantly, bring much needed software applications within the reach of individuals and small businesses, who cannot otherwise afford such software.8 Further, unlike proprietary software, open source software applications make their source code available for free, which can be customized to fit the unique needs of specific organizations.
Many organizations have caught on to open source software and realized significant cost savings in technology expenditure as a result. For instance, Cendant Travel Distribution Services replaced a $100 million mainframe system with a $2.5 million system running on 144 Linux servers.6 Amazon.com cut its technology expenditure from $71 million to $54 million by switching to open source applications.9 Sabre Holdings saved tens of millions of dollars by adopting MySQL, an open source database product.7 Though the basic open source software is free, the prospect of paid ancillary products and services such as hardware and consulting has motivated many erstwhile proprietary technology vendors such as Hewlett-Packard, IBM, and Sun Microsystems to embrace open source software and offer value-added services based on such software.
Table 1 shows an estimated range of the current global market share of several of today’s open source software applications. This table shows that though the open source market is large and growing for some application domains such as Web server (such as Apache), server operating systems (such as Linux Server), database server (such as MySQL), electronic mail client (such as Sendmail), and Internet browser (such as Firefox), it is lagging behind its proprietary counterparts in other domains such as client operating systems (such as Linux Workstation), office productivity software (such as OpenOffice), and enterprise resource planning (ERP) systems. This pattern suggests that there may be significant barriers to open source software adoption among some sectors of the user populations.
It is widely believed that proprietary software vendors often use fear, uncertainty and doubt to undermine and cut the market potential of their open source competitors. The objective of this paper is to reduce that uncertainty via a candid discussion of the barriers confronting open source software adoption and potential remedies to those barriers. These barriers and their remedies, summarized in Table 2, are discussed in detail.
Knowledge Barriers
Given all of the above benefits of open source software, one is left with the question: why do some organizations still spend money on proprietary software? In some cases, the answer is simply that they do not know that an open source application relevant to their business needs exists. For instance, Compiere, an open source ERP systems for small-to-medium sized businesses, may be reasonable alternatives to expensive ERP systems from SAP and Oracle, but is largely unknown among the adopter community. Equally unknown are open source business intelligence and analysis software such as Jasper Reports and Pentaho. In other cases, managers may be aware of open source applications, but may lack the knowledge required to implement and use it. Further, they may be unaware of the availability of support services or consultants who can assist with open source software implementation or the range of services offered. Unlike their proprietary counterparts, open source software projects are often run by volunteer organizations without marketing or advertising budgets, who have fewer means or resources of reaching or informing their potential adopter base.
What can organizations do to overcome this knowledge gap? Given the rapid rate of changes in business practices and available technologies to support them, it is practically impossible for organizations outside of the software domain to keep track of all available software products relevant to their operations. However, one convenient Web site they can occasionally visit to search for and download relevant applications in SourceForge.net. This Web site maintains a “living” archive of over 131,000 open source applications, along with their latest software patches and updates, covering a broad spectrum of software from specialized technical software, such as operating systems and middleware, to business applications software, such as ERP systems and point of sale systems.
Adopting new software applications is also associated with a steep learning curve, and more so in the case of open source software, given the relative lack of a support network to assist with their implementation, deployment and support. These applications vary significantly in terms of their usability or user-friendliness, from command lines to graphical user interfaces. Further, since more open source applications are newer systems relative to their proprietary counterparts, little internal know-how exists in most organizations on how to use these systems or customize them for internal needs. Open source consultants such as IBM, Hewlett Packard, RedHat, IONA, Navica, Open Sky Consulting, and Olliance, can assist with the technical and business aspects of open source implementation. It should be noted that though open source software is free, hiring consultants is not. However, consulting costs are not unique to open source software, since vendors of proprietary software include the costs of technology support in pricing their proprietary software.
Organizations interested in open source software should employ a multipronged strategy to manage their adoption and implementation processes. First, they must engage in a conscious search for open source applications that fit their needs, starting with Web sites such as SourceForge.net. Second, they should educate and train their staff members in installing, using, and possibly customizing open source applications. Consultant organizations, such as the ones listed here, can assist in this regard. Third, new technology hires can be directed at individuals who are familiar with and capable of using open source software. These hires may also spread awareness of and cross-train other internal employees less familiar with such software. Fourth, user organizations can consider outsourcing the implementation and support of open source applications to external vendors if they lack the manpower or the capability to do so themselves. This strategy can provide a quick way of overcoming the knowledge barriers associated with open source software adoption. Finally, organizations should consider sending key users to professional conferences and subscribing to trade magazines to keep current with the latest trends and events in this area.
Legacy Integration
Most organizations rely on legacy systems for mission-critical business processes such as accounting, sales, and manufacturing. These systems were created many decades ago using out-of-date technologies that do not interact well with today’s technologies, are expensive to modify, and are irreplaceable given their key operational roles in organizations.1 Naturally, organizations are resistant to discarding or rebuilding their legacy systems and prefer new technologies that can integrate well and share data with existing legacy systems. Though legacy system integration is problematic for both open source and proprietary software, the prospect of inadequate legacy integration and lack of accountability for failed integration are often key reasons for organizations to avoid open source software adoption.
Though legacy integration has always been a thorny issue, new software-based mechanisms and standards are emerging to bridge the gap between existing legacy systems and new open source applications. Such integration can be accomplished using eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP) and related Web services standards, and ServiceOriented Architecture (SOA).2 Given that open source applications make their source code freely available for building extensions and modifications, the availability of integration tools from third-party vendors is much more likely for open source applications than for proprietary (closed-source) applications. Open source consultants and support services can assist with the selection of the right tools as well as customizing internal legacy systems to integrate well with contemporary open source applications.
Forking
Because open source software is developed by independent developers or groups of developers, there is always a possibility that each person or group may create their own version of software. Starting with the same source code, if different groups do not coordinate their efforts, the new features and functionality they add may not be interoperable with each other or exhibit equivalent functionality. “Forking,” as such code variations are called, was responsible for the fragmenting of the open source BSD-Unix community in the early 1990s into FreeBSD, OpenBSD, and NetBSD camps,5 allowing proprietary Microsoft Windows to establish a dominance in the operating systems space. Similar examples can be observed for the Emacs text editor, which forked in 1992 into GNU/emacs and Lucid/xemacs, and the NCSA Web server, which forked in 1995 into NCSA httpd (discontinued since) and Apache versions. Forking is inherently dangerous because it tends to fragment the adopter and applications market, hurting each version’s ability to gain a critical mass of adopters and forcing vendors to choose between the forked versions or create and support multiple versions of their own applications. Further, many potential adopters and vendors may take a “wait-and-see” approach for a dominant standard to emerge, before buying into the open source software, thereby stalling its adoption.
Some contend that forking is a natural evolution of the open source philosophy and may even have hidden benefits. The openness of the source code encourages developers to extend the core kernel to suit their own needs, and in doing so, may add to the functionality and long-term viability of the program. But the nature of open source licenses, such as the GNU General Public License (GPL), is such that if developers want to make these extensions “official” (for example, be part of the official kernel), they will have to transfer ownership of the source code to the open source community. The advantage of this approach is that if the original developer shuts down operations or otherwise decides to abandon a forked software and move on to more promising software, access to the source code will allow other developers to step in, maintain, and build extensions to the “orphaned” code and serve customers already using the forked code. This is not possible for proprietary software, where copyright restrictions will prevent others from maintaining or developing the orphaned software. This was the case of the GLUT library used in computer graphics, whose development stopped several years ago and no further development was possible to support advances in hardware and methodologies because the original software is still “protected by copyright.”
Fortunately, leading minds in the open source movement are aware of the dangers of forking and the importance of maintaining a common set of standards that developers can use to build and extend open source code. The recent merger of Open Source Development Labs (OSDL) and the Free Standards Group (FSG) to form The Linux Foundation and the formation of Open Source Initiative (OSI) standards body are right steps in this direction, which augers well for the future of open source software. Similar standards bodies, such as American National Standards Institute (ANSI) and the Institute of Electrical and Electronics Engineers (IEEE), have been central to providing leadership to and guiding the evolution of other computing technologies such as the structured query language (SQL) interface for relational databases (ANSI SQL-92) and wireless Ethernet protocols (IEEE 802.11g). In sum, though forking does present a hindrance for open source software adoption, adopting a forked software will not necessarily endanger business operations even if the original developer abandons code support or development (unlike proprietary software) and further, this problem appears to be self-resolving with the evolution of self-managed standards bodies.
Sunk Costs
Open source software is a fairly recent phenomenon starting in the 1990s, though organizations have been using software and applications since the 1960s. Many organizations have already invested heavily in proprietary software prior to the emergence of open source, and adopting open source systems will require writing off prior investments as a “sunk cost.” Naturally, many organizations are unwilling to bear this cost, and hence cannot adopt open source systems on an enterprise wide scale. Since organizational executives demand cost justification for most new technology investments, the sunk cost of existing proprietary systems renders open source adoption unjustifiable.
Organizations considering open source adoption may attempt to address the sunk cost problem in two ways. First, they may consider partial adoption of open source software, in specific areas where no prior proprietary system (and hence, sunk cost) exists. For instance, an organization without business intelligence applications may consider open source variants of these applications such as Jasper Reports and Pentaho (in lieu of proprietary variants), even though it may wish to retain proprietary versions of sales, accounting, manufacturing, and other mission-critical business systems already in place. Second, instead of comparing the adoption costs of open source with the sunk costs of proprietary applications, organizations should compare the future cost streams of maintaining their proprietary applications vis-à-vis open source applications. The cost savings in licensing and using open source systems over a multiple-year period may potentially be adequate to justify the sunk costs invested in prior proprietary systems.
Perception of Technological Immaturity
There is a common perception among many organizational managers that open source software is an immature technology and not yet ready for commercial use.4 Many also believe that goods available for free, such as open source software, are probably of inferior quality than those that are paid for, such as proprietary software. Fuelling this perception may be the “bazaar style” development of open source software, by volunteer developers at their leisure and without formal oversight or incentives, and the fear that one day, these developers may not want to continue improving these systems for free or may move on to other technologies. Not surprisingly, such thoughts are frequently echoed by the marketing divisions of proprietary software companies to plant uncertainty and doubt in the minds of potential open source software adopters, in an effort to retain competitive advantage for their own products.
However, the hundreds of thousands of downloads to date of popular open source software such as Linux, Apache, and MySQL from Sourceforge. net should put to rest fears about their technological maturity or their longterm sustainability. Further, the fact that commercial organizations such as IBM, Hewlett-Packard, and Sun Microsystems are investing millions of dollars on open source software development should provide some degree of confidence in the minds of concerned adopters. Further, open source software is fast gaining in maturity, possibly more so than their proprietary counterparts. Third-party organizations have developed formal evaluation metrics and models to benchmark the quality and robustness of open source software. These models include open source maturity models by Navica,3 CapGemini, and Atos Origin. These models consider a wide range of factors such as the availability of training, documentation, third party support, integrated software and other professional services, community size, community age, and lines of source code, with different weights for each factor, to estimate the maturity of open source software. Potential adopters considering open source adoption may employ the above models to evaluate for themselves the true quality and maturity levels of their targeted software.
Conclusion
While the benefits of open source software, such as cost savings, vendor independence, and open standards, are often highlighted in the practitioner press, the barriers confronting open source software adoption and potential ways of overcoming these barriers are less known. This article described five major barriers for adopting such software, along with potential remedies for each barrier. We hope that our analysis will help user organizations make a fair and balanced assessment of the benefits and challenges of open source adoption, when they are confronted with that decision.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment