Using open source to reduce business risk

If you're paying enough in license and support fees on something that can be replaced with an open source product to hire a couple of open source developers instead, then doing that makes sense. in terms of overall business risk reduction.
Written by Paul Murphy, Contributor

Everything considered, especially the fact that it's Easter weekend, you'd expect this blog entry to be about Sun's nearly miraculous escape from IBM and its future as an employee owned business - but it's not, because I think it's too early to tell just how much damage IBM managed to inflict and only the sheer viciousness of the personal attacks now being made on Jonathan Schwartz and other key Sun players supports the idea that Southeastern has played its last big card, and lost.

What I'd like to talk about instead is using open source to protect your IT operation from some of the third party risks attendant on the current recession/depression.

The proposition is that if you spend enough on licensing and support for proprietary software that could be replaced by open source products that not paying those fees would let you hire and retain at least two open source developers, then doing so makes sense because it reduces operational risk while increasing downstream flexibility.

Basically, if you're paying some commercial developer a couple of salaries a year to maintain and support a product, then you're really paying for his development infrastructure: access to source, access to feedback from multiple users, and access to knowledgeable development staff - and because joining the world wide open source community and hiring a couple of developers gives you those same benefits plus better control on how your dollars get spent, you're better off doing it.

Suppose, for example, that your business relies on Sybase ASE - and you pay them several hundred thousand a year in licensing and support. That's a great product: it reliably does what it's supposed to do - but if you hire a couple of committed developers for either MySQL or PostGresSQL they can switch you to their product without much difficulty or transition risk and both will provide the same RDBMS services on the same hardware at about the same level of short term risk. So what changes?

First, you remove a single point of failure from your operation. Sybase is a nice company that makes a pretty good product - but they're in the weathermen's cross hairs: a successful part of the American economy and in California to boot. In contrast the MySQL and PostGres communities are world wide - not by any means immune to what's happening in the economy, but as geographically and economically diversified as it's possible to get.

Second, you get the same access to skills, source code, and user feedback development management at Sysbase gets - plus your people can learn what's unique about your business, contribute beyond the RDBMS agenda, and be held responsible when things go wrong at 3AM.

And, third, you get a significant reduction in barriers to change: other open source adoption becomes easier; you can re-allocate developer time as needed; running two or more open source RDBMS packages costs about the same as running one; and the transition from a proprietory product to an open source one tends to be harder than moving back and much harder than moving between open source packages.

Notice, please, that I'm just using Sybase and its major open source competitors here as an example, not predicting financial or other problems at Sybase - the argument is applicable pretty much across the board for foundation products from LAMP to Java and the latest Sun compilers, and largely applicable (although with more reservations) to applications from OpenOffice to Drupal and Cocoon.

So what's the bottom line? if you're big enough to make it pay, then bringing in open source development expertise connecting your operation to the world wide open source community gives you comparable or better software, better control, more downstream flexibility, and reduced risks - all pretty good things, right?

Editorial standards