The grassroots efforts of system administrators have brought Linux and other free software into the mainstream. To be an effective advocate for free software at work, you need to speak the language of management and convince them from their point of view. This article discusses how to present your case, why your audience makes all the difference, how to hook them with proof of cost savings, and reveals two secret weapons for your quest to promote free software.

This article explains why bashing Microsoft won’t help you in your case, which migration recommendations will seem the most practical and feasible to management, and how to present those recommendations in terms that management will respond to. It talks about how your goals are different from those of management, and how to adjust your approach accordingly. Finally, it demystifies return on investment (ROI) and shows how you can put together simple calculations to back up your case.

The golden rule of advocacy

The most important thing to remember when you are making a case for free software is to be sensitive to your audience. Who are you talking to? How technical are they? What is most important to them? You must address their concerns. Most people consider it a courtesy if you tell them that you’re researching different free software solutions and you’d like to take their concerns into account as you investigate the options.

The most important thing to remember when you are making a case for free software is to be sensitive to your audience

Tip 1: don’t bash Microsoft

Criticizing Microsoft can be counter-productive in your advocacy for free software. There are three important reasons for this.

Criticizing Microsoft can be counter-productive in your advocacy for free software

The first and best reason is that you really don’t have to. Jupiter Research conducted a survey in 2003 of IT professionals in the small- to mid-size business market, asking what free software they were using and why. The number one reason for migrating to Linux wasn’t cost savings, security, or reliability. Perhaps surprisingly, the primary reason stated for migrating to free software was to get away from Microsoft. Therefore, you don’t have to say anything negative; your audience may be thinking it anyway.

The second reason involves a little pop psychology. Consider this: when you denigrate Microsoft, you insult people who only have experience working with Microsoft. Either your audience or at least a percentage of their reports may be in this camp, so be careful of insulting the base of their professional knowledge.

The third reason is that you will seem more credible and professional if you stick to the positive and resist the urge to use a derogatory nickname.

Tip 2: be practical

Focus on recommendations that will seem the most practical and feasible to your audience. Your campaign should begin on the edges of the enterprise, with systems that are less critical. It’s best to start with migration recommendations for systems that are less likely to cause unacceptable disruption. Remember to consider management’s perception of disruption as you consider potential candidates. For example, e-mail systems can be a difficult place to start unless you have a compelling reason to promote a migration in this area. Management will naturally shy away from migrations perceived to have a high risk of disruption.

In your advocacy efforts, be sure to stress to management that free software adoption doesn’t have to be radical

Basic internet infrastructure is usually the best place to start. Basic web servers, DNS servers, web content, spam/virus filters, and similar services are commonly trusted to Linux and free software. Sometimes it’s possible to get approval for a Linux deployment on reused hardware. So don’t overlook this possibility, especially for file servers. It’s easier for management to say yes when the capital outlay is so low.

In your advocacy efforts, be sure to stress to management that free software adoption doesn’t have to be radical; just a few systems in non-critical roles can add up to savings now and increased staff experience for future deployments.

Tip 3: lose the tech-speak

Sometimes it might seem that management doesn’t take your technical advice seriously. Understand that your goals are different from management’s goals. You want to work with the best technology, advance your career by keeping up with new technologies as they develop, and do your job efficiently using tools that will make your job easier. You’re technology-centric. Management wants to hold down the fort, make sure nothing goes terribly wrong, try to keep people from complaining, and do it all within the budget. They are not technology-centric. Note that the actual technology doesn’t make it into the list of most important goals—it’s just a means.

If your pitch to management focuses primarily on the superiority of the technology, you’re only giving them a small part of the story from their point of view

The significance is that when you focus on the technology, management thinks you don’t understand the big picture. To management, it’s about making things work well enough to keep everyone reasonably happy within the constraints of a budget. If your pitch to management focuses primarily on the superiority of the technology, you’re only giving them a small part of the story from their point of view. Even worse, if you argue about the technology with a colleague in front of management, you’re likely to get even more pushback.

For example, you may recommend dumping the mail server for Sendmail on Linux. Your colleague may advocate Postfix because it’s more secure. When you enter a discussion on the technical merits of each solution, your boss may tune out the tech-speak while perceiving that either solution may pose a risk by being the wrong choice. By focusing on the technical, and especially by debating technical points, you and your colleague introduced more risk (or at least perception of risk) into the equation. So lay off the tech-speak and focus on your two secret weapons instead.

Secret weapon 1: case studies

Management loves case studies. They are anecdotal, easy and quick to read, and easy to identify with. Most importantly, case studies feel like proof to management. Case studies usually reflect their peers—IT directors, mainly, and an endorsement from a peer goes a long way. So start googling.

Case studies feel like proof to management

As you search for case studies to help you in your recommendations, follow these two basic rules:

• Avoid case studies provided by vendors, as they usually sound too much like marketing materials to be truly credible. Your best source is always going to be a magazine because the analysis will be independent.
• Choose case studies that are as similar to your scenario as possible to help management recognize how your free software recommendation would work in your situation as well as it did in the case study. Consider whether the case study is reflective of your industry segment, or if the basic IT landscape is familiar.

To get started, look at a few of the case studies I presented in my book The Practical Manager’s Guide to Open Source.