Getting Started With Linux In Your Business

<< Back


This is not a formal white paper, just some advice based on my experience.  Some of the common questions and concerns I've run into along the path.   The common alternative operating system I'll just call W for typing convenience. :) Another thing to keep in mind is people say "Linux" like it's a product. It's not a product as much as a community, a lifestyle. It's an important distinction. Not all parts of an integrated data system even have to run on Linux. There are some very good proprietary Unix flavors out there, some offering some very tempting management tools. So, when I say Linux, be aware that in a big system it could end up being a *nix environment. In fact that's likely, depending on who does the implementation.


Having a throat to choke. Seems to be a big factor for a lot of CIO's. They want someone to whip on when network services go down the toilet. The nice thing about a Linux or *nix environment is you can hire someone to choke for somewhat less than you'd pay for the software. You can even make a big show of firing them and have someone new in by the end of the week. You'll pay for service in either environment, only in the Linux environment you don't have to pay for software AND service. Having worked in both environments I can say with absolute confidence that a well-designed and well-maintained *nix system, if properly implemented, will be extremely stable. You will still have the throat to choke but will find that you rarely have any need to do so.


First let's address what I call The Myth's Of Open Source Doom:


You'll spend more supporting Linux than buying W products and supporting them.  BZZZT! Wrong.  You will likely spend more setting up Linux because Linux administrators command a higher price than their W counterparts.  You will get that back many times over in increased stability and up time and not being trapped in an endless software upgrade cycle.  Having said that let me caution you not to underestimate transition costs, particularly those associated with file format conversion and data migration.  More on that later.  Also remember that you pay for support in either operating environment. These will vary depending on whether you are replacing server or desktop components.


There's not very much software available for Linux.  Also not true.  There is a ton of software available for Linux, though sometimes you have to hunt around for it a bit.  It is true many of the applications you use today may not be available, but there is usually a low-cost alternative for most of them.  There are many vendors out there offering end to end open source solutions. 


You'll spend a fortune retraining your staff.  Where do they come up with this stuff? For the majority of tasks most users need very little retraining.  Sending an Email in either environment is virtually identical.  Most users with a functional understanding of the alternative applications will need a bit of time to get used to the spreadsheet and presentation tools, but they will adapt.  No one I know implementing an OSS test system has gone back to the proprietary solution, and certainly not because the users couldn't figure out how to do their job.


Open source software isn't as good as proprietary software.  Who says?  Probably a study commissioned by your favorite big software company.  In many ways open source is better.  It's certainly been reviewed more than most proprietary code and tested on a wider variety of hardware.  One of the neat things about open source code is that it very rarely feels the need to reinvent itself.  It tends to just get better and better over time.  Another great advantage to having the source code is being able to bring a programmer on board for a short time to make a piece of software do something you want it to do that no one else will have. 

Proprietary software is more secure than open source.  That's bordering on hilarious.  Proprietary software depends on what's called obscurity by concealment.  In other words, no one can see our code and it's harder to find exploits.   The argument being that since open source code can be examined for flaws and vulnerabilities, bad guys can more easily figure out how to attack it.  The problem with that theory is that everyone else looking at the code can see the same exploit and it tends to get fixed pretty fast.  A poorly configured operating system...any operating not going to provide much in the way of security. 


Open source software accounts for more security flaws than proprietary software.  An accusation that's proof that there are lies, damn lies and statistics.  It depends on how you count them and who's doing the counting.

Now let's balance out the view by addressing the Open Source Sky Pie:

Open source software is free.  Many times that's true, but not always.  Some are free for personal use and charge for business deployment.  Most will give you the application and charge for customization and support, which to me seems entirely fair.  Certainly better than paying a fortune for the product, then paying for near useless support on top of that.  But you will find per user and per processor charges in the open source world, just like you know who.  Read the license agreements. 


You can use open source on old hardware.  That's true in some cases, but check the hardware compatibility guide before you decide to cut over your call center just before the holidays.  Open source solutions frequently support a narrower range of hardware options, so make sure yours are on the list before flipping the switch.  And running Linux on a 500 Mhz desktop carrying X and a graphical desktop is going to run...well, like a 500 Mhz machine.  Your old machines will not suddenly turn into speed demons because of Linux.  But you will on average, get longer life out of your hardware in a *nix environment.


Open source solutions are as good as proprietary software.  That's not always true.  Many times proprietary solutions will perform some tasks far better than the open source alternatives and have very attractive features.  You don't think they under-pay all those L-1 and H1-B workers for nothing, do you?  One of the reasons many companies switching will still keep W kiosks available for some applications. 


It's just like W.  No, it's not and it never will be.  It's a different operating system with different rules.  It will be an adjustment.  Plan carefully, implement in phases, be vicious about sticking to cost estimates.  Know when and how to back out of a particular phase if it's not going well. 


Open source products can open W documents.  Sometimes, but not always and there's frequently a long lag time before other solutions will be able to convert the file formats.  Do not underestimate the time and expense necessary for data conversion! 


So what works then?  Now that we've clarified some of the mythical claims, good and bad, let's talk business. 


Start in the server room.  With the increasing trend of web-based software systems, many corporate clients find starting with a LAMP (Linux-Apache-MySQL-PHP) web project is a good way to safely dip their toe in the open source water.  The LAMP project becomes the first transition in your server farm. Yes, all of them. In general conversion projects aimed at server support systems, if planned right, will offer a good return and be almost invisible to staff.  But to take a really big bite out of downstream licensing costs, you'll want to go all the way.


I've noticed a tendency for customers to get locked into a PC mentality, thinking they need fully functional PC on every desk.  For a majority of people the huge processing power of the average PC goes to waste.  My best guess is that, not too far in the future, we'll look back on that idea and laugh.  Consider all your options for desktop replacement.  There are several workable options for phased replacement of desktop PC's with several varieties of diskless thin client workstations.  Thin clients are basically smaller computers that borrow storage and some processing functions from a central server.  Thin clients are in some cases being displaced by more versatile smart displays.


What you can't do: One thing you can't do is depend on your MCSE network staff to implement a *nix translation for you. They think they can handle it and will tell you with all honesty they can do it, but the fact is, unless they have a strong background in *nix (and if they did they probably wouldn't be MCSE's), it's not happening. They'll inevitably go back to what they know and that is a disaster waiting to happen. Running Lintel like Wintel is the worst of both worlds. If you only click away with one thing, scan this: If you're going to cut the cord, cut the cord. Don't jack around with a half-ass installation that's only going to cost you money, tank your credibility and really torque your users. You can't do it with Wintel-trained staff. Sorry. Find *nix staff with enough Wintel background that they'll be able to stand the stench long enough to get through the transition.


Institutional Inertia: Nothing freaks out staff like change, even a change for the better. But with an emotional issue like this one expect and plan for resistance. In every department is the Wintel hobbyist who's been using W for years. People go to them for advise on spreadsheet problems, how to do list merge in the word processor, you know who I'm talking about. Short of firing them you'll want to co-op these people as part of the transition planning. Give them a Powerbook G4 with OS X and let them tinker. Send them to a *nix class and give them time to talk about the things they like. If they continue to resist and complain, remove them. Simple as that. Demonstrate that failing to adapt to the new environment will have consequences. No matter how well your *nix architecture runs there will always be some staff wailing for the leeks and onions they had in Wintel Hell.


Options: You have more than one option for implementing a *nix transition and don't have to do it on your own. Companies like IBM specialize in providing services like I'm describing and, if you're willing to pay a premium price, they can put enough boots on the ground to get the job done. The only problem I have with them is they tend to push their own products, whether they're the best solution or not. But the advantage is having someone to blame if it doesn't work.


Planning: In real estate the popular slogan is location, location, location.  In the transition to open source your mantra is planning, planning, planning. The worst possible way to start is to throw all your business processes and staff into upheaval.  One area to pay close attention to is file format compatibility.  It will be a modern day version of the Tower of Babel if accounting rolls before personnel and suddenly find they have no means of exchanging documents.  Another frequently overlooked item are portable appliances such as PDA's.  Chaos can be avoided by careful study of current business practices by different departments and job functions.  Take a close look at the software they use on a daily basis and document how work flow is organized.  What many companies discover is that they have classes of workers, even though they may be doing different jobs. 


Also accept up front that no transition is going to be completely painless.  Despite the best efforts of clever programmers and technical people there will some file formats and information that are just not going to translate into the new environment.  There will be losses and there will be a temporary hit on productivity while staff adjust to the new environment and recreate some of the information that won't translate. 


To review:

More reading:


Large Implementations

KBSt Migration Guide (excellent)


IDA Migration Guide


Smaller Implementations


Linux in Small Business: A Practical User's Guide

John P. Lathrop (ISBN 1-893115-46-1)

<< Back

Copyright 2003

Chris Poindexter

All Rights Reserved