Migration Costs

That raises the question of migration costs. What's involved in migrating?

EUNICE: A lot of the costs are strategicmigration, training and risk. People from the Linux advocacy community don't often think about the amount of risk and difficulty. But if you have a staff of tens, hundreds, sometimes thousands of people who know the solutions, and you already have experience with a system, whether it's Oracle or IBM or Sun or whatever, it really doesn't matter what the solution is. Choosing anything different brings up huge risk costs and migration costs that are not just migration of a particular application but also migration of who you are and what your strategy is. So you have to be pretty concerned with those. Often in the open source debate, we kind of walk around those risk and integration issues, but that's at the core of what a CIO or CTO really needs to be thinking about, these big strategic costs.

ROBBINS: I recently had a conversation with a number of CIOs around the Oracle/DB2 debate, and they have all said that they would have to be dragged kicking and screaming to do a database migration, regardless of the performance of the newcomer on the block, simply because migrations of anything at that level are always painful. It's like exploratory surgery. Until you get into the systemwhich you probably inherited from your predecessor or from a team of people who didn't document their code and have left your companyyou don't know what the real implications of that migration are going to be until you're already in it.

QUANDT: One migration issue is that Linux is moving beyond the entry-level infrastructure to the mid-range, and you're talking about databases, but there will be ways to scale Linux up to an eight-way SMP on Intel. So the characteristics of which application you can actually support with Linux are changing.

CORMIER: I agree 100 percentLinux is moving into the more complex and higher-end technologies daily. One of the things I wanted to comment onI didn't get a chance to jump inwas the question of whether Linux or open source in general is going to be around for 10 years. That's one of the beauties of Linux. You, as a customer, have the decision of how long it's going to be around for your application. You're not locked in, you're not hit with a vendor saying, "We're going to retire this next week."

YATKO: You have to ask that question with all your operating environments. Right?

CORMIER: Exactly.

YATKO: I think Linux is here to stay. I think there's enough movement going on in the industry, enough support now from major contributors such as IBM investing billions of dollars into this, and now you see Sun jumping in as well.

MATUSOW: As you talk about Linux moving into the higher end, from the CIO perspective, one of the things that you have to consider is how much test and development burden you are taking on versus what you were traditionally looking to vendors to do. There are so many different distributions of Linux out there, and they lack binary compatibility across them. If you are having multiple implementations, particularly if you have IT staff that is doing it without your knowledgewhich certainly we have found in our discussions with customers to be the casethen the modular nature of the system, in fact, is such that there is no full regression test pass being done. So that test burden is being moved onto the shoulders of the customer.

EUNICE: That's a burden that is, unfortunately, moved onto the shoulders of the user with any new coming-up technology. We've seen it with Unix in the late 1980s, we saw it with Windows in the 1990s, and we're seeing it again with Linux.

QUANDT: If you support your own application, yes, you probably have to do some of your own testing, unless you partner with a Linux distribution provider. But a lot of the leading Linux distribution providers have certified a distribution with key independent software vendors.

MATUSOW: If you talk to the customers who have joined us here today, large enterprise organizations, they all have custom applications with significant development staff. So there's a limit to how far they're going to be able to move from the traditional point of view where they're going to have to test those pieces. But if they are also adding them on top of all fixed testing and future compatibility and binary compatibility testing, it can be a very significant amount of work.

CORMIER: In terms of testing, the open source model actually lends itself to a great degree of testing just because of the nature of the model, the number of eyes that are on it. It opens itself to a great deal of generic testing, which any vendor also has to worry about. I contend that custom applications are no different from one operating system to another on where the testing burden lies. And in the case of commercial applications from independent software vendors, we are just now seeing them, as Stacey says, starting to certify to various Linux distributions. So I don't really see a problem here compared with other operating systems.