Pages: 1, 2
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.
Read more Big Scary Daemons columns.
Return to the BSD DevCenter.