Section 3.1. Preventing an Open Source Nightmare

3.1. Preventing an Open Source Nightmare

IT departments end up creating open source nightmares, because they don't ask the right questions and they don't prepare for the responsibilities and risks involved. Of course, implementation of commercial technology often ends in a nightmare, too, but that is a different story.

The typical open source nightmare begins when a lead architect or a development team approaches management and suggests using open source for a particular project. In many ways, such requests resemble a child asking a parent if she can have a puppy. The parent generally replies, "Yes, if you promise to take care of it." The child promises to do so, not knowing anything about housebreaking a puppy, what it will take to feed and groom it, and how often it needs to go for a walk. After a while, the child just plays with the puppy and the parent is left to clean up the mess.

While this is a cruel analogy for technologists, it does accurately illustrate one of the major problems with using open source in the enterprise: the difficulty of understanding an IT department's skills. One major cause of open source failure is that the business staff doesn't know the IT department's skill level, and the IT department has an unrealistic view of its own skill level. The amount of work involved in evaluating and deploying open source is also frequently underestimated by IT teams with little open source experience.

The most common open source nightmare involves using open source in a project and having implementation take three or four times as long as expected, because so much needed to be learned to get the job done. A worse situation occurs when the implementation goes smoothly, and the difficulty of supporting or changing an open source project is discovered after the software is in production.

Then, of course, there is the problem of having the person who championed the use of open source leave the company after implementation but before any institutional skills have been built. This is known as a key-person problem.

It is important to note that commercial software is not immune to any of these problems.

A broad oversimplification about open source versus commercial software is that open source represents primarily an investment of time, and commercial software represents primarily an investment of money. Any organization setting out to use open source must set aside some time for research and experimentation. There is no way to skirt this time commitment.

This same sort of work must be done for commercial software as well, but in those cases at almost every turn a vendor or consultant is ready to help exchange time for money.

One implication of this is that anything that systematically reduces the time required to effectively use open source projects increases its value to an organization. In the end, the higher the skills and the more experience an organization has with open source, the more potential value it has. Higher skills reduce the time investment and the cost of using open source, and that increases the promise of using more open source projects. It has been shown over and over again that the most highly skilled organizations are the first to adopt open source, and are the most aggressive in exploiting it. Amazon.com, Google, Yahoo!, Ticketmaster, NASA, academic research labs, and most Wall Street financial firms are heavy users of open source.

This chapter will provide a framework for sober analysis of the biggest factor that eats up time in an open source implementationbuilding skills. Your understanding of the skills and risks involved is the most important factor in determining whether using open source will be a valuable step forward, or a nightmare.