So, the BSD family provides professional-grade operating systems?
You might be lucky enough to be sole lord and master of your domain; the only techie at a small office, or a sovereign network manager at a company where technology is not understood. Most of us have to work to sell our solutions internally, however. You can argue about reliability and ease-of-use, but the commercial solutions spend a lot of money creating that exact image. The burden of proof is on you. You must decide which times to prove it, and when to not try.
Think for a moment about an average medium-sized business owner or manager. We're not talking about one of these cool, technically-savvy guys here. The average good manager cares about providing a good work environment, the mounds of paperwork that the government has dumped on him this month, and how his family will react when he comes home late again. He cares about "freedom." But "software freedom" is beyond his experience. He couldn't care less. You cannot make him care. And if this software is so good, why has nobody heard about it?
Even if you're a systems diva, by proposing a BSD solution you're asking your manager to risk his career on your skills. Meanwhile, he knows that a vendor would be there even if your entire department is simultaneously trampled by a herd of runaway llamas. This is a serious uphill battle. Here's some things that can help you.
First, let's look at you. To make this work, you must be respectable. Many BSD and Linux users want to be rebels. (At times it seems even worse in the BSD crowd; there's a certain section of the movement that sees BSD as "more alternative" than Linux, and therefore more cool.) This most often comes out as vendor bias. I know excellent network engineers who cannot relate to their coworkers long enough to hold a civil conversation without a reference to a personal software prejudice. Others are calm most of the time, but when set off, rant at great length about the evils of Microsoft. This appears obsessive and irrational. There's a word for this: demagogue. Demagogues are not respected in the workplace. Without respect, you cannot sell your ideas. Other people are less obviously rebels. If you act like a rebel, people will believe that you're a rebel. Put yourself in your manager's shoes for a moment. Better yet, put yourself in the shoes of the company owner. Are you going to trust your multi-million-dollar company to a rebel? Didn't think so.
Look at the people around you. Check out their pants, their shirts, how their hair is styled. Do you look like them? If you don't, you already have a certain stigma of rebel. Maybe you don't need a tie, but try on a shirt. One with those little round things. They're called "buttons." Your manager has a much easier time supporting someone who understands the proper use of the button API than she would some cocky know-it-all.
Would you wear a shirt with buttons in the cause of promoting BSD?
Should people judge solely by appearance and attitude? No, of course not. Do they? Absolutely. We all do, in the absence of other data. You already are fighting one battle to change hearts and minds. Do you want to fight a two-front war over such diverse subjects as software and respectability? Especially when respectability is your major weapon in the software argument?
You can, of course, go the other route. Greg Lehey looks like a quintessential hacker. He can get away with it because he's very, very good and has the experience to prove it. Most readers of this column aren't in his position. This method is better, but requires years of experience and a great deal of work. By "years of experience" I mean more than five, and preferably more than ten. (The years you endured as a tech support flunky don't count.)
I recommend that you examine yourself. Don't just dismiss this by saying, "Of course I'm respectable." Go look in the mirror for at least 60 whole seconds. One day at work, take a full 2 minutes an hour to consider the conversations you've had in the preceding 58 minutes. Do you have any hint of demagoguery? If so, your respectability just took a hit.
You're competing against an idea of "professional-grade software." Ultimately, professional software is the software used by professionals. If you are professional, your tools are considered professional. Professional recommendations carry weight. Amateur recommendations don't.
So, now that you are considered respectable, let's look at things you need before even proposing a solution.
Many software vendors provide a feature listed on no specifications sheet: deniability. Suppose you implement a BSD-based solution. If it breaks, can you fix it? Don't count on some mysterious developer on some mailing list somewhere; can you, personally, actually get bits under your fingers and fix it with the resources your community offers for immediate use? I can phone Microsoft Support and for the low price of my company AmEx number, someone will walk me through configuring or fixing darn near anything. This is a powerful argument. Fortunately, BSD support is becoming easier to find from companies such as Wasabi Systems and FreeBSD Services Limited. Still, you need to not merely be able to, but enjoy finding solutions quickly and under pressure.
In fact, most managers will happily pay for deniability in their IT infrastructure. They have enough headaches with other problems and the average solution works -- most of the time. If a server goes bad, a manager easily tell his boss "We have contacted Microsoft, and they're working on it with us." This answer gives company owners a warm and fuzzy feeling; everything that can be done is being done. That manager will have a much more difficult time saying "Our resident systems expert is debugging the source code to find the problem." Many managers are quick to find fault with others' work. You might quickly find yourself in a position where someone in authority says "The problem is obviously this 'source code' stuff. Windows doesn't have that. Get rid of it."
Avoiding this requires an honest assessment of your skills. Do you need deniability? What happens if you screw up, or outright fail? Are you willing to stake your job on unmitigated success? Because that's what you're doing.
The best thing you can do is listen to your users before you implement something. What features do they want? Can you provide all of those features with BSD? If not, then your users will not be happy. The solution you provide will take the blame. A BSD solution not only must meet expectations, it must exceed them. Remember, if a user complains about the Exchange server you have deniability -- it's Microsoft's fault. If they complain about your IMAP/exim/BSD solution, you have no deniability. It's your fault.
One of the requirements for providing services on any free Unix platform is knowing how that service works. In Windows, in a few hours I can point-and-click and set up just about any piece of software. This software might not work well. It might not handle everything I want. But it will hobble along and provide what functionality it does offer.
On the other hand, I know someone who has implemented a company-wide single-sign-on solution with OpenBSD and OpenLDAP. It is astonishingly flexible. I also know several companies who could really use this. Unfortunately, I don't know much at all about LDAP. Would I enjoy researching, testing, and implementing this? Absolutely. Should my employer pay me to spend an indefinite length of time learning the intimacies of LDAP so I can implement this with a free system? Absolutely not. Learning LDAP would be a legitimate use of my training benefits, but I must do that before proposing the solution.
These considerations can help you decide what battles to fight, and which ones to avoid, and how to equip yourself to win them. Next time we'll look at demolishing your own case before someone else can.
Michael W. Lucas
Read more Big Scary Daemons columns.
Return to the BSD DevCenter.
Copyright © 2009 O'Reilly Media, Inc.