Abstract

FLOSS represents a huge pool of ready-made, well-designed, pre-integrated software that that we can use to improve IT support. And not only is it free, but it promotes sharing, scalability, reduces licensing and support costs, and relieves its users of legal liability more than it encumbers them.

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 Free/Libre/Open Source Software (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 than Netreo.

One of the criticisms 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? Regardless, we have to go the extra distance.

The solution is to nominate someone to evaluate the best FLOSS products. This is often much easier than doing the evaluation on commercial products as the software is 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)

   sudo apt-get install nagios

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

That there is no organizational structure to find and present competing OSS systems highlights the holes in our evaluation process and inattention in our organization, not the lack of good free software.

It is hard for me to emphasize this enough:

The continued lack of appreciation and inability to evaluate the quality of Open source Software is costing University of California tens to hundreds of thousands of dollars a year per campus.

There are extensive methodologies to doing such evaluations. For examples, one of the most extensively 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.

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.