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 monster.com.
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?