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 has 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 pages 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, but regardless, we should certainly do our own homework.

One solution is to nominate someone in any software review process 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. The most widely used packages are already in the FLOSS repositories so that installation is often as simple as (for Nagios on a Debian-based Linux system):

   sudo apt-get install nagios

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:

  • I dentify candidates

  • R ead existing reviews

  • C ompare the leading programs' basic attributes to your needs, and then

  • A nalyze the top candidates in more depth.

Another parameter for deciding on a FLOSS package is to engage the authors directly (more difficult with proprietary software) to see how responsive they are to bug reports, how amenable they are to contributed fixes, and how polite/professional they are.

It would be very helpful if such evaluations were also published so that others at UC could make use of them or use them as a starting point for their own evaluations.

Paying for software does not assure quality. Just as 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. Most people who use MS Word use less than 5% of its features. Why pay for something that you don’t use? Is a multi-thousand dollar commercial trouble-ticketing package worth that much if most of the features that were used to justify its purchase are never used? With FLOSS, you could try the full, unrestricted version for as long as you like and see which features you actually need. If you then decide that a commercial package offers these features at a compelling price, it may make sense to buy it.

Besides the unit costs, upgrades of proprietary software have another cost - a cyclic stupidity tax if you will. People become expert at using tools repeatedly, whether they’re carpentry or software tools. While there aren’t many interface changes to be made to a hammer, there are probably hundreds in a new release of MS Office. Re-learning how to use these new interfaces is a nontrivial, periodic loss of productivity, paid for by the customer. With FLOSS, you don’t have to upgrade if you don’t want to, and some tools have maintained the same interface for decades. That may be boring, but it makes using the tools very productive.

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 UC-sized organization, there are probably at least 10 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 and initial use that non-FLOSS packages have. However when you gain that functional knowledge, it can be used to roll out the package to all your departments in bulk for little additional cost. Emphatically not so for commercial packages.

Technical support is another issue where FLOSS is supposed to lag proprietary products, but my personal experience as a research computing support geek is that I have either gotten better support thru open forums or the proprietary support has been so generic and useless that I had to essentially figure it out for myself anyway. There have been a few shining exceptions to this, but in the 30 years I’ve been at this, there have been precious few. The astonishing speed and reach of web search engines has revolutionized software support, altho it has not been noted very much in the trade rags. The error message output of a program, typed into a search engine will almost always reveal the solution for fixing it, obviating the need for paid technical support. UNLESS it’s a proprietary product whose bug-tracking system is shielded from search engines. In that case, you HAVE to go to THEIR technical support and wait until THEY type in the same thing and repeat it to you. I would hazard that free internet technical support for Generally Regarded as Mature FLOSS is both faster and more technically complete than paid technical support for a comparable proprietary product.

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, matched, and mashed up to provide additional functionality for no $ down. 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.