The bottom line is that you must do ROI analysis for yourself, whether using commercial or open source solutions. And while the true costs are rarely quantifiable or authoritative, doing the analysis for an open source project is vital, because it can expose the true costs and risks, and help an IT department prepare for them.
Now that all of the ideas about costs are swirling before you, let’s take a close look at how you can create an ROI model to express all of these factors. There are, of course, many ways to go about creating such a model. This section will walk through a flexible approach that should apply to most situations faced by IT departments.
A reasonable way to start an ROI analysis is to start with a spreadsheet that represents the equation mentioned at the beginning of this chapter. Let’s assume a three-year analysis. The first page of the spreadsheet will have one row each for revenue and expenses, and one row for category of cost. At the bottom is a row that totals up the column according to the ROI formula (see Figure 4-1).
Each column represents a time period; let’s assume one quarter.
After the first page of the worksheet is one worksheet page dedicated to each of the revenue and expense categories. The columns of these worksheets are the quarterly periods, just like on the summary sheet. The rows are the specified line items that make up the cost estimates. All the costs are estimated in dollars. If hourly time estimates must be created, they can be done on the rows of the worksheets or on other worksheets. The rest of this chapter will provide suggestions for what might make up the rows of each worksheet.
Consistency in approach is perhaps more important than accuracy in such an analysis, for two reasons. First, accuracy is hard to come by. For some data, it will be possible to get numbers to back up estimates. For example, if an application can be retired and replaced with open source, maintenance no longer needs to be paid and
the resulting savings will be clear. But how much time will be spent installing, evaluating, integrating, maintaining, and supporting the open source solution? These numbers will be hard to come by, especially if an IT department does not have a lot of experience with open source.
Second, if some sort of consistent approach is used, the analysis can be adjusted at the detail or summary level, with some hope that the model will not break down. In this way, it becomes clear to everyone reading the model that certain estimates are based on guesses, all of which are constructed in the same manner. The analysis should explicitly state how the guesses were constructed and why they are justified. For example, an IT department assumes that there will be four production servers and that configuring the first one will take 20 hours. The department can then replicate that configuration to three identical servers in two hours each. It will be possible to track this configuration time and then plug the real data into the model to see how it has changed. Another example: if it turns out that the configuration was underestimated by about 30% in the first 2 of 10 configurations, a new model can be created by reducing the 8 configuration estimates by 30%, if all of them were constructed in the same way.
So, in general, the more granular and measurable the analysis is, the better a planning tool it will be. As an IT department becomes more experienced with open source, its ability to estimate specific costs will improve.
As we noted earlier in this chapter, evaluation costs for open source are generally higher and require different resources than for commercial software. An engineer, for example, will spend a significant amount of time researching and implementing an open source program. The following is a list of jobs an engineer will spend time performing while evaluating an open source project (these could also be included as line items in a cost estimate):
Searching for open source
Creating a test environment
Installing and configuring software
Writing test programs
Researching questions and problems
Researching integration techniques and costs
Networking with open source community members and looking for answers to questions
Installation and configuration costs are the costs of figuring out how to install the software in your test and production environment, and make it work the way you want it to work, by using the settings and parameters that are intended for that purpose. Elements of installation and configuration costs include:
Engineer time spent learning how to install the software in a development environment
Engineer time spent learning how to install the software in a test environment
Engineer time spent learning how to install the software in a production environment
Engineer time spent doing basic performance testing
Engineer time spent developing backup scripts
Engineer time spent learning how to operate the software
Engineer time spent learning how to monitor the software
Engineer time spent integrating the software into production monitoring and alerting systems
Training time for developers
Training time for top operations staff
Integration and customization costs include the planning, design, and development required to integrate the software into an IT department, and to extend the software’s functionality to meet the needs at hand. Elements of integration and customization costs include:
Engineer time spent gathering requirements for integration and customization
Engineer time spent reading source code, documentation, and bulletin boards to understand the workings of the software
Engineer time spent designing the integration and customization
Engineer time spent coding the integration and customization
Engineer time spent testing the integration and customization
Fees for any consultants brought in to help the process
Operations and support costs are the costs incurred to run the open source project in production. Many of these costs are similar to those incurred for commercial software. Elements of operations and support costs include: