My philosophy about adopting Open Source software is to give realistic advice for IT directors faced with the prospect of sorting out this new wave of technologies and business models. It can certainly be a daunting task. It's one thing for a home enthusiast to try out the latest cutting-edge software on a machine that doesn't really have to do much more than collect e-mail, but it's another thing entirely to commit to a production system.

Part of the problem is that there's so much Open Source software to choose from, and it's all in varying stages of development. Literally hundreds of applications (or more) can be found on Sourceforge, a repository of Open Source code. I've heard people advise IT directors to browse Sourceforge for replacement software, but honestly, that's a mistake. Sourceforge is like an incubator for Open Source projects, and it's simply not practical to search for production-quality software among projects that include those at an embryonic stage.

Practical is the operative word. I know that IT directors want advice about Open Source software that they can use *now* with maximum benefit and minimum risk. And I know that they value *practical* above cutting-edge, so that's how this column got its name. Once a month, I'll take a practical view of Open Source, highlighting software and approaches that are well-tested and ready to use now in average IT environments.

Dipping Your Toes In
The first thing I'd like to do is dispel the notion that Open Source adoption needs to be a radical process. Don't think "taking the plunge" - think "dipping your toes in." An analyst group did a survey last year in which they asked technology professionals if it would be expensive to rip out existing systems wholesale and replace them with Linux. The obvious answer must be yes in most cases, but it's really not a question worth asking. Instead, we should be asking where we can make use of Open Source - not just Linux - to achieve the most benefit with the least risk. This means thinking of migration not as a wide-scale process, but as particular solutions for particular problems. And it turns out that some common problems lend themselves especially well to Open Source.

Look for the Low-Hanging Fruit
The trick to getting started with Open Source is to select the areas in your IT environment where a migration will give you the best value with the least effort and disruption. That value will depend on what you're looking for - cost savings is usually number one, but security and performance aren't far behind.

In general, the easiest systems to migrate are those with basic functions that don't depend on a third party or complex custom development. You should start with server migrations first, of course, since those deployments will be transparent to users and give your staff a chance to learn Linux behind the scenes. Linux on the server side is now considered by most analysts to be mainstream in the corporate world, so you're not sticking your neck out with a server deployment. Essentially, anything generally considered to be basic computing infrastructure - those systems you're most likely to have in common with other industries - can be potential candidates for an Open Source migration.

Migrating Windows file-and-print servers, for example, will likely give you a great return for the effort, and they're a good way to get your staff started with Linux. Not only will you save on license fees for the server, you'll also save on each Windows client access license. In some cases, hardware reuse is possible and can result in more savings. Anything related to Internet/intranet infrastructure is also a good place to start looking for possibilities. DNS servers, firewalls, and web proxies, for example, can be switched fairly easily. Other specialized servers may also be candidates for migration, such as fax servers, remote access servers, PC-based VPNs, etc.

The ease of migrating your internal or external Web sites will depend on the portability of your chosen technologies. If you relied heavily on proprietary tools that require a specific application server, then you'll need to examine what it would take to do a conversion. It may be too difficult to be worth the savings, but an investigation will tell. If you wrote applications in Java, or if the site is relatively simple, a switch may be quite easy.

E-mail systems pose the particular challenge of requiring consistency in an organization, heavily affecting both the server and client, but Linux migrations are now possible while maintaining a seamless environment. If you use a basic e-mail server with a basic IMAP client as your standard, then you can easily migrate to Linux. Users can access mail with Mozilla on either Windows or Linux. If Exchange is your standard, then it's possible to migrate to Linux with an Exchange replacement like OpenExchange or CommuniGate Pro. The replacements work with a mixed environment of Windows and Linux desktops, using an Outlook substitute. The migration will be transparent to the Windows desktops. Running an Exchange replacement on Linux will be cheaper than running Exchange on Windows, and can be significantly cheaper if you can migrate some desktops to Linux at the same time.

Easiest Server Migrations
- File and print servers
- Internet/intranet infrastructure and services based on open standards
- Miscellaneous servers like fax, remote access, VPN, etc.
- E-mail servers

More Complicated Server Migrations
- Custom application servers
- Vendor-supplied application servers with no Linux ports
- Internet/intranet services closely tied to proprietary application servers

Where To Keep the Status Quo
There are going to be areas that you will need to leave alone for now. Most organizations are tied to a proprietary operating system because of third-party vertical applications. If your organization relies on one of these, then you don't have many choices. You'll get the best value in the future, however, if you have more options. Ask your vendors when they plan to release Linux versions. Many software vendors have been steadily moving in this direction anyway, and a little pressure may help them along. For custom apps, you'll need to investigate the complexity of a conversion and determine if the benefits are worth it. Factors such as your chosen language and tools, staff skill sets, and where you are in the development cycle will all play a role.

The point is that you're likely to find many suitable uses for Open Source software now. The best strategy is to make slow and steady progress by taking a practical approach - dipping your toes into well-established software and practices. You just have to look for the easiest places to start, and make sure that the benefits you get outweigh the risks.