![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
Linux users are a notorious bunch. We tend to be vociferous OS bigots of the first order. This is a trait that has served the software community well. After all, if we were not that way we would never have put the time and effort into developing, deploying, and supporting the thing. But it also a trait that has drawbacks. Some of these drawbacks are serious, and effect our ability to present Linux as a serious alternative to other, more prominent OS's (using the term, in many cases, very loosely).
I'm not going to try to present the Linux alternative in anything but a fair and honest way. That means I'm not going to be talking about the possibility of loosing your job for choosing Linux -- after all, that is not a problem that is unique or limited to any one OS. The fact is that when you choose the wrong tool for mission critical applications, you should be called to task for that choice. This is regardless of the OS's involved. Likewise I will not clamor on that Linux is the one, true solution to all problems. Such a statement, however much I'd like it to be so, is just as foolish.
But, I wish to be clear that I will not have many good things to say about those other OS's. For the most part they are deserving of their poor reputations and of the scorn of any true Linux afficionado. Still, there are better and worse ways of promoting the Nearly One True OS that is Linux. In this paper I would like to discuss some of those options.
A few weeks ago I helped a friend (we'll call him Mike, being that that is his name and I could care less about his anonymity) install Red Hat 5.0 on his system. I made certain that all the configuration files were properly tweaked for his particular computer. I installed KDE, and made KDM the default login method. I set up his networking, making sure that it handled everything seamlessly in the background. Then I showed him where the docs, howto's, mini-howto's and the like were located. I spent time with him making sure he knew how to use info, find, grep, ps, which, apropos and the man pages. After a few hours of work and teaching, I went my happy way convinced that another conversion to the Linux way (tm) had taken place. After all, Mike hated Windows and had had nothing but problems with both 95 and NT.
But the next week when I stopped over, I found my friend was back to running Windows 95, unhappy as ever about his daily crashes and computer problems. It is important to understand that Mike isn't some luser; rather, he is a sophisticated computer professional with substantial computer knowledge. He has been a consulting parter with me for major corporations, and has worked on developing a number of expert systems. He knows his stuff very well. So why, then, did Mike fail to embrace the Linux alternative?
The answer, unfortunately, is one we advocates hear all the time. The new user of the Linux system finds that the learning curve is too steep to be manageable. Like many other people, Mike has a real life - he has a job, a girlfriend, various projects and hobbies, and he can not spend all his free time learning a new way of being productive. Moreover, he can't afford to devote the days or even weeks it might take him to learn how to administer a system so that he can accomplish even simple tasks. He needs to be productive today, and tomorrow, at the same rate he was yesterday. Because Mike is already familiar with the system and applications on the windows box, and not with those on Linux, he could not afford to switch. When the initial learning curve is so steep getting to be equally productive when moving from another OS to Linux can be daunting. This is even more true if one is an expert user on the non-Linux machine.
Many OS Bigots (myself included on my more polemical days) will counter that it is simply untrue that it takes that long to learn a new system. Or we'll simply deny that Linux is really all that complicated. Instead of recognizing any validity in the statements made by the complainants, we attempt to invalidate the complaint by suggesting that the person in question must be a luser instead of a user. ``I learned Unix in a couple of hours,'' or ``Heck, just pick up Unix Unleashed and read it,'' are statements that carry the implication that the person being addressed is somehow not as competent as the speaker.
This approach does more damage to the Linux (and Unix) community than many people realize. We have good solutions to many problems, but if we aren't willing to take the people who need those solutions seriously, we will not be heard.
So, the question arises, ``How do we Linux users, developers, and advocates help those with limited time for learning new systems make the switch?'' There are several answers to this question, but they almost all fall into three categories. I call these categories the OS/2 revisited approach, the suck it up approach, and the delayed skill transfer approach. What are these methods? Glad you asked!
The first, the OS/2 revisited approach, consists of making windows available on or under the new OS. IBM had moderate success in getting dissatisfied users to switch to their products by providing a technically superior system that managed to provide the user with their favorite windows applications. Linux has a number of programs and libraries available that help with this approach. DOSEMU, the TWIN library, WINE, WABI, and others are all efforts to provide the user with access to his favorite MS products.
This approach has some big dividends. The user is able to transfer many of his or her skills immediately. There is little trepidation in wondering how to do word processing on the very same word-processor you've been using for the last 2 years. There is far less worry about being able to get your work done when you don't have to worry about finding and learning new applications in order to accomplish your normal tasks.
However, this approach does have some problems. Today, the most obvious is that windows95 apps are not nearly as portable to Linux emulation as are the older 3.x apps. This means that many users are not able to bring over their favorite applications any more. Rather, the user needs to find and obtain an outdated version of his or her favorite product. The user then will need to worry about reformatting old data and projects to use the older program, as well as concerning themselves with being able to share their data seamlessly with coworkers.
Another major drawback with this approach, as IBM found out, is that the users are not encouraged to explore the power of the underlying OS. ``A better memory manager for windows'' is not what Linux is about. It is not what it does best. And, like OS/2, eventually users who use it for that purpose will realize that the increased complexity doesn't pay out any real dividends. The reason OS/2 failed (regardless of what the various OS/2 pundits say, it is dead) is the same reason these various projects will never really be the answer to Linux advocacy. They don't really solve the problem of getting users up on the new OS. All they do is offer a false sense of security at a cost of complexity and a lack of compatibility with state-of-the-art Windows environments (if there is such a thing.)
The trend to develop Windows95-like applications such as StarOffice on Unix platforms seems to be an extension of this methodology. Instead of embracing the tenants of ``small is beautiful'' and ``make each program do one thing well,'' these development efforts are aimed at reproducing the Suite on Unix. The advantage of this, is, of course, that it is what managers expect to find on their computers. The disadvantage is that the ``Office Suite,'' in all it's ugly, bloated, glory is now nestled into the Unix culture. Most true devotee's of Unix will likely dismiss these suites as being against the Unix grain. Still, they present a way to move reluctant Windows95 people into the Unix world.
The suck it up approach, also known as the sink or swim method can and does work. I, for example, simply reformatted my hard-drive one day, and never looked back. However, for most people in real-life business environments, this isn't possible. Unlike most people, I really did have lots of time to explore my system, and being in graduate school, I had few applications I really needed to run. ``Mission Critical'' doesn't apply to most people in master's programs. Like the example of Mike, above, the real user just doesn't have the time to waste on learning how to be productive all over again. Still, for some users, it can work. The key is having good teachers who are also good system administrators on hand to help the user along. Had I been willing to visit Mike on a daily basis to hand hold while he got up to speed, he would probably be running on Red Hat instead of Redmond.
The advantage to this method is that it doesn't rely on a sense of security. Unlike OS/2 revisited, the suck it up'ers have to dive into the system, they have to tackle the learning curve, and with good teachers it can happen fairly quickly. Most people can learn the basics of Emacs, LaTeX, Unix shells and command lines, and the various other Unix tools and tricks in a week or less. While there may still be some touch and go moments when problems with system administration raise their ugly head, for the most part, after some intensive training and a few moments of butterflies in the stomach, the person can manage to get along.
The problem with this approach is, of course, that it takes a leap of faith, that most people are very leery of making. And, I might add, they are right to be leery of doing it this way. Some people simply won't get the new way no matter how patient you are, because they will be stressing out over some project that they are working on. Others, because of various concerns about being able to get the job done, simply won't leave the tried and true - no matter how obvious it is that it is really tried and found wanting. Let's face it, most people are nervous about the unknown, and moving to Linux is the unknown for someone whose only computer experience is MS or Mac based. Here again, the aforementioned Office-ish suites can come in very handy. While rarely the best tool for any one job, they can be used to make the suck it up'er more comfortable in his or her new environment.
It is important to realize that there is always the occasional person whose task still can not be adequately completed under Linux. There are specialty apps which require MS or Mac products to run. For these people, leaping before looking, long and hard, can be disastrous. And, we gurus need to be aware that one story from such a person on newsgroups and mailing lists goes as far as ten stories of positive experiences. Trying to coerce most people into the suck it up method is just asking for trouble. You risk your credibility about OS matters on your ability to teach and support someone in learning a new environment. This is a gamble that most likely won't pay off often enough to be worth the risk. Our most powerful weapon in the Linux community has always been our honesty and integrity when it comes to the products we advocate. To push someone to use a system they are not ready for can have deleterious effects on that reputation.
This brings us to the last method - the delayed skill transfer approach. What is this? It's simple -- give Windows, NT and Mac users Unix tools to use on their current projects! Simple, huh? The problem is, in our zest to push the Linux point of view on people, we often forget that we can give some demonstration of the power of the Unix way which is utterly non-threatening to new users. By replacing the command windows prompt with bash, by changing dir to ls, by adding ghostview, ghostscript, emacs, perl, LaTeX and other tools to the Windows environment, we allow for users to develop their skills and confidence in Unix methods without compromising their ability to currently work.
While this method may take longer to get any particular user up and running in a completely Linux-only environment, it also offers the most benefits with the fewest drawbacks. The benefits of the OS/2 revisited method, namely that of having tools that you are comfortable with, is realized without the deficit of having to rely on out-dated versions or be worried about underlying complexities. The drawbacks of the suck it up approach are avoided as the users are given plenty of time to become familiar with the new tools in an environment that doesn't endanger any current projects. Thus the users are less stressed and more open to trying new things, for the new things don't entail the need to be concerned about not being able to accomplish critical tasks.
Further, after a few weeks or months, those ``mission critical'' tasks are now being accomplished on Unix tools that have been ported to the user's (soon to be formerly) favorite platform. Thus, when the switch over to Linux comes, the user no longer has to learn two new things - how to be productive and how to system manage. Instead, they are instantly productive and can learn the underlying system at their leisure. More often than not they will come to want the extra functionality of things like named pipes, IPC, and other Unix niceties that are unavailable in their scaled down ports.
While this seems to be a fairly obvious method of helping users move to Unix environments it seems to be one of the least attempted. There are a few reasons for this.
The point of all this is that there is more than one way to skin a cat (or in the case of Gates-ware, a weasel). Linux advocacy can, and should, take forms that are appropriate to the particular situation of a particular user. A student in a computer science program with lots of free-time probably should opt for the suck it up approach. A person with plenty of support from a local administrator and plenty of legacy apps might benefit greatly from the OS/2 revisited method. And, most importantly, we can't forget that promoting Unix tools under other OS's is a form of advocacy. More importantly, in an environment where mission critical apps and projects abound, it may be the most effective form of advocacy. Keep up with available ports of your favorite Unix tools under other systems, and you can increase your conversion success rate!
This document was generated using the LaTeX2HTML translator Version 98.1 release (February 19th, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 lj_advocacy.tex.
The translation was initiated by David Wagle on 1998-03-23