Linuxmanship

24 December 2012: trimmed obsolete material.

28 August 2009: fixed a bunch of links, mostly because the Mainstream IT Media doesn't know how to do HTTP Redirects when they change CMSs. Thanks to Rick Moen for updates.

8 May 2009: added a local copy of MSFT evangelism documents

14 December 2005: fixed a bunch of out-of-date links (thanks to Rick Moen for correct URLs.)

New 26 November 2001: added link to Why Open Source Software / Free Software (OSS/FS)?

New 6 Mar 2000: Still.

New 22-23 Jun 1999: Elevator Talk, Benefits vs. Buzzwords, fixed some spelling errors and broken links.

New 11 Apr - 14 Oct 1998: more articles for the Further Reading section.

New 27 Mar 1998: added negative comments, revised "You know you've been advocating Linux too long when..., revised layout. This page now passes weblint -x netscape

New 23 Feb 1998: revised hundredth monkey

New 20 Feb 1998: issues list, links to the Operating System Sucks-Rules-O-Meter.

Accuracy

Everything you say about Linux should be correct. If you don't know, say that you don't know. A good "I don't know" does much more than let people know you're honest. It creates an opportunity to contact somebody again when you find out the answer.

"Remember when you asked if Linux does AppleTalk and I said I didn't know? Well, it does..."

Benefits vs. Buzzwords

A classic piece of sales advice is to sell "benefits, not features." For example, they'll tell you to say "I'm improving web security" instead of "I'm installing the Apache web server."

Unfortunately, many mid-level decision-makers in the IT market make their choices based on features -- sometimes, features that don't have any benefit for their companies. So, start selling benefits, but don't be slow to switch to listing buzzwords if the prospect demands them.

If you're in a meeting with a person who wants to hear benefits and another who's a buzzword hog, take extra time to clarify exactly what the project needs -- white board diagrams are good. Let the buzzword hog sell the other person on why the project needs to be buzzword-compliant, while you concentrate on defining the problem to match the unique selling proposition of the Linux-based solution you're offering. Don't attack the buzzword hog directly.

Boss, the

Sell Linux as high up in the organization as you possibly can. Once you have the big cheese running and advocating Linux, the people who judge an operating system politically will come around. The people who judge an operating system by its merits are already on your side.

You're less likely to find a flaming proprietary software advocate in the corner office, too. The boss will probably have the least emotional investment in the existing proprietary systems, and the most interest in getting things done right, or at least in such a way as to make himself look good.

Closing the sale

If you're selling a Linux-based solution as a consultant or vendor, you are really selling. You'll send an invoice when the goods or services are delivered. But even if you're only advocating Linux within your organization, you're still selling. You're asking management to "spend" some resources, even if it's just a spare computer and some of your time.

If you're a natural born sales person already, you don't need to read this. Welcome to the team, and be sure you have a well-informed support network to help all the people you bring in.

If you're not a natural born sales person, teaching and explaining will be the easy parts for you. The hard part is closing the sale -- getting your prospect to say yes to Linux.

Here is one method of closing. There are others. Please mail me at dmarti@zgp.org if you have another method that works for you.

Offer a series of questions to which the answer is obviously yes. Get the prospect to answer yes. Then, as the last question, ask the person directly and specifically for the business. Be as specific as possible with that last question.

YOU: "Isn't it good to run the most configurable and full-featured web server?"

PROSPECT: "Yes."

YOU: "Isn't it good to get a system that connects to all our existing systems?"

PROSPECT: "Yes."

YOU: "Isn't it great that the budget for this project will be lower than expected if you decide we should go with Linux?"

PROSPECT: "Yes."

YOU: "So would you like me to install it Thursday so we can get started?"

PROSPECT: "Yes."

If the prospect says yes, thank him or her and get that Linux system installed or upgraded (see upgrade). If possible, don't talk with the person again until you have something working. Any conversation after the "yes" is an opportunity for him or her to back off. And don't check with other people before you have something to show. All that will do is give them a chance to shoot your Linux project down. Once you have a "yes," milk it. (See work, hard.)

If the prospect says no, remember that he or she is saying no to the specific offer you made -- not to you or to Linux in general. Practice your Linux and sales skills and come back when you have something new to say and can propose something else. Fortunately there is always something new in the Linux world, and you can get the same prospect again when the need for a new system comes along.

Be persistent. If you come back to a prospect at the right time -- let's say he or she just got off the phone with Support but is still snarled up with a proprietary system -- you might just get something. It might seem like luck, but it's really just being organized enough to ask a lot of people to try Linux, and prepared enough to back up what you say with the facts. The more people you ask the sooner you'll get somebody.

Customer

When you decide to convince someone to use Linux, you just entered sales. The person you want to convince is the customer.

Don't panic. The customer isn't always right, but the customer's concerns are always valid. There is a whole relationship of customer-salesperson that you might not be familiar with, and it's a whole different style of communication from anything you might be called on to do as a programmer, administrator or support person. I'll be addressing it at length in my upcoming book, Programmers are from Mercury, Sales People are From Uranus but in the meantime, use Silence, Falling Inflection and Listening and questioning.

Customers, always dress better than the

"Always dress better than the customers" is the first rule of sales. However, you should only dress one step better. Customer wears jeans, you wear khakis. Customer wears khakis, you wear khakis with a jacket and tie. Customer wears jacket and tie, you wear a suit. Customer wears suit, you wear a little better suit. Not hard.

If you're a full-time employee, and the Linux "customer" is your boss, dress like him or her, not one step better. If you and your boss are of different sexes, dress like somebody of the same sex as you, at your boss's level, who your boss gets along with well. Yes, it cuts into your freedom, but would you rather be running Linux dressed like your boss, or running some proprietary crap-OS dressed like a Linux freak? When your Linux project is hugely successful, you can dress how you want.

Elevator talk

Imagine that you step into an elevator with the CEO of a company you're trying to sell on a Linux-based project. He or she asks you what you're working on. You have 20 seconds to explain the benefits of what you want to do. What would you say?

Keeping your "elevator talk" in mind helps you communicate the advantages of what you're trying to sell. And you never know when you really are going to step on that elevator.

Enabler (Don't be one)

Imagine working next to a crack addict. Imagine that this person was always screwing up -- promising big things but delivering only excuses. Would you start doing the crack addict's work instead of your own so that he or she could sneak out to smoke more crack?

If you wouldn't do it for a human being, why do it for an operating system? If you have trouble getting a proprietary operating system to deliver on its promises, don't let it slide. Get on the phone to Support and stay there.

Investing your time and effort in covering for screwups is "Enabling" and it's bad for people and operating systems alike. Don't cut the proprietary systems any slack.

Sadly, every proprietary system has enablers, and these people often rationalize their situation by turning into advocates of their proprietary systems. Proprietary system advocates aren't evil or stupid. They are the victims. They have a disease and they need help. You wouldn't flame people for having any other disease, so don't flame them for this. They'll come around when their boss does.

Falling Inflection

In spoken English, a statement of fact goes down in pitch at the end. A question goes up. Your statements about Linux are statements of fact, (see Accuracy) and you should make them sound that way by having the pitch go down at the end.

This is the most important rule of sounding credible, and must not be shared with advocates of proprietary systems. If you're serious about advocating Linux, put a dollar in a jar for your favorite good cause every time you let your voice go up at the end of a statement.

Flaming

Flaming, unfortunately, even the most witty, sarcastic flaming you can do, does not count as sales or as effective Linux advocacy. If you feel that flaming people who do stupid things is good for you or for them, please select a stupid habit other than not running Linux and flame people who do that.

Hundredth Monkey

It has been brought to our attention that the "Hundredth Monkey Phenomenon" is bogus. Linux knowledge has apparently been spreading over a worldwide computer network of some kind, not by telepathy. We regret the error. Please see this article by Rick Moen for more information.

If you are trying to spread Linux from home through the use of telepathy or morphogenetic fields, please note that neither one has been shown to work. Instead, do a project using Linux, teach somebody Linux, or write about Linux.

Influencers

Computer people aren't the only ones you need to sell Linux to. Other people, who don't know squat about computers, also influence the purchase of "information technology systems." Which explains a lot.

When talking with influencers, find out what they dislike most about their current information systems. If a Linux solution would not have those bad characteristics, say so.

"I used to get General Protection Faults all the time too, so I upgraded to Linux. I hope Bob decides to go with Linux for your department too."

Issues List

Keep notes on every problem you have with a proprietary operating system, along with the date and time you reported it to Support and the response you got. The problems are called "issues." Proprietary operating system vendors don't like to say "bugs," so you shouldn't either. You must be calm and accurate when discussing your issues list. Don't wear a "NAME OF PROPRIETARY OS SUX, LINUX ROCKS" T-shirt. Be professional. Let yourself be seen reading the proprietary OS manual at lunch. Take lots of notes, and put Post-It® Notes in your copy until it looks like a compost pile. Ask to go to the most expensive proprietary OS training you can find. Make an effort to understand how the proprietary OS is supposed to work, and keep building that issues list. Stay on the line with support until your phone ear hurts.

Remember, though, as a user of a proprietary operating system you are not supposed to "hack" or "work around" your issues. That's enabling. You are supposed to get support, right? Pick up the phone, and save your hacking for Linux projects.

It is easy for supervisors to blame their own people for problems caused by proprietary software the people have to use. You don't buy sixteen pages of ads in your boss's favorite glossy magazine to tell him how much work you can do. Your issues list is your way to record the truth, as completely and fairly as you can, to offset the flood of lies your boss is hearing elsewhere. Your issues list, and the problems that resulted from your issues, will help you sell Linux later. So before you swap jokes with your buddies about how some proprietary OS "sucks," get on the phone, get an answer or an excuse, and take notes.

License Compliance

As a Linux user and administrator, you already comply with the terms of the GNU General Public License. (Easy, isn't it?) If you are in a position to do so, make sure other people comply with proprietary software licenses too. Persuade management of the necessity to do this by digging up cases of license violations.

Don't let license violations slide. If people want proprietary software, they should pay for it. If somebody proposes a proprietary solution, ask them if their budget includes all required licenses.

Listening and questioning

Don't just say that Linux is the ideal solution. First, listen to the person explain what he or she needs. Don't interrupt. Then ask plenty of questions to keep the person talking. Think about the answers. Then ask "anything else?" to give the person a chance to give you a "wish list" for the future.

Think some more, (see Pause Before Answering, The), then recommend a specific Linux-based solution.

Legacy system

1. Any operating system except Linux. 2. Any information project that does not use Linux.

Because the word "legacy" has come to mean "old, expensive, difficult to program, and slow," you should get into the habit of prepending "legacy" to the names of operating systems other than Linux whenever you mention them.

Negative comments

You should always concentrate on the advantages of Linux, not the disadvantages of proprietary systems. If you do make negative comments, make very specific ones. This is OK:

I installed PROPRIETARY MTA NAME AND VERSION on a Foobar 666 running PROPRIETARY OS NAME AND VERSION. It often hung when anyone tried to send a 1400x1200 JPEG image of a spider monkey as a MIME attachment from PROPRIETARY MUA NAME AND VERSION.

This is not:

PROPRIETARY OS hangs all the time, so it makes a lousy mail server.

A detailed problem report will make you seem more credible. A general rant will make you seem less credible. If you tell about a specific problem, people will generalize from it, since they won't remember the details. If you make a general comment it will reflect badly on you.

No Fly Zone, The

When advocating Linux, keep your hands out of the "no fly zone," which extends from top of head to foot and from ear to ear. You should not touch your face, neck, center of chest, or crotch. Having your hands out and separated makes you appear honest and optimistic. Some people say that is it good to make a tent with your fingers, away from your body, when you are considering a question (see Pause Before Answering, The). But don't clasp or wring your hands, or crack your knuckles.

Oops-Linux-Answer, The

When someone asks you how to do something on a proprietary system, just start to give a Linux answer, then catch yourself.

"Why don't you just pipe the....oh, never mind. Hmmm, I don't know how to do that on NAME OF PROPRIETARY SYSTEM either."

Pause Before Answering, The

Don't blurt out an answer right after someone asks you a question about Linux. Pause as if you were thinking. Hey, if you're pausing anyway, you could even think.

Popcorn, Faith

Faith Popcorn, the most famous marketing consultant in the world, has defined a set of Trends (her capital T) that are developing for the future. In her view, a product that is "on-Trend" will succeed. Fortunately for us, Linux fits in just fine with most of them, and is indeed headed for world domination.

Faith Popcorn and Lys Marigold 1996. Clicking: 16 trends to fit your life, your work, and your business. (ISBN 0-88730-694-2)

Quitters

If someone angrily mentions to you that he or she is having trouble with Linux and announces that he or she plans to replace it with something else that is plainly unsuitable, just laugh. You will probably have the urge to laugh anyway, just let it out.

If he or she asks what's so funny, just grin and say, "Nothing...go for it." If the person was really going to switch, nothing you could say at this point would make him or her turn back.

Fortunately, this threat to quit is a bluff. It's a cry for help. Don't start justifying Linux, or denouncing alternatives. Linux isn't on trial, you know it works. If the person wants to turn the conversation into a request for help with Linux, he or she should make the move and ask for help, not blame Linux for his or her problems.

RTFM

Note: this section should now cover "Planet" blog aggregators. Best way to get detailed introductions to new open-source stuff.

Linux is getting the power to do new stuff every day, and there is lots of valuable information buried in the man pages, in the info, in /usr/doc, and on the LDP web site. Not counting the reading you need to do to get stuff working, browse the rest of the documentation. That way you can get an idea of Linux's amazing capabilities, and where to look things up.

Silence

Pause when speaking, even when you know what you're going to say next. Don't talk as filler while thinking of something to say, or say "um..." "uh..." or "duh..."

Still

When you mention that some person or company uses a proprietary OS for some task, say that they are "still using FooOS." It's a quick way to emphasize the fact that proprietary systems are the past and Linux is the future.

Teaching Linux

If you get someone to switch to Linux, help him or her. A Linux advocate is someone who has gotten one project done with Linux and realized the system's incredible power. The key to putting another Linux advocate on the street is getting the person through that first project.

When you read these points, notice how hard they would be to apply to a stupid person. So, if you have a choice of who to teach Linux to, try to pick somebody smart.

1. Unless a question is a really simple one, try to take questions, test answers, and explain answers in that order, not all at once.
2. When somebody says something doesn't work, ask what error message shows up. Most of the time it's a simple error and when the person goes back to try it again and write down the error message, it will work right and he or she will get confidence from having figured it out with "no help" from you. It will also get the person into the habit of paying attention to error messages.
3. Make the person do things for himself or herself to the extent of his or her ability. If you are hoping to make the person into a fully qualified administrator, that means he or she does everything. If you are just getting somebody set up at the user level, ask him or her to navigate dialog boxes and such.
4. Follow up on questions you answer. A simple "How's that smb.conf working out" can get followup questions whose answers will put the person on the road to true productivity.
5. Keep encouraging the person with news of excellent results that others are getting with Linux. If you find another organization that is doing a similar project with Linux, be sure the person knows about it.
6. If you run into trouble, mention as an aside that you're glad you're not trying to do the same task on a proprietary system.
7. When the person is happy after accomplishing something, be impressed and let the person advocate to you.
   

   NEW USER: "I got the web server set up the way I want it. Works great."

   YOU: "That stuff can be a pain to configure. You wouldn't believe how long it took me the first time."

   NEW USER: "Really? It was easy! You were right before when you said Linux rules!"

True

If your Linux solution and a proprietary solution both have feature X, and Linux's version of X has characteristic Y, then use the word "true" to describe any X that is Y. For example, if your favorite distribution of Linux comes with sendmail, list things that sendmail does but another OS's MTA does not, and say that your Linux proposal includes a "true SMTP MTA."

Some good "true"s are "true remote administration," "true mail abuse filtration," "true multitasking" and "true crash protection."

Upgrade

1. Replacing one version of Linux with a later version. 2. Replacing any other operating system with Linux.

Note: Replacing one version of a proprietary operating system with another is not an upgrade. Changing from one proprietary operating system to another is not an upgrade. It is only an upgrade if the computer ends up running Linux.

Unique Selling Proposition

Every product or service should have a Unique Selling Proposition (or USP as the marketing experts say.)

It's something that your Linux proposal offers that nobody else can. For example, if it's a system for a client who doesn't have an administrator, you could choose as your USP the fact that your proposal offers "True Remote Administration."

You're not just selling Linux, you're selling a Linux-based information technology solution. Think of something that Linux offers, that is valuable to your customer, that none of the proprietary alternatives offer. Then emphasize that point and get people to agree that the solution must have it. When they agree with that, close the sale.

User, The

If a person you meet only understands the basic user-level stuff (pointing and clicking and so on) just mention casually that based on current trends, his or her current operating system will shortly be replaced by Linux. Don't go into detail.

The more you do this, and the more Linux users start doing it, the more people will begin to take it for granted. An operating system is not just a computer program -- it's a consensus reality. Building this shared illusion in advance of the OS's actual capabilities is essential. This strategy is being used against open systems, so open systems people should use it right back.

Regular users believe that the information industry is ruled by a conspiracy whose goal is to make them relearn everything every couple years. So they will accept this statement -- if you don't push it, and if they hear it regularly from other Linux people too.

This strategy isn't going to get people demanding that you install Linux for them now. But think of other people's users, and think of the future. Casually mention how great the upgrade to Linux went when you're on airplanes, at conferences, and other places. No need to go into detail, just act relieved that Linux works so much better than that stuff you had before. Remind the user not to invest a lot of time in learning much about proprietary systems since "NAME OF PROPRIETARY SYSTEM is out of here before you know it."

Don't make a big deal out of advocating Linux to users; it's just important that they (1) hear the name from someone they know is knowledgeable (or sounds knowledgeable; see Falling Inflection), and (2) that they remember it's the next upgrade they will have to deal with. When people who don't know you're running Linux start bugging you with questions about it, then you'll know this strategy is working.

"We're an all-NAME OF PROPRIETARY OS shop"

The first multicellular life forms heard this one all the time: "We're an all-unicellular mud flat." Lots of Linux installations used to be all-something-else shops, and somebody had to install it first. So stop complaining, and start installing. Remember that other people have already succeeded in installing Linux in places where policy had been against it.

Don't boast that you plan to move the whole operation over to Linux, just emphasize that Linux works well with the existing systems. Go ahead and emphasize the parts of your Linux proposal, such as hardware, that are the same as the proprietary systems, too. If people assume your proposal involves their favorite proprietary system and not Linux, that's their fault, not yours.

Work, hard

If you sell someone on Linux, be prepared to put in extra time to make it work perfectly and on schedule. You are on the front line of the Linux movement and you can count on help from many people if you do everything you can.

If it's your first Linux project for your employer, take a good look at the building in daylight before you start, because you won't be seeing it for a while. No information project ever goes exactly as planned. But if you sacrifice some time to make the first Linux project go especially well, you will more than make it up in future productivity and fun. It's possible that you will get a raise, a better job, or maybe even a bigger monitor.

You want people to be comparing the performance of indifferently administered proprietary systems to the performance of your tweaked, buffed and tuned Linux system. Since Linux rules to begin with, this extra attention will make it stand out beyond belief.

You have to admit

Don't tell anybody this. If you do, they won't.

You know you've been advocating Linux too long when...

1. Your "please support Linux" rants on warranty registration cards start to run over onto the front.
2. The only proprietary utility name you admit to remembering is "fdisk."
3. You move to another state because the vanity license plate LINUXRLZ is already taken in yours.

Further Reading

Adelstein, Tom. 1999. How to Successfully Sell Linux

Alexander, Stephen. 2000. No business like trade-show business. Infoworld.

Berinato, Scott. 2002. How to Run a Microsoft-Free Shop. CIO. (A "12-step program" to cure a proprietary OS dependency.)

Plamondon, James, et al. Effective Evangelism (and other confidential Microsoft documents, big PDF. This is the strategy that killed off Unix, Netware, and non-Microsoft proprietary developer tools to open up the niche for Linux and free software. Thanks, I think.)

Kirch, John. 1998. Microsoft Windows NT Server 4.0 versus UNIX

Leibovitch, Evan. 1998. The four phases of Linux acceptance: an approach to Linux advocacy.

Litt, Steve. 1998. The Conversion of Troubleshooters.Com Troubleshooting Professional 5:4.

Litt, Steve. 1998. Corporationally Incorrect. Troubleshooting Professional 2:4.

Litt, Steve. 1998. Free software. Troubleshooting Professional 2:5.

Litt, Steve. 1998. Linux issue. Troubleshooting Professional 2:11.

Rogers, Paul. 1997. Linux Advocacy mini-HOWTO. Linux Documentation Project.

Valliere, Rob. 2001. Linux as a Replacement for Windows 2000. An MS-DOS/Microsoft Windows consultant evaluates the Red Hat 7.1 distribution and compares Linux desktop software to a client's existing Windows applications.

Wheeler, David A. 2001. Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!. The most comprehensive summary and index of pro-Linux articles and studies anywhere. This paper summarizes and links to extensive quantitative information comparing free and proprietary software reported in the mainstream IT media and by IT analyst companies. The paper examines market share, reliability, performance, scaleability, security, and total cost of ownership; it also gives commentary on non-quantitative issues and unnecessary fears.

Perl Advocacy from the Perl Institute.

More Computers: Software: Operating Systems: Linux: Advocacy documents from the Open Directory Project.