Basics for Adopting Linux/Open Source

By: Brian Proffitt
Tuesday, May 28, 2002 11:27:40 AM EST
URL: http://www.linuxplanet.com/linuxplanet/reports/4223/1/

Changing Some Old Ideas

Let's face it; the chances of all of us waking up tomorrow and finding Microsoft Windows replaced by Linux on every machine in the world are pretty much the same chance that the Chicago Cubs will win the World Series: possible, but likely not going to happen in my lifetime.

The adoption of a new platform is not something that happens overnight, especially in the corporate arena, where conservativism often makes the decision to change a slow and complicated process. There are shades of grey wrapped up in every decision--quite a contrast to the often black-and-white world of an IT worker. In that world, if something is broken, fix it. If it breaks repeatedly, re-code it (if you can) or replace it.

These different approaches are probably the major issue behind getting corporations to look at Linux and other open source software seriously. It is not that they have a great love affair with Microsoft's products, but rather the fact that for decision-makers, Windows, for all its flaws and expense, represents that which is known. Linux represents the unknown and no amount of cajoling and endorsement from the IT staff is going to change their minds. Especially if the pro-Linux arguments are couched in technical jargonism that seems like a foreign language.

The successful approach to endorsing Linux use in a company is to make the case in terms that the decision-makers and purse-holders will understand, i.e., financial benefits.

The standard approach to presenting this kind of information. is digging through the Internet and pulling out as many Total Cost of Ownership (TCO) studies that you can find and present them as evidence, making sure to contrast them with the upcoming Software Assurance licensing changes that will take effect for Microsoft applications.

This paper version of "Scared Straight" may shake the managers out of their Microsoft comfort zone (if it hasn't already) and make them more receptive to listening to alternative ideas, but don't expect it to do all the work for you. You may want to suggest trying a test bed solution for Linux/OSS adoption with one team or department in your company first, so the real benefits can be seen with managements' own eyes.

There are more systematic methods that can be used in implementing a platform adoption in an organization, methods that have been tried and true by many consultants and managers. You can use them yourself to try to get Linux into your company.

Starting Change

The first big step in starting any project of this nature is to honestly assess the needs of your company and see what kind of changes are really needed. Notice the emphasis on honest. While you might want to rip out every licensed copy of Windows in your company, you obviously can't do this in a practical application of change.

When you look a move to open source software, don't just prepare a report on the numbers. That's easy, given the vast disparity in licensing costs between closed-source and open-source applications and the labor cost savings gained from any move to a Linux platform. The numbers are good, but they cannot comprise the entirety of your arguments vis a vis Linux.

Include in your evaluation, then, a look at the general readiness of the department or team you want to try to migrate to the new software. Are they motivated? Are they optimistic? How's their morale? If they are having problems in any of these areas, you may want to pick another group to be the prototype area for change. Also, see how they are doing on their workload. If they are perpetually several days behind schedule, they may not be a good group to experiment with.

Next, draw up a list of incentives for the team so they know what they're gettng out of this. Don't just tell them that "management said I could experiment on you, so there." That will not only de-moralize them, it will also make them so ristant to change that even if Linux could change lead into gold, they won't sign off on it.

While you're making this list, focus on the team's requirements. Maybe a complete desktop renovation is what they need, or maybe what will help them more is a complete back-end replacement of their server platforms. Try to identify the one change that will do the most good and then stick with that. Don't change platforms willy-nilly just for the sake of "Linux is good."

Be sure you know how the team works. Who does what, and what is it they do that is so important? How does the team's output integrate with the rest of the company?

A classic trick to software adoption is recognizing people on the team that are technically-minded or willing enough to become early adopters. These folks serve two purposes: they help work out the early bugs in the platform switch and they will serve as pseudo-support for the rest of their team after the entire migration has been implemented. If you're really lucky, these people will also be opinion leaders on the team (and maybe in the overall company), so you'll get some good press, too.

As you're doing this, make sure everyone who needs to be in the loop is in the loop. Don't go off and work some dark magic on your own and then pop up three weeks later and say "done!" If no one sees how you made the changes, they might be a little leery of later making those changes company-wide. In other words, document, document, document.

Making the Change

Once you've made a change plan and justified it to the Powers That Be, stick to it. If you decide to work with Red Hat, don't switch over to SuSE just because they released a new version.

On the other hand, be ready to roll with any internally generated changes. If someone on the team suddenly decides they need to have a custom interface to an Oracle database, get ready to include that change into your final goals or be ready explain why it isn't going to happen right away.

Be firm. Politely firm, not dictatorial. Nothing turns off a client faster than an insufferable IT geek who thinks that they know it All just because they know how to run a cron job. But you will need to be firm, because like most humans, your team will be resistant to any change. How resistant will be a matter of degrees, but if they sense you start to waffle after hearing just their most minute gripes and groans, they'll turn on you.

Explain as much as you can. This is a hard one for IT folks, since we tend to get genuinely excited about our work and want to share with others. Unfortunately, it can lead to "geeking out" on some poor unsuspecting co-worker, leaving their eyes glazed and their brains confused. So, share what you're doing, but be succinct. Instead of "the fact that the command line only uses 18.6 kiloquads of processing transistor power makes it infinitely superior to any graphical network-transparent environment," try "we're going to run this application outside of the windowed environment because it will run a whole lot faster."

Try to actively seek out resistors and find out what their problems are. Don't just assume they're being a pain just to spite you. Examine their problems and try to find the reason why they are resistant. Maybe there's a hardware/software conflict on their machine that no one else has. Maybe "this is a stupid application" could translate into "I don't like this program because I don't understand it." Or maybe they just like being a pain. In any case, you have actively addressed their problems and there will be little room for them to say otherwise when the final evaluation of the change is made.

Wrapping Up

You may have read all of this and said to yourself, "I don't want to do all this touchy-feely stuff. Let's just stick Linux on their machines and let them deal with it." (If this seems harsh, be aware that I get e-mails like this all of the time.)

As an IT staffer, it is probably not your job to "handle" employees as described in the previous sections. And you may not feel the need to even try. This is all well and good, actually. If you're not the social type, though, at least recognize that most of the people who work around you are. Very few people like to be pushed around, even if the person doing the pushing is fundamentally trying to do a good thing.

So, what to do? Privately admit your weaknesses in this area and get someone in your department to help you with the interactions and goal-making. This will accomplish the change you think is best for the company and leave you free to concentrate on your strengths.

More and more organizations are moving to Linux and open-source software everyday and there's more reasons than ever to marshall up a proposal to try open-source applications in your organization. Just remember to plan, adapt, and most of all be patient.

Even Linux was not built in a day.

Managing Editor Brian Proffitt, in a time long ago, was once the Configuration Manager for a major real-estate investment trust company in the U.S.