Lesson 1: Don't believe the hype

Lesson 2: Look for signs of life

freshmeat.net is my favourite place to look for open source software.  It currently contains descriptions of around 50,000 projects.  Not surprisingly, not all of those projects are under active development.

The key signs of life are:

• Longevity - has the project been active for more than a couple years?
• Maturity - has the project been through several release phases?
• Activity - has there been a recent release?
• Community interest - is there some evidence of an active community, such as a mailing list or forum?
• Broad developer base - is this a one man show?

Lesson 3: Be prepared to get your hands dirty 

This article is written for prospective users of Open Source software, which doesn't mean you have to have a driving passion for the Open Source philosophy.  There are many people out there who do hold this as a passion and who altruistically donate their time and effort for the cause.  As a user of free software, you may or may not feel an obligation to give something back, but you should at least anticipate that you might have to spend some time investigating possible bugs and feeding that information back to the project.

Only today I had a problem getting the Linux bonding driver going; I needed to increase the throughput between two servers that were configured to mirror their disks from one to the other on every write.  I followed the instructions to the letter.  After checking everything several times over, I went to the mailing list and described my problem in detail.  Full credit to Jay Vosburgh, who responded with some ideas on how I could further debug.  After following through on those ideas, and a couple more email exchanges, we came to a solution.  It turned out to be a bug in the ethernet driver, which will now be referred to the driver maintainer to fix. 

So, sometimes things don't work.  The unanswerable question is, would it have been any smoother if you have invested in commercial software?  When we pay money for software there is a much bigger expectation that it will work with minimal fuss, but with so many different types of hardware and different software and networking configurations out there, there's still a good chance that things will go wrong.

Lesson 4: Understand the risk equation 

I've already touched on risk in several of the points above.  An overall risk assessment looks at all the possible events that could cause things to go wrong, what the probability of occurrence of each event is, and what the consequences (or costs) are if the event does occur.  The sum of (probability times cost) is your risk exposure.  Some of the risks that adoption of open source software might pose to a production environment include:

• Lack of documentation - creating a potential risk to deployment schedule
• Bugs or incomplete features - potentially affecting schedule, user satisfaction, security
  
• Lack of immediate support - posing risk again to schedule
• Project termination or suspension - putting at risk long-term support for the deployment

• Documentation is generally complete and sound
• Bugs and incomplete features are probably equally likely - commercial software is not necessarily tested any better than open source, the driving requirement for speed to market often means seemingly non-essential features are skipped, the prevalence of bugs is largely a function of the size of the user base, and security issues are rife in both forms of software.
• First level support is typically next business day, but should a software patch be required, it could take months until the next release.
  
• Companies go out of business every day and take their proprietary software with them

Lesson 5: Understand the cost equation 

Imagine building your own house from materials that you harvest from your own back yard.  It's an enormous undertaking, but at the end you have a house, a permanent asset, which has cost you relatively little compared to buying it outright.  It has also been a fair bit of up-front effort compared to, say, renting.

The first case is analogous to designing and coding your own software, compared to the big up-front cost of buying a perpetual license.  Or, software is often sold on the 'renting' model, where you can only continue to use it as long as you keep paying.

Now imagine that you're planning to buld your own house, and a team of benefactors comes by and delivers tons of building materials to your (still to be constructed) door, and they even put some of the materials together for you - perhaps a few nicely furnished rooms and some kitchen cupboards.  Your job now is just to finish off the remaining pieces and then you have that permanent asset, almost as if you had built it from scratch.  This is the Open Source analogy.

 So, the Open Source route is a fantastic way to leverage existing software without a massive up-front investment.  But it's not for everyone; continuing the analogy above, unless you or your team rank as "home handyman" or better in the software world, you may have no choice but to pay for a fully supported commercial package.

Conclusions

As with all engineering choices, do your homework, weigh your options, and make a sound decision based on good information and evaluation.  Make sure you consider Open Source as one of your options.