Selling Open Source to Management

by Kevin Bedell

Selecting and using an open source solution for a production application can be a challenge. It's not hard to choose established applications like the Apache Web Server or Linux, but there are other open source projects sprouting up everywhere. How do you know when they are ready for prime time?

More importantly for some of us working in big companies, how do you sell them internally so you can use them?

To begin with, here are some rules to follow when evaluating an open source package. Before opening your mouth and committing to delivering an application by a fixed date, consider these:

 1. Please... Wait until at least a "1.0 release"!

I know it's tempting. I've been there and had to pull myself back from the edge. But if you commit to going to production using a product that's not ready, you may find yourself in the computer room at 1 am the night before acceptance testing checking flight schedules to Jamaica or surfing

 2. Look for an active committer base.

I don't mean one person either. Look for projects where there are commits from a dedicated group happening every day. These are the teams that respond quickly when a major bug is found.

 3. Monitor the email lists for a while.

Are questions routinely answered the same day (or within minutes or hours) by 2 or more people? Imagine that the questions asked were yours - and that hitting launch date was dependent upon somebody answering. Do you trust that someone would be there for you?

 4. - Most importantly, use the software.

Find some little out of the way application where you can test it out. The application doesn't have to be big - but it should be something you use for a while to see how things go.

For example, I'm going to have to build an e-mail processing app next Spring and I've been considering using Jakarta JAMES for it. JAMES has some very cool technologies for building mail apps that may be really useful. So I installed James on one of our servers and built some JUnit tests for testing code I have right now that sends e-mail. Everytime I do a build now, I'm running these tests that excercise my e-mail code by sending email to JAMES and reading it back.

Over the next few months I'll monitor the testing to see if I ever lose messages, or if I have to restart the server often or have other problems. Hopefully I'll get a good feeling for how reliable it is.

So once you've convinced yourself, how do you convince your DLPHB (Dilbert-Like Pointed Haired Boss)?

So how do you convince management you should be using open source? By managing these two words: Fear and Greed.

The Greed part is obvious. Your manager wants to get ahead, right? They get ahead by saving money, hitting deadlines and delivering quality. Open source can help them do all of these. Use these arguments:

 1. Open source means no cost. This translates to:

    - No spending time with sales people

    - No getting purchase orders signed

    - No annual maintenance agreements to budget for

    - No user licenses to keep track of

    - No contracts for review by the company lawyers

 2. Hitting deadlines can be easier:

    - Support responses in minutes or hours

    - Having source code helps isolate bugs faster

    - Drawing on the experience of other users is easier

 3. Delivering quality because:

    - "Many eyes on the code" means bugs are found quickly.

    - All bug listings are on-line. If there are bugs, you know about them.

    - If all else fails, you can fix the code yourself if you need to.

Managing Fear is trickier, though not impossible. It can be harder, because most of the things managers are afraid of can't be easily quantified. Managers fear things like:

  4. The open source project will disappear.

Successful open source projects don't just go away. Assuming you've done your homework and this project is good, the user base will stick around. Even if the project goes away, you still have all the source code - which is more than a vendor going out of business will give you.

  5. The open source project is some 'cool' technology that you want to play with.

Managers sometimes think programmers just like to play with new technologies all the time. That's because many programmers actually do like to play with new technologies all the time.

Look in the mirror here. This is where you make or break the decision. Have you used the product internally for a while? Do you have a prototype? Can you give a demonstration? You can succeed here if you've done your homework and you can communicate things clearly.

Communicating clearly sometimes means talking in 'business terms'. It means talking about saving money, or speeding up delivery, or having an easier time hiring experienced people.

As an example of how to put together a presentation on for management, I've made available a powerpoint presentation to help sell manager-types on using Jakarta Struts. It's yours to use free - you can download it at the companion site for my book, Struts Kick Start.

How have you convinced your management to let you adopt open source? Has it succeeded, or backfired on you?


2002-11-11 22:18:53
No upfront costs would be better
The mix you give for "no costs" are the usual ones. But when you are having a budget that can be used for licensing, consider reserving out of that budget. Test your application and PAY that programmer to fix the features that bug you. It makes better sense and it halfway eases the fear factor as well; by buying support we get that app up better than when it was a commercial app.

The fixes required there are often in the next service pack (every n months) or in the next version.. By paying the programmer the turn around time is superior.

Obviously you can also use your own programmers but that is another headache.

2002-11-11 23:10:13
Thank you.
Looks like a great book proposal.
2002-11-12 09:39:42
Thank you.
Best of luck - I actually agree with you. I wrote this up because I've heard from a number of people who want to use opens source products but are unable to get them approved.

I also thing there are a bunch of managers out there who don't know what questions to ask developers who bring open source projects to them.

2002-11-12 09:45:55
No upfront costs would be better
I agree here as well. One of the topics I was going to cover (before the post starting getting too long) was the idea of 3rd party support for open source apps. This can be a great way to help manage issues.

In fact, this is The JBoss Group's primary business model - they are 'certifying' consultants all over the world on their platform and trying to build a support/customization business.

Another example is Base Beans Engineering. They provide consulting. training and support for Jakarta Struts. In addition, the also do their part to support Struts itself through email list support and other ways.

2002-11-12 14:40:29
"Open source means no cost."?
It wouldn't be wise to say "Open source means no cos" to your management: it wouldn't leave much room for expenses.

My rule of thumb: Buy Microsoft and spend money on software licenses, or use Open Source and spend money on clever people.

Let's be honest: without clever people, you won't get and keep Open Source Software operational. The not-so clever people will only be able to click on Microsoft wizards and use CTRL-ALT-DEL. And if things go wrong with Microsoft, management won't be fired for buying Microsoft.

And let's be honest: management that does not want to spend money on clever people, should not choose for open source.


2002-11-12 15:56:27
Kevin's PowerPoint presentation on selling Struts to "suits"

Is it suppoosed to be a joke?
Using PowerPoint for the presentation!!!
Why not some form of browser accessible file or set of files? Or, would it hurt to illustrate your point using presentation package?

2002-11-12 23:54:10
Thank you
This is the most concise piece I've seen in far too long.

Maybe someday, apps won't gain acceptance by serupticious installations "just-in-time" without the PHB knowing it was even installed. Untill that day, I'll keep "accidentally" installing linux on the second partition...

It baffles me that anyone would develop any type of product without control of the source code and it's dependencies. This article is a well worded rebuttle to that sort of polluted thinking.

2002-11-13 00:34:52
Rewrite this artice as a manager's "howto" to question people proposing open source
Many manager's don't know how to deal with employees proposing to use open source in their company.

You could turn this article around and make it a "manager's check list". This would give them a mental framework for dealing with open source. Once they feel comfortable witht the issue in general they're also more likely to accept specific requests.

2002-11-13 13:35:41
Ouch! But of course you're right.

I had to use powerpoint - my boss made me! ;-P

2002-11-13 13:39:42
Thank you
Thanks for the nice words ;-)

The problems you're talking about are the same reasons I got thinking about all this to begin with. I've had my share of 'invisible' open source apps (let's see, Ant, emacs, cygwin, tomcat, xdoclet, and on and on....).

2002-11-13 13:42:26
Rewrite this artice as a manager's "howto" to question people proposing open source
This is a great idea - thanks!

I agree that a lot of managers don't know how to evaluate the risks associated with open source. They also don't know how to tell their managers why they authorized it...

2002-11-13 14:21:57
One more note of praise for this excellent entry
That's all I had to say, but this space down here requires some sort of content.
2002-11-13 15:05:02
selling open source to management
Easy, find a problem and solve it.

We're a Linux VAR, once we find a problem, we simply put in a Linux box, solve the provblem for a period of time, then return and finish the sale.

From there it's usually easy to upsell other options for the device.


2002-11-14 12:10:29
Harder yet: get mgmnt to open source your software
I recently convinced my employer to allow me to release production software that I developed for them as an open source project. This can be considerably more difficult, and definitely hinges on management's perception of the integrity and the "cleverness" of the developer. The arguments are much the same....

At no new financial cost, your organization can gain:
- improved software quality
- additional functionality
- a long-term maintenance strategy
through an act of goodwill.

Then I gave them some unbilled time, because you should always show gratitude to your user community.

As for this article, I agree that you should follow these guidelines with production functions, but for development, research, and particular niches where there is no affordable alternative, you should not be afraid to experiment. This is THE VERY REASON open source works in the first place.

Perhaps by your logic, no organization should use pre-1.0 software. Thank goodness somebody put some stake in XML or Mozilla before they reached 1.0, but I'll assume it wasn't where you worked.

As for the commits or one man efforts... not every type of software has rapid change cycles or should. It's really a product of size: some open source products may already be pretty stable and tight :)

Jon Roberts

2002-12-13 08:51:19
What is stoping many CIOs from using Open source ?

Great article.

Check out for some more possible selling points.