It may be surprising to those not actively engaged in the open source revolution, but when I talk to clients about their business problems I don’t have to spend much time, if any, selling the benefits of open source. Most of the businesses we talk to already get it. But every once-in-a-while someone will ask me, “Why open source?”. So I thought I’d talk about some of the reasons why Optaros clients choose open source.

There are many reasons why our clients choose open source. Some clients are initially attracted to open source by the idea that they may be able to lower their total cost of ownership by shifting a portion of their license dollars to services and saving the rest. While that is a consideration, it’s not the whole story. In addition to lower cost, there are at least three other major factors that make assembling solutions from open source components an attractive option for our clients:

1. Open source solutions are often a better fit.
2. Open source solutions are often standards-based.
3. Open source solutions are more transparent.

Let’s look at each of these.

1. Open source solutions are often a better fit.

It has been fairly well documented that companies have over-spent on things like application servers and content management solutions. As a whole the number is easily in the billions of dollars every year. Clients buy into the vendor pitch that a particular package can address all current and most future needs. They spend six figures on up front licenses, three to five times that on services to implement and customize the solution, and then 25% to 40% of the license fee every year on support and maintenance.

In the end they have a very complex, heavily-customized solution that takes a disproportionately large staff to run-and-maintain. They might use a fraction of the functionality the product provides out-of-the-box.

That would be bad enough if the functionality used was a fit with what the business needed. But the real kick in the shins is that after the product is installed the client may still need to go through major efforts to customize, extend, or tweak the system to make it fit their business.

Open source projects tend to offer the lower common denominator of functionality. Without spending anything on up-front licenses, you get what’s common across most installations. You can take what you would have spent on those licenses and spend them on services to fill in the gaps resulting in a closer fit to the business needs at a lower total cost.

As a quick aside regarding lower total cost, let me not paint too rosy of a picture here. Most clients pay someone to support their open source solutions. (As opposed to proprietary vendors, clients actually have a choice of support providers). Commercial support for open source software certainly isn’t free and often suffers from the same issues as closed source software support (slow response, foggy escalation procedures, shallow technical depth).

The point is that you don’t have to buy giant, sprawling platforms to get something that merely approximates your requirements—instead you can assemble solutions from open source components that get you closer to exactly what you need without up-front licenses.

2. Open source solutions are often standards-based.

Open source solutions are often based on established standards (or even built on top of other open source projects). This happens naturally–it is a lot easier, from a collaboration stand point and for sheer level of effort, for an open source community to build upon an established industry standard or other open source projects than it is to come up with a proprietary solution from scratch. Conversely, closed-source vendors invest time and money in proprietary standards to use as a competitive advantage.

Why are open standards important? For a couple of reasons. First, the pool of people in the market place who can quickly get up to speed on your system is far greater than for proprietary systems. As an exercise in the content management space, try searching Monster for people who know Documentum’s WDK. Then, try searching for people who know Spring, Hibernate, or JavaServer Faces (JSF), some of the core technologies behind Alfresco, an open source Documentum competitor.

The other reason why open standards are important is because it means greater flexibility. This flexibility might manifest itself as the ability to swap components in and out to fit the technology preferences at the client or to take advantage of specialized functionality. And it can mean lower switching costs. For example, maybe the repository solution needs to be switched out and because it is standards-based, content migration is easier. Or maybe switching out the portal isn’t as painful because the repository is JSR-170 compliant which makes it easier for other systems, like portals, to get content into and out of the repository.

Proprietary vendors often claim to be “open” and “standards-based”. Usually they are putting lipstick on a pig. The fact that your proprietary repository can store XML does not make it “open” or “standards-based”.

Of course, just because a system is open source does not guarantee 100% interoperability but, in general, open source solutions are much more open and standards-based than their closed source counterparts.

3. Open source solutions are more transparent.

The obvious example of transparency is that clients get the source code. Access to the source is invaluable when troubleshooting or customizing. Clients with proprietary solutions are often forced to decompile vendor code–a clear violation of most license agreements–just to figure out how to properly extend a component.

Beyond troubleshooting or customizing, the source offers an opportunity to help the community improve the product with bug fixes or enhancements. And clients can influence product growth and direction much more easily in the open source world because they can download and build nightly software releases as development is happening. Contrast that with the partner-only “early beta” software release approach of closed source companies.

The way open projects are run is also transparent. When a client invests in a critical piece of infrastructure, they need to know what the issues are with the system and they need access to people who have a deep understanding of the system. Closed-source vendors work to hide bug information for fear of hurting sales. And they tightly control access to the hardcore engineers, usually reserving access to them for “Enterprise” customers paying top dollar for the privilege.

Open source projects, on the other hand, usually provide full access to bug tracking. Clients can vote for and monitor issues they care about. Beyond that, they often make product road maps available in wikis, and low-level product planning and technical discussions available in forums. (Alfresco is one good example of this behavior but is by no means unique).

Open source developers aren’t secluded–they are usually active participants in the community around the project. These communities, made up of product development engineers (often working for commercial open source companies), integrators, consultants, corporate developers, and end-users serve as a valuable support resource for clients that is usually much more useful than the closed pay-for-support system offered by proprietary vendors.

Conclusion

I could add that many clients see solutions assembled from open source as having better stability, faster performance, improved security, and a shorter implementation time but these advantages all tend to accrue as a result of the benefits I’ve outlined above.

I’ll leave you with an anecdote I think is fairly telling. Six or seven years ago, clients would tell me they’d only consider open source as a last resort (if they even knew what it was). Last year, I was talking to a large client with a household name who said, “Our CIO has issued an edict which is essentially ‘open source first’. If we’re going to propose a solution using closed source software, we’d better have a very good reason.” For that client, I’d say open source had reached a tipping point. How far can we be from the rest of the world’s CIOs taking the same stand?