Chris wrote: > I been trying (rather unsuccessfully) to convince various clients and > employers to adopt OpenBSD. Most people, I find, are resistent to > change and would not use anything they are not familiar with. Others > would say that if I leave the job, it would be hard to find people who > can use (or even heard of) OpenBSD and in some places Management never > heard of OpenBSD and have very little clue as to how good or bad it is > compared to Linux/ Solaris and Windows thus they will just knock off > the proposal in 2 seconds. > > Is there any way I could convince these people to make the move to > OpenBSD? Suggestions, tips and tricks along with real life examples > would be much appreciated. Thanks.
*) Respect the work that has come before you. No one likes someone who walks in and says, "Let's change everything, because this is what I know!". Wait until you know the real problems...then deliver solutions based on the problem, not based on your desires. *) Prove to them that you know what you are doing on OTHER things. Solve real problems, make things work better, document existing systems. Give them reason to trust your judgment and quality of work. *) Prove to them that you can (and do) document the systems you are responsible for. *) Point out the relative "unknownness" of various products already in your environment. I.e., if you have a SAN that only one person in the office knows how to configure, you have just won the "not familiar" argument. Even if it is the Indu$try $andard $olution, the "How you configured it in your environment" is critical. *) Point out that people who know OpenBSD may not be falling out of trees, people who REALLY know Linux, Solaris, Cisco, Juniper, EMC, Xiotech, Windows, etc. WELL (i.e., not just a hack with a sheet of paper that would be more useful in the bathroom than on the wall) are not common, either...and if they are really good at what they do, they already have jobs, and you will pay THROUGH THE NOSE and every other orifice you have to get them to come work for you. The ones sitting around waiting for the phone to ring aren't that good. I recently heard a guy enjoying the idea of a $150k/yr job he had heard about to maintain an "industry standard firewall". Why so much? Because there weren't very many good people available to maintain this standard device. AND, the ability to grow-your-own expert was about zero, because you could not grab an old junk machine and build a demo or test machine, you had to shell out big money for their box and their training. And, if you don't pay them a lot, your expert will go elsewhere once you make them an expert. *) Show how easy it is to BUILD your own experts. If you want to learn Solaris, you will be looking at buying some newish computers to run it on. If you want to learn OpenBSD, you can do it on old junk! You can teach your co-workers, they can work with old company equipment to learn more. Try that with the big name products. (funny story: former employer, we built a very nice set of OpenBSD firewalls. Massive redundancy, DR, etc., ALL out of spare parts. An ex-boss got a bug up his butt about having Juniper on his resume, so he brought in a pair of probably $40k Juniper firewalls. But...I don't speak Juniper. "Fine, we'll have E. do it!". E. wasn't quite up to the task, and he got fed up with the BS and quit. Now the boss had NO one who could bring up his babies. He was later fired, and the new resume-stuffing boss didn't like Juniper, but liked Cisco, so in come a new pair of $50k boxes. The never-used Junipers are currently sitting in a warehouse somewhere, and a consultant made a LOT of money replacing our OpenBSD firewalls with the Ciscos that accomplished the EXACT SAME THING). *) Point out that there are a lot of people LOOKING for experts in these "industry standard" systems, and they are not finding good ones. Lots of people looking is BAD for your company, not good! That bids up the prices and that discourages long-term employment. *) Demonstrate, don't talk. Don't say, "it would be nice if you handed me $4000 for this project", grab an old junk machine and build a demonstrator. Do it right -- include the disaster recovery, the backup, the repair and the documentation in your "demonstrator". IF it proves that's all you need, you are done! *) Hook your co-workers. OpenBSD is fun, and it is very easy to learn (not just "load"). I managed to get a co-worker interested, he's now got an OpenBSD machine at home, which has been doing real work for him and solving problems (and the Windows box puked its guts, but the data was stored on Samba on the OpenBSD box, and now his wife is a fan, too! :) Guess what? We now have TWO OpenBSD experts in the office. (which is probably more than we have of the "official" company solution). *) Solve real problems with OpenBSD. On my second day on the job, the guy I was replacing told me about one problem he had -- a mail server would collect huge amounts of mailer error messages in the administrator account...and if it got more than about 50,000 message, the administrator mailbox would fill, and that would cause MORE error messages to be sent to administrator, and the machine would quickly go into a death spiral. It took only about three days for 50,000 messages to be collected. He told me that, we went to lunch, and a couple hours after we got back, I had grabbed some old junk HW and built an OpenBSD machine which automatically POP3ped mail out of the mail server every hour. Problem solved! The junk machine had only a 10G HD and 128M RAM, installing the company standard CentOS on it would have been..a challenge..and the basic OS install would have taken longer than the entire project took. Every time they complain, I ask for hardware which would run CentOS (silence). "What if it breaks?" I point to the rack of old crap hardware (and besides, we can always do what we did before, manually pulling messages out of the thing). *) Document your systems REALLY WELL. I don't mean write the ultimate user's guide for OpenBSD, but document what YOUR machine is doing, how it does it, what tools it uses, how to know it is working properly, how it could be improved, how to recover from a failure, etc. EVERYTHING you would want to know if you suddenly had it thrust upon you and you had no idea what it did. Since most people are horrible at documenting their systems, you have a HUGE leg-up when it comes to the pissing match. My documented system will usually win out over your undocumented system. *) Your documentation should include the things your boss is afraid of, such as what happens if you vanish and no one else has the root password? I wrote it up (basically an over-detailed version of what is in the FAQ) and had him go through the process. He actually was a bit pissed, as he had an agenda which did not include low-cost small name solutions, but you could almost see the thrill of his being able to take control of this locked box (or maybe it was the idea of me "disappearing" :) *) Make sure the solution does not tie them to you. Temping though it may be to ensure your job security by making something only you can maintain, if your boss is not a complete idiot that's what they are afraid of. SO, make sure someone else can at least keep your systems running. Cross train people on your own. Make sure your solutions can survive long into the future. Have an "exit" strategy for how you can migrate to other solutions with minimal disruption (even if your solution is the best in the world, someday, something better may come along...) *) Design your system right. I could (and may) write an entire book on that one sentence, but in short: keep it simple, reliable, maintainable, documented and make sure it can survive past you. Nick.
