Getting there: Migrating to open source

Those who have made the move share advice on how to prepare and what traps to avoid.

Despite the enthusiasm of many open source backers, successful rollouts of the technology aren't automatic.

While a recent Forrester Research report found that roughly 40% of the 100 U.S. companies surveyed had no disappointments, that still leaves 6 out of 10 perhaps wishing they had done things differently.

How can you better your chances of success? Read on to learn what open source users and industry watchers advise.

1. Getting started

While open source software can be quickly downloaded and put to use, industry watchers say rollouts should be approached in much the same way as they would with commercial applications. That means assembling a proof-of-concept plan and determining long-term integration, support and labor costs.

"It's a cultural difference. IT people wanting to bring open source in-house don't always approach it as they would other technologies," says Mark Douglas, vice president of engineering and operations at online dating company eHarmony in Pasadena, Calif. "They need to put together a pilot and show the reasons why open source is better than commercial products."

Linux and Apache might have flourished in one-off rollouts, but users say a full-blown migration to open source needs to be driven by more than experimental curiosity.

"Teams will know they are ready when commercial software just never meets all of their needs. Those gaps end up being a critical factor in the decision to go open source," says Andres Andreu, technical director of Web engineering and applications for advertising giant Ogilvy & Mather in New York.

2. Support scheme

One Catch-22 with open source centers around support. Sure, there are numerous sources for help with many of the 70,000 open source components available for download on the Internet, but how good are they?

"There may appear to be support, but it really needs to be investigated beyond surface appearances," says Michael Goulde, a senior analyst at Forrester. "You have to determine if you are choosing a viable product with long-term development plans and identify the development community upfront."

EHarmony's Douglas says with every type of open source software, there is most likely a vendor committed to providing support. IT managers can contact vendors such as Red Hat and Covalent, for example, to get support contracts that rival those for commercial software.

"It hasn't been any different than when I wanted to get [BEA] WebLogic support; I contact the salespeople and they get me support," Douglas says.

3. Learn the licensing

Open source doesn't always mean free.

"Deciphering the different license models for open source, and even commercial, software can become a bit of a train wreck," says Sam Lamonica, IT director at general contracting and engineering company Rudolph & Sletten in Foster City, Calif. "You have to figure out which licensing scheme is going to work for your company and how you are using the open source code."

The Open Source Initiative lists dozens of license models it has certified on its Web site , including the General Public License (GPL) and Mozilla Public License (MPL).

For example, GPL permits unlimited free use, modification and redistribution of source code, but imposes restrictions, such as prohibiting the licensee from charging for redistributed code without also sharing the source code and explicitly publishing the copyright and warranty notice.

4. Go to the source

One of the biggest perceived benefits of open source is the flexibility of having access to the source code.

But there are two caveats: One, IT staff needs to have the skills to write scripts and make the software work for them; and two, IT managers will have to take full responsibility when the manipulated code doesn't live up to original expectations.

"You may not get all of the commercial refinements you are used to, so you really have to understand software, data and architectures," Ogilvy & Mather's Andreu says. "You will cut the umbilical cord of vendor accountability in this realm."

5. Tying it all together

The differences in open source code from developer to developer can make it difficult for a company to quickly adopt and integrate a complete open source stack.

One route is to follow the LAMP model, an integrated stack that includes Linux , Apache, MySQL and programming languages Perl, PHP or Python . Start-ups such as OpenLogic, Optaros and SpikeSource say they will do the integration work for IT managers and provide services or stacks of software that fit the LAMP model.

"Open source can become a real time sink if you are working to tie multiple pieces together," says Rick Beebe, manager of system and network engineering for ITS-Med at the Yale University School of Medicine in New Haven, Conn. "Many open source projects are built on other open source projects and the hidden costs with open source is directly related to the time it takes to work out the integration."

6. Security concerns

Open source advocates contend that the technology is more secure than commercial offerings, but open source software has susceptibilities of its own.

According to analyst Laura Koetzle, open source developers are not as motivated by customer satisfaction numbers or the potential of hackers as commercial vendors to participate in vendor-sec mailing lists to report bugs and holes in the software. "Open source maintainers will vary widely in the speed and quality of their responses to security vulnerabilities," she writes in a Forrester report.

Koetzle says open source software passes the "good-enough security tests" that most commercial products do, but she adds that you can take extra measures to ensure the security of open source software on your network.

Gaining ground
• By 2010, IT organizations in Global 2000 companies will consider open-source products in 80% of their infrastructure-focused software investments and 25% of their business software investments.


To start, standardize on one distribution of source code. Software release management processes also should be applied. And you should consider using tools such as GNU privacy guard, a free replacement to the data encryption program PGP (Pretty Good Privacy).

7. Make management a priority

While management is historically an afterthought when rolling out new technology, it shouldn't be with open source.

Yale's Beebe suggests standardizing open source rollouts to help simplify management and ensure better performance later. "It can get very confusing, fast if you have different distributions installed," he says. "With commercial software, there is someone you can call and have them worry about why performance isn't up to par. But with open source, you need to get a handle on it yourself."

One "gotcha" can be assuming that a Windows application will perform the same if moved to Linux.

"It pays to check it out ahead of time," says Kerry Miller, network engineer at First Victoria National Bank in Houston. "We like to run things in a test environment for a while first, then ask a couple of users to try it out before we unleash something on the whole bank."

Copyright © 2005 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022