Excerpts from the IT Book review of "Open Source for the Enterprise.", One of the first things that is asked of any new project in a modern IT department is that a cost benefit analysis be created to determine if the investment of time and resources makes sense. This takes many forms, but at many companies the idea of return on investment, or ROI, is king.

Management's goal in asking for an ROI analysis is simple: explain why an open source project (or any other project) is going to help the organization succeed by increasing revenue or saving money. Technologists frequently are annoyed by the request to analyze ROI, for several reasons:
* It is hard to create a defensible approach. The results of almost any ROI analysis can be changed massively, by adjusting assumptions.
* intangible benefits, such as flexibility or creating a simpler architecture, are frequently undervalued or are not included.
* Besides reducing technical costs, technologists have difficulty making reasonable estimates about how the new technology will increase revenue.
At a high level, calculating ROI for open source is pretty much the same as for commercial software. The equation looks something as indicated in the picture.

* Of course, for such an equation to make sense we must understand many things:
* What is the time horizon for the analysis? How long will we get to count revenue or savings against this investment? One year? Two years?
* Is it possible to compare alternatives? Should we choose the fastest time to payback or the largest savings over the long term?
* What are the interest rate assumptions? What is the hurdle rate--that is, the minimum return---for any investment for the company?
* What costs will be included and what will be assumed to be born as infrastructure costs? ROI analyses frequently don't include the extra costs of electric power or bandwidth. Sometimes ROI analysis includes hosting, and other times it doesn't.
* Should reduced costs in the future, or costs than can be avoided, be included? How can such costs be reasonably estimated?
Are the same costs between the alternatives being compared? Has the analysis for one product assumed away costs, or underestimated them? What costs are vendors concealing or disregarding?

How Open Source Costs Differ from Commercial Software Costs

On the return side of the equation there is not much difference between open source and commercial software. Revenue is revenue, and if a computer system helps support it, that's great. It is possible for two different alternatives to meet the goals of creating revenue in different ways, but we can draw no generality about open source always being better to support the creation of revenue. For savings the situation is much the same. Once the estimated savings are determined for each alternative, there is not much to do but compare.

Calculating savings is another black art. It is easiest to do when known costs are eliminated or are replaced with a new set of lower costs. But an honest analysis of savings would have to quantify savings due to differences in reliability, downtime, maintenance procedures, and so on. Many of these issues are hard to quantify in a defensible manner.
Source: 1Prashanth RaiTag(s):Open+Source, Book