Open Source Software - benefits and pitfalls.

A personal view

Introduction

Open source software has been in use in the enterprise for a long time now - certainly over 20 years. My first serious experience was in the late 1980s when I was looking for a way to use C++ on a development project based on Unix System V minicomputers, and discovered the GNU project would give us for free what we'd otherwise have to pay AT&T an arm and a leg for.

I've never looked back. And nor has the rest of industry. It is hard indeed to find a commercial organisation which doesn't rely on open source somewhere, even if it's just because that's the operating system in their network routers.

But while open source has become a respectable and vital part of the mix, it hasn't killed off the commercial vendors. Quite the contrary. Many successful companies run open source and commercial products side-by-side, and while others spend advertising money decrying the 'free' alternatives, you can't help feeling that even they are secretly pleased to have such a convenient target to aim at.

If you've been reading any of my other articles, you'll know that my particular interest is in the deployment of software on a large scale in the enterprise. So what are the real benefits and pitfalls of adopting open source rather than an alternative?

And to avoid niggles, let me say that I'm not going to be terribly careful about distinguishing open source, community developed etc, or in worrying about the legal subtleties of different licensing schemes. These factors seem to be terribly important to some companies, while others ignore the distinction without obvious ill effects. If as a firm, you have an aversion to certain forms of license, then that will make your decision for you, and nothing I say is likely to affect that decision.

Business Applications and Operating Systems

Let's deal with the easiest cases first. True business applications, the ones which exist to provide end-user functionality focused on a business need, and for which IT is merely the enabler, tend to have few if any credible open-source offerings. The exception is perhaps in areas like e-commerce which are intricately tied-in to the technology infrastructure, but even here, there is little of real importance to the large enterprise. The reason is not hard to find. Most open source software is open source because there's a sufficient pool of developers in the community willing to work at making it better, and that is most likely to happen because the developers themselves are interested in its capabilities and have some insight into how it should work.

And what do developers get enthused by? Technology-focused applications, that's what. So the core of true business applications tends to be developed at their expense by a vendor, and is unlikely to be opened out. As a result, it is rare for a short-list of business applications to include both open source and fully-commercial products.

At the other end of the scale, operating system and other similar decisions tend to have a logic all their own, and tend to be made by people who probaby know as much as I do about it. But the choice tends to be fairly straightforward - if you're a Microsoft shop, you're going to be buying Windows. If you're a Unix shop, then you're probably using open source, unless you're committed to Solaris on Sparc or AIX on a mainframe or something similar.

Middleware etc.

The real interest these days lies with midddleware, databases, and other enabling technologies which are used as building blocks, and with technology frameworks and toolkits aimed at developers or system administrators. Here it's not unusual to find the open source products are not only cheaper to license but better and more widely used than the alternatives. The vendors make their money by selling expertise, or by providing value added 'enterprise features' at a cost, while relying on grassroots enthusiasm to build momentum.

Decision making

Some interesting questions come to mind:

• Is TCO the right measure of the financial impact of introducing open source vs paid-for software, and if so, how to measure it?
• How do you compare the support models?
• What are the risks?
• And how, if at all, can you control its introduction?

The first question looks as though it should be easy. TCO by definition is the thing you want to measure if you are comparing the financial effects of different products. So just apply your standard TCO methodology ( you do have one, don't you ) and out pops an answer.

Well, maybe. You can certainly compare the costs of licensing, and maintenance agreements, which, strangely, will always look good for the free stuff, and you can look at technology footprints to estimate the setup and running costs. But how do you quantify the value received from that license and maintenance fee, and compare it with the value of access to the source code, and the existence of support forums and other resources. And what about influence. If you are a major player, will you have more influence on the evolution of an open source product or a commercial one from a vendor who gets lots of your money?

Moving on to the risks, I've already alluded to the legal issues. But the biggest risks from any significant technology investment are the short-term one, that it fails to deliver enough of what it was introduced to achieve, and the long-term one, that it ends up having been the wrong horse to back, and sooner or later becomes a drag on the organisation, ripe only for retirement and replacement with something new and more exciting. The long-term, argument doesn't seem to be greatly influenced by whether open-source is involved. We can all find examples of both commercial technologies from major vendors and open-source projects with huge support which ultimately faded away or were overtaken. As for the short-term argument, well it should be obvious that picking a product which won't cut it just because it's free is silly. But choosing to buy one just because it's the market leader is equally silly. However, in the second case, there's a major firm to deal with, and you can often negotiate a deal in a way which shares that short-term risk with the vendor, either through extended pilots, free consultancy or whatever, something not really available if there's nobody to get paid.

The sting in the tail

So far, it may well appear that open source offers no particular challenges - it's just a different way of sourcing necessary software. But there is one big difference, one which, depending on the culture of the organisation, may turn out to be crucial. And that is that since open source software is available to anyone who wants it without ceremony, none of the usual purchasing controls etc can prevent people within the organisation from getting hold of it and ( at least in a development environment ) using it.

This matters, because a considerable head of steam around a particular open source solution can easily develop within a project team quite off the radar of the normal control processes, leading to one of those awkward situations in which there's little choice but to introduce a de-facto solution based on unapproved product choices. There are some similarities here with the problems I discuss in my Facing the contradiction paper.

Not only is control of the introduction of open source products harder to enforce, it's also harder to persuade individuals of its necessity. The TCO-based argument may appeal to budget holders, but most development teams don't really control their own finances directly, and most organisations don't have financial systems capable of making the true cost of a technology visible to those picking it in the first place. So picking an open source framework or service layer has little obvious downside.

Solutions

One approach which can work consists of embracing what you can't control. Rather than pushing open source pilots underground till they emerge fully grown and dangerous, encourage them, but put reasonable conditions on those involved, like requiring them to evaluate them properly and to have appropriate stop/go decision points. The right level of control will depend on the individual product category. As a rough guess, individual open-source development libraries are relatively innocuous, whereas the unconstrained introduction of any new enterprise-wide database infrastructure is probably a serious mistake, whether open source or not. Middleware and client-server based products fall somewhere inbetween, while true end-user business applications are still rare enough that it's probably safe not to worry about them very much at this point.