Mind your NegaBIT$

There’s every reason to be careful in IT spending, especially (but not only) in these unsettled times. Just as energy conservation is the most efficient mechanism for saving energy (see NegaWatts), the most efficient mechanism for saving money in Information Technology is by NOT paying for that which you do not need to pay for. I call them NegaBIT$ (as in B undles of IT $ you don’t have to spend).

While the direct saving on software costs relative to UC’s deficit is tiny, it can have a multiplier effect, as the use of FLOSS not only has an immediate effect in reducing some costs, but has a much greater effect in the long term as a way of approaching IT and reducing other costs.

An example may be useful. I don’t know the cost of the "Enterprise Monitoring system" we use here (Netreo), but I do know that Google reports ~33,000 hits on it. Nagios, a similar, but Open Source system, has >5,000,000 hits. This doesn’t mean that Netreo is bad software, nor that Nagios is good software, but it certainly should cause ears to perk up and to examine Nagios in closer detail to see why there are 156 times more Google refs to Nagios than to Netreo. Another way of evaluating mindshare is to check how many pages link to the site. Using Google’s advanced search, about 1400 pages link to www.nagios.org, while only 2 link to www.netreo.com.

One of the complaints I’ve heard from people charged with evaluating software is that they can’t obtain comparable information about a competitive FLOSS package as from a commercial vendor. This is an inherent problem with FLOSS. Since the software is free, how can the producers also be expected to provide salespeople and promotional kits that would compete with those from a commercial vendor? If we are going to exploit FLOSS, we have to be prepared to dig a little harder. Or not - would you be willing to accept at face value whatever a commercial vendor tells you? In some cases, especially for the more mature FLOSS systems, they do provide comparable propaganda (sometimes labeled as such), but regardless, we should certainly do our own homework.

The solution is to nominate someone to evaluate the best FLOSS products. This is actually often much easier than doing the evaluation on commercial products as the FLOSS packages are freely available in unrestricted form (and the best known packages, are already in the FLOSS repositories) so that installation is often as simple as (for Nagios on a Debian-based system):

There are an additional ~20 optional (and free) packages that work with Nagios that are available via the same mechanism.

There are extensive methodologies for doing such evaluations. For examples, one of the most best documented is David Wheeler’s IRCA approach:

Paying for software does not assure quality, and not paying for software does not assure catastrophy. One of the best-selling software titles of 1995 was Syncronys Software’s SoftRAM, a Memory Optimizer program for Windows that was eventually shown to do … nothing. This exemplifies just one problem with closed source software - short of actually disassembling the binary executable code, you can’t see how it works so you can’t tell if it’s doing what it says it does. Not that most of us would be going thru the code line by line, but you can bet that there would be geeks out there that were.

There is also the problem of vendor lock-in and transitioning. If you have dedicated an entire infrastructure around a particular commercial software, the vendor obviously knows this and can then increase the renewal or support costs to just shy of lethal levels, knowing that they can. You now have no choice but to pay their ransom or face a huge transition cost. Sometimes this transition is unexpectedly forced on you, as when rivals buy each other and kill or neglect the competing software lines offered by their now-subsidiary.

Why do people choose commercial software over the OSS equivalent? The feature set is a typical explanation of why an organization chooses a commercial product over an OSS one - there are often additional options and features in commercial software packages that OSS ones lack. There is good reason for this. Vendors /have/ to offer something beyond what the OSS has, and often the reason the FLOSS equivalent lacks a feature is that no one uses or has requested it.

Besides the unit costs, commercial software has an additional hidden cost when provided by a large organization - that of negotiating license agreements, packaging and distributing the software, tracking the use and leakage of such software, and providing the accounting reports of such use. For a UCI-sized campus, there are probably 3-4 FTE-equivalents that are involved in this process.

This is not to suggest that FLOSS has no costs - FLOSS packages have the same kinds of costs for configuration that non-FLOSS packages have. However when you gain that functional knowledge, it can be used to roll out the package in bulk for no more cost.

Once you start down this path of exploiting FLOSS, it’s a slippery slope to saving. You can find all kinds of compatible software that can be mixed and matched and mashed up to provide additional functionality for no $ down. And since much FLOSS uses the same underlying libraries, it tends to have a greater overall compatibility.

And when you find a FLOSS solution that works well, you can roll it out to all 100,000 of your closest friends. Now THAT is scalability.

NegaBIT$ indeed.