Convincing the Boss to Accept FOSS

In the last decade, I've done plenty of formal research into corporate adoption of open source. For example, I designed a survey and wrote up the results of one research study about business open source use. So I can say authoritatively: At least as of that 2008 research, the major business executive barriers to FOSS adoption are product support, the awareness of available solutions (that is, vendors come calling with a sales pitch, but the CIO might not know an open source option is available), and lack of support by management (i.e. "the boss won't let us"). I've also written the Evans Data open source report for several years, so I know that developers' FOSS perceptions of what's important are very different than the murmurings on the deep-plush-carpeted executive floor.

But statistics go just so far, and most articles about the benefits of open source are written by-and-for techies. No research can show what motivates a hidebound, traditional boss to change his mind about the suitability of an open source application for the company. Very likely, I suspect, the adoption happens eventually because someone who works at the company argues for the new application or OS ("Hey boss, if we used this alternative instead—"), but I'm equally sure that plenty have tried the arm-twisting and failed.

So what does it take to sell the boss on open source? That can be demonstrated best with personal anecdotes — so I set out to get some. In a few online communities, I asked open source advocates how they successfully pitched an open source application. Here, I summarize their responses (generally without detailed attribution, since I didn't ask for it).

Tell them the software is free. Many open source advocates are sure that the way to any boss' heart is through her budget. While developers and other techies may love open source because of such things as its strong community or the philosophy of open source, they also acknowledge that the best way to appeal to the boss may be the bottom line. This attitude may be cynical — "They are always trying to save because they know that whatever is left in their account at the end of the period will go to their pockets," wrote a guy named Al — but I dare say there's plenty of justification in some firms. As a developer named Jason wrote, "I simply insisted that I will make and save them more money. And I did!... It didn't take much to persuade my boss at all."

Be realistic about the pluses and minuses. If you present your preferred open source software as perfect in every way, you'll damage your credibility. Sure, any proprietary software salesthing will speak about his app with glowing praise, but the boss expects that and braces for it. If you act like a fanboy, your recommendation will be downgraded or dismissed. Be realistic about the application's advantages and disadvantages, and about how its open source origins may affect the business.

For example, writes Brian C, "I would first have to convince myself that the enterprise has the resources, culture, and ability to support the FOSS software. If that's so, then I would become the salesman for the proposed software, or recruit one or more of them from among the prospective users — to counter the other salesmen. And of course, the prospective users would themselves have to discover and pitch the functional advantages of the proposed FOSS." Open source adoption often does mean cultural changes, technology training, and adjustments from the familiar, even if the new option is better.

Don't discount your boss' predictable concerns about, say, 24x7 support; raise those issues and explain how the company can address each of them. If you're open about the changes that would occur ("We'd have to hire someone who knows Linux networking...") while also demonstrating the financial and operational benefits, you have a better chance of success.

Find allies. Before you try to sell the boss on the open source option, make sure that your colleagues and business department users are on board. First, they can join in the chorus to use the open source application; more important, perhaps, is that their reluctance could kill the idea because the boss cares about their concerns. Whether or not those concerns are valid. Writes Mark (an old high school friend who was in the same introductory programming classes I was!), "In my case, the management team is all over open source products. It's the technicians that are having problems with some of the concepts, i.e. no certainty on support if/when something breaks."

If you're the enterprise architect, your opinion might have a lot of clout with the CIO. If you're the guy who fixes printers when they jam... perhaps the boss won't accept your advice quite so readily. But it's helpful to get allies no matter where you are in the corporate pecking order, because those people will be affected by the new software adoption. (This isn't a bad habit to acquire. In the upcoming book, The Practical CIO, former GM CIO Jose Carlos Eiras explains at great length the value of building alliances across the business.)

Don't try to sell the boss based on the things that matter to you. Sell the boss on the things that matter to her. As a guy named Gerard pointed out, the boss thinks of support as "picking up a phone when your mission critical app is offline and connecting immediately with a specialist," not "logging into IRC at 2:30 in the morning."

Bosses usually care less about best-of-breed software than they do about "Does it do the job adequately?" and "How little can I think about it once it's installed?" So you need to address the ecosystem in which the software will work. "How interchangeable is the employee in charge of the software? If they won the lottery tomorrow, can I find a replacement easily? How will I know they're qualified? If I'm a PHB, I may not have the technical prowess to determine if the person is bluffing their way through the interview. I need to see evidence, like a certification, that provides some kind of evidence of proficiency," says Gerard.

This doesn't mean that you have to make compromises. Alexandro Colorado, an OpenOffice.org ES Community Lead, writes that the easiest way to get the boss to consider open source is to suggest commercial open source software, such as Red Hat Enterprise, Mandriva Corporate, or SuSE Professional. Depending on the type of application you're pitching, consider Zimbra Enterprise, MySQL Enterprise, SugarCRM, and StarOffice. "The problem with FLOSS sometimes is that we want to push the 'consumer/developer' barebones version of the products and pretend that we can support it on an enterprise/company level by ourselves or [worse], by ignoring the issue," writes Colorado.

Consider a slow-but-sure approach. Juan, an operations manager, suggests you bring open source into the company gradually. "The first step is to start using open source tools to have the work done in secondary tasks, so your boss can see it actually works," he says. "I've seen it with Subversion -> Tortoise SVN -> Trac -> Wiki, Mantis Bugtracking -> LAMP."

Juan isn't the only one to sneak open source in the back door, and let its virtues demonstrate themselves. At Ismail's company, a team of Java developers insisted on Eclipse, Tomcat, MySQL, Linux, Spring, and so on. "When other commercial divisions discovered our practices — bug tracking, release management, source control, to name a few — and realized all our tools are free, their eyes opened," he writes. "Simply mentioning that MySQL provides all the tools necessary for the proposed mid-range solutions, the bosses quickly lost interest in their Microsoft SQL Server licenses. Free is freedom!"

In fact, why mention that it's open source at all? Graham, an IT manager, runs the intranet on LAMP stacks, using Joomla and wikis, uses Nagios for network monitoring, and Scribus for DTP. "All the 'bosses' know is we have solutions that work well," Graham says. The fact that it is open source is secondary."

Another techie writes, "I sell the app and only mention open source if they ask. People just accept that software can be free; no need to explain why its free, you just open yourself up for doubt and a whole pile of follow up questions when they probably aren't going to understand the answers." When a new project comes up, draw up a decision matrix outlining each option's relative merits. If open source wins on technical or other grounds, then so be it. "Quite often it does, and if it won fairly then no one disputes its adoption," wrote this contributor. "This is within large government departments, generally in an information facilitation role, usually at a project management level."

But that won't fly in a lot of companies... so it's time to act like the vendors.

Put together a presentation, just like the vendors do. "Any product should have firm advocates to be adopted by the management," wrote a discussion participant named Raja. "This applies to both FOSS and vendor products. In case of vendor products, the vendor is obviously its firmest advocate. His selling points would definitely include a talk about the superior customer service and better after sales experience. But his talking point must still be the product features and its customizability."

As Raja points out, FOSS resistance stems from the uncertainty of adopting a product which is bereft of advocates within the organization. "You need to be that advocate and do what the vendors do." These activities can include one or more of the following, Raja suggests:

• Construct a prototype with the proposed solution. This is the most recommended and effective way to make your point.
• Use presentation materials to showcase the product features. Use product demos if available.
• Discuss the benefits of custom fitting this product to your organization.
• Talk about the product's community support and adoption.
• Show sites that have already used the product and benefited from it (including endorsements).

All these, supplemented by the zero cost, may allow you to sway your audience. Adds Raja, "I have used these strategies with organizations ranging in size from 10 to 200,000 people." I dare say you may have even better success, because as someone working inside the company you have a lot more information, and you can fine tune the prototype, benefits, and so on to address existing problems that a random vendor won't know about. "Here's what I threw together over the holiday weekend starting with the BlahBlah database" can be much more effective than any vendor's Hello World program.

But don't try to duplicate a commercial vendor's sales pitch exactly. Recommends a contributor named Shyam, you also need to address specific open source aspects of the application you're recommending, including the application's maturity, viable options for commercial support, technical architecture and deployment, security, and the availability of existing skills in the organization. That's before you address the corporate open source policy (assuming you have one — and if not, add another To Do item to the list of "what it'd take for us to adopt this").

This seems like a good start, but I'm sure you can add suggestions from your own experience. How did you convince the boss to adopt FOSS? Tell us about it in the comments.

You should probably follow me on Twitter.