We all know about the benefits of open source software in lowering total cost of ownership, offering more choice and the increasing quality and functionality of the code. The rise of Linux as an edge server and now migrating toward the data center is clear validation that the open source model has taken root.

But there are still significant barriers to overcome before Linux and other open source projects are broadly accepted across enterprises. During a keynote at the Open Source Business Conference 2004 in San Francisco last week, Ray Lane, former Oracle executive and a general partner at Kleiner Perkins Caufield & Byers, outlined six objections gleaned from interviews with a few dozen CIOs at Fortune 500 companies. The six objections won't forestall the march of open source into data centers and desktops, but they provide a good framework for discussing the roadmap for open source software.

Lack of formal support
At the top of Lane's objection list is the support issue. IT executives understand that the free license for an open source package is just a fraction of the cost to deploy and maintain an application.

The expectation is that support for Linux will continue to improve, with well funded companies like Red Hat and Novell behind the distributions. Red Hat, for example, has a cash reserve of about $1 billion, and Novell has been steadily building a portfolio of open source software to complement its proprietary offerings. The hardware vendors who bundle open source software want to protect their reputations; even if they don't develop the distributions, they are on the hook with customers to deliver an overall solution that works. IBM and HP would not be in bed with Red Hat, SuSE, TurboLinux or MandrakeSoft for long if the Linux distributors couldn't deliver on the service-level agreements that customers require.

Apache far outpaces Microsoft's Internet Information Services in the Web server software marketplace and doesn't appear to suffer from a lack of support service offerings.

		Open source deficiencies Informal support Velocity of change No roadmap Functional gaps Licensing caveats ISV endorsements

Many smaller companies are building proprietary extensions and support services on top of open source code. Gluecode, for example, harnesses Apache projects and combines them with its own proprietary portal and management technology. Gluecode claims that it is three to six times less expensive than similar solutions from BEA, IBM and Oracle. The company charges a monthly subscription of $4,000 to $2,000 per month for its Advanced Server products.

"We have been converting from PHP to Java, and using Gluecode to incorporate single-sign-on and to do some portlets for different Web applications," said James Chaney, Web developer at Consolidated Communications, a telecommunications company that operates call centers for companies such as Procter & Gamble. "Support has been great."

Of course, smaller, younger companies, or even established entities, won't get far down the road with reference accounts unless they can provide the support and maintenance required to satisfy customers.

Lane is likely also referring to the large number of open source projects that don't have formal support outside of the collaborative development process. The Apache Software Foundation, a non-profit umbrella organization, provides aid and support for the multitude of Apache open source projects and demonstrates how well the collaborative development model works. In fact, the open source software underlying the Apache group's collaboration efforts provides the basis for CollabNet's SourceCast, a Web-based platform for collaborative software development in use by companies including Sun, Sybase and Motorola.

Open source application server maker JBoss offers 24-hour support and is certifying its software for the Java 2 Enterprise Edition (J2EE) standard, but the small company is going up against companies like BEA, IBM, Microsoft and Sun. Convincing a CIO that it can deliver better, , more cost effective support than its billion dollar competitors is a credibility and growth challenge for JBoss and its brethren.

For other open source software, the support infrastructure and assurance is less defined, and enterprises must proceed at their own risk. In many cases, an enterprise can rely on the open source community for more informal support, which won't be sufficient for mission-critical applications, but that's no different from the risks of dealing with smaller, resource-constrained companies that sell more purely proprietary software.

Velocity of change
Many enterprises are overwhelmed with patches and handling vulnerabilities, as well as the consequences associated with introducing new software into an infrastructure. The fact that the open source community is constantly tweaking its software is a reasonable concern for IT executives. Open source software introduces more complexities in software maintenance, but also promotes more secure and reliable code through rapid bug and vulnerability fixes. Microsoft took 200 days, for instance, to deliver a patch for a particular vulnerability.

Given that enterprises don't want constant upgrades and optional fixes, the major Linux distributors offer scheduled, rather than just continuous, releases via subscriptions as well certification of the software to alleviate this problem. Red Hat claims to have a database of over one million dependencies to check against as part of its delivery of new patches or functionality.

As an overall objection, the versioning issues will go away as more vendors develop subscription and support services for open source software software that are part of an automated lifecycle management infrastructure. In addition, both vendors and IT shops must be more involved in the communities managing open source projects that are their code base.

The number and scope of open source projects can be an issue for for vendors and enterprises, however. "You have a broad selection of open source projects to choose from, such as five or six XML parsers and four or five databases," said Bud Tribble, vice president of software technology at Apple. "It's not easy to get the equations right--how strong is the community or how does it fit with us."

Lack of roadmap
Many open source projects suffer from an informality that causes CIOs anxiety. Most IT executives want a clear roadmap for products so that they can better plan for their future and select vendors. While the major open source distributions have specifications and Web sites that outline the various projects, the code-by-committee approach may not align with the goals of a particular enterprise. But, just like protocol standards committees, the open source community process has tradeoffs. Enterprises can be held hostage to lower common denominator specifications and solutions.

On the other hand, without standards like TCP/IP or XML, we would be without the Internet and Web services. The open source software development approach is more democratic than proprietary software, and the debates are public. The community tends to regulate itself and focus on longer-term rather than short-term goals.

Increasingly, open source projects will become even more transparent and include more detailed roadmaps, based on the feedback from various constituents.

Keep in mind that the roadmaps from all vendors or committees can lead to detours and dead ends. Vendors produce roadmaps as a way to keep customers informed, but also to keep them from looking elsewhere for solutions.

Product delays and roadmap detours are irritating, but they are more often the result of the complexities of software development and the industry practice of marketing future versions way before their time. Many of the open source communities have so far shown that they can provide roadmaps, and given the process is more open than for companies with proprietary software, the end user community has more ability to provide input and track the progress of projects.

Functional gaps
The current market for Linux is dominated by low-end edge server applications, but the open source operating system is expected to gain significant share in mainframe, data centers and ERP applications in the coming year. On the desktop front, Linux could account for 5 percent of desktops worldwide by 2007, according to various industry reports.

Among the more well known open source projects, MySQL is developing MySQL Cluster, a higher-end version of its open source database that will allow more than one instance of the database to take over if another fails. The company is also adding stored procedures, which are already a part of other open source databases, PostgreSQL and Firebird.

Novell announced this week that SuSE Linux 9.1 Professional will deploy the 2.6 Linux kernel, a major overhaul of the Linux core with supports for the 64-bit extensions to x86 chips from AMD and Intel. Red Hat is preparing its distribution of the 2.6 kernel for next year. Some open source distributions have passed Common Criteria certifications, which are necessary for government and military customers.

The functionality gaps in open source compared to proprietary software won't pose a major obstacle over time. Most importantly, major vendors, in addition to the broad community of open source developers, are devoting substantial engineering and evangelism resources to open source projects. The traditional software and hybrid vendors and the open source communities will clearly have some conflicts and potential fragmentation as new feature sets and licensing models are ironed out. For example, what happens if Red Hat wants a specific modification in the Linux kernel but Linus Torvalds and the Open Source Development Labs don't agree? Nonetheless, the collective talent and engineering efforts will continue to yield impressive results, leapfrogging some of the proprietary platforms.

Licensing caveats
The SCO litigation as well as confusion about the various open source licensing schemes adds an element of uncertainty and risk for IT executives. Legions of lawyers continue to debate the issues surrounding the the General Public License and how to ensure that intellectual property rights are protected. The BSD and Apache models appear to have the most licensing flexibility to date.

There are new hybrid licensing models that combine open source and proprietary code in flexible ways. Gluecode, among others, uses open source software as a foundation for building products with proprietary extensions. At the same time, Gluecode provides customers access to source code through its Enterprise Source License (ESL), which allows them to extend the code according to their requirements, but not embed, distribute, sub-license or resell the end product to third parties.

MySQL uses a dual-license philosophy, offering its database software under an open-source license for use in open-source software and under a commercial license for inclusion in proprietary software. However, dual licenses are considered less useful when more than one company owns the source code copyright. The company recently resolved a licensing conflict with LAMP (Linux-Apache-MySQL-PHP, Perl, Python) cohort PHP. Licensing, as well as intellectual intellectual property protection, are the biggest areas in which more clarity and well-defined practices are needed.

ISV endorsements
Endorsements from independent software vendors (ISVs) aren't especially credible for CIOs, but those from peers in other enterprises carry substantial weight. Today, Linux has proven itself for a specific set of tasks, and there are no significant roadblocks that prevent open source from climbing up the stack.

At this point in the evolution of open source, it's too early to divine when and how the various obstacles will be overcome. But, it's clear that software development and business models are changing as a result of open source code. The future is interoperable, modular components based on standards that will include both open and proprietary code. John Fowler, Sun's chief technology officer for software, describes this trend as providing "combinatoric" value.

Tim O'Reilly, president of O'Reilly & Associates and an open source software activist, suggests that engineering reliable systems from independently developed components may be the key open source business competency. If developers focus on that capability, the barriers today that limit the adoption of open source software will eventually become background noise from the companies and enterprises stuck in the past.

You can write to me at dan.farber@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.