Making Effective Software TCO Calculations
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In a previous article, "The Cost of Free Software," I pointed out that Microsoft was completely objective in its assessment of Windows’ TCO when compared to that of free software. Unfortunately, a bug in the way Firefox renders sarcasm caused several readers to take this statement at face value. In case this hasn’t been fixed yet:
<sarcasm>
Vendors are always completely trustworthy and reliable when quoting TCO, and would never skew statistics or select most-favorable configurations.
</sarcasm>
This being the case, it is important that an organization is able to make its own determinations as to the TCO of a system before it switches. Open source advocates are often quick to point out the lower initial cost of their systems. Detractors point to potentially higher maintenance costs. Free software advocates focus more on the freedom aspects and the associated lower cost of migration. All of these are valid points, but none of them tells the whole story. The TCO of any IT system can be broken into four components:
- The purchase price of the system
- The cost of switching to the new system
- The cost of maintaining the system
- The cost of switching away from the system
Each of these must be taken into account when pricing an upgrade.
The Initial Cost
Here free software used to have a clear advantage. At zero cost, it was a clear winner. These days, many commercial software houses have got in on the act and provide zero-cost products in areas where there is a free software competitor. Such companies aim to charge for support, and because they are the only ones with access to the product’s source code, they are the ones who can really offer this support.
Of course, the off-the-shelf cost may be only part of the story. Very often software needs customizing for a particular business use. If you are using free software then you might have more flexibility here, because you (or a contractor employed by your company) can modify the code directly, rather than having to work through a set of exposed interfaces and a bolted-on scripting language.
If you do decide to modify free software, then you either have to maintain a fork of it in-house or get your changes merged back into the main version. The first option can be expensive—you will need to pay someone to periodically merge changes from the main tree into your copy—but it can provide a competitive advantage in the short term. If you are just using the software, not building your business around it, then you lose nothing by releasing your changes, and you gain from the fact other people will help fix bugs in them. Better yet, if your required changes are useful to others, then you may be able to share the cost of having them implemented.