Is Open Source Appropriate for Your IT Strategy? 10 Essential Questions

David Senf and

Warren Shiau

CIOs wrestling with fear, uncertainty, and doubt regarding the adoption of open source are wading through the rhetoric fashioned by software pundits and marketers on both the open and proprietary sides. Issues concerning maturity, cost, reliability, support/documentation, and licensing lie at the heart of the discussion. Each of these issues bears a varying degree of weight, depending on the open source initiative in question. The Linux operating systems (server and client) and the Apache Web server, for example, have achieved an anomalous level of adoption, input, testing, and documentation – and are, therefore, not accurate bellwethers for gauging the viability of all open source initiatives.

IDC treats assessing the viability of open source within a CIO’s enterprise environment, first, as an internal IT operations issue. Determining viability centers on the compatibility of in-house expertise, support, and computing environment with open source.

Second, determining the compatibility of the organization’s strategic IT direction with open source centers on the functionality-versus-cost debate. Organizations requiring little software customization may emphasize cost savings in their IT strategies – an emphasis that is inconsistent with maintaining customized open source software throughout the organization.

Third, once an operational and strategic fit with open source is determined, the CIO’s issue becomes timing of adoption. IDC believes this decision will center on factors external to the organization, such as availability of outside expertise, code maturity/testing, tools availability, and services support.

Armed with a Plan

The selection criteria used to assess the viability of open source within the enterprise are somewhat similar to the criteria for selecting proprietary solutions. The following list outlines question areas with which organizations may wish to assess open source for use on the desktop and within the software stack:

• Is there adequate in-house expertise to manage open source deployment, modification, and maintenance?
• How significant may limited support be for implementation and maintenance?
• How critical is potentially limited documentation to the viability of open source on the desktop or on enterprise systems?
• Compared with proprietary solutions for given requirements, are the capabilities of open source solutions better, the same, or inadequate?
• Does the usability/functionality of an open source solution reconcile with end-user needs?
• Does/will a given open source solution align with enterprise system requirements?
• What are the near- and long-term architectural and platform implications of open source?
• Within current plans and future strategy, does a given open source solution meet IT and business needs for stability, performance, and scalability?
• What are the costs associated with accommodating, administering, maintaining, etc., open source code?
• Does the license agreement for the use, modification, and distribution of open code align with IT/business objectives and legal concerns?

For many CIOs, “it’s a confidence issue,” as articulated by Graham Bird of the Open Group. Gaining this confidence will involve gauging the ability of open source solutions to reconcile with multiple considerations. Determining when the time is right to adopt open source solutions will stem, in part, from external factors, including the following:

• Support availability and cost
• Code maturity and testing
• Open source project milestone timeline and evolution
• Tools availability for deployment and maintenance
• Software/hardware industry acceptance/inclusion
• System integrator support/availability

Adoption Considerations

Organizations considering adoption of open source should expect a lack of support through the deployment and maintenance processes. Open source initiatives such as Linux are well documented and supported, but this does not hold true for the majority of open source code. At best, support availability and cost are unpredictable, leaving a question mark around timing and costs. However, organizations incorporating open source into the software mix can leverage limited support/documentation from systems integrators, open source distributors, vendors supporting open source, and online collaboration.

Another one of the natural concerns for adopting open source software is the manner in which it is planned, designed, built, tested, and maintained. Packaged and in-house solutions generally adhere to disciplined project management and evolve through processes such as the systems development life cycle and have a project team accountable for the security and reliability of the solution. Can the open source community development model (lots of developers, no formal management) work?

This question is explored in Eric S. Raymond’s The Cathedral and the Bazaar, in which he outlines the success of Linux despite its being an affront to Brooks’ law of development projects having the “right” number of programmers – generally a small number. Raymond advocates continually launching code in front of as many eyeballs as possible, given “smart data structures,” can compensate for “dumb code.”

The open source model should continue to function well. However, organizations that have made a decision to use open source software may consider involvement within the open source development process to assert some predictability around delivery milestones, especially when niche, industry, or special user/system requirements are involved.

Moreover, the evolution of open source development will depend on the extent to which enterprise and government users modify and expand the base of open source code. Increased involvement translates into a greater pool of projects from which to draw. Also, user participation within open source projects will help grow the number and quality of features available.

As CIOs consider trends toward “plug-and-play” modularity and lower-cost solutions, the attractiveness of participation within the open source process and overall open source viability begins to wane. However, niche opportunities and requirements that can be solved through a community-based iterative development process will remain. This can take the form of acquiring packaged open source for a fee or downloading it at no cost, or it may present opportunities for organizations to leverage open source by contributing to the development process.

Trends and Evolution

The trend toward service-oriented computing, built around standards such as J2EE and Web services, engenders an environment within which features and functionality are dynamically reusable in any context. Certainly, the utopia of standardized “plug and play” software is not just around the corner, but throughout the software stack, lower-cost component-based solutions are emerging. Sun, IBM, and CA are examples of vendors providing modular infrastructure software, while SAP, Siebel, and PeopleSoft are examples of vendors building out modular enterprise applications software. Commoditization throughout the software stack and on the desktop, while increasing functionality and driving down costs, negatively impacts the relevancy of open source.

IDC believes that CIOs will become more receptive to open source over time, and enterprise initiation, support, and participation in open source software development will increase, especially to meet niche customization requirements. The size of the increase in this market, however, depends on open source development efforts shifting from ad hoc confluences of individual developers to organized development with significant IT department/enterprise sponsorship and involvement. CIOs need to address the key questions outlined above while assessing the external proprietary and open source trends impacting adoption timelines.