Whether open source will work at any company depends on both the capabilities of the company and the maturity of the open source software. The fact is that some open source is so rickety that it isn’t useful to anyone except the most highly skilled. If you browse the popular directories of open source software, it doesn’t take long to find dormant projects that have not been updated for years. For example, Cheetah, a Python-powered template engine, was posted on the http://www.freshmeat.net site on July 15, 2001, was updated July 16, 2001, and hasn’t been touched since. Other open source software, such as the Apache Web Server, is at the other end of the quality spectrum; it is widely considered better in every way than all the commercial alternatives, and it is as easy to use. Thousands of projects occupy the space in between these two extremes.
Not all users of open source are equal. Given the IT budget of Amazon, Google, Yahoo!, or Ticketmaster and the pedigree of their engineering staff, it is no wonder that they can make open source work. They could write their systems in assembly language. But when you look far from the gurus of Silicon Valley and focus instead on the city of Houston, or on the Ernie Ball Company, a guitar-string maker that’s run entirely on open source software, you must realize that there is some middle ground. You don’t have to be an MIT Ph.D. to make open source work for your business or organization.
The difference between the successful open source implementation, in which the value of open source is realized for a company, and the unsuccessful one, in which the struggle to use open source is not worth the effort, amounts to knowing your problem, knowing the software, and knowing yourself.
The key to a successful outcome in applying open source is a thorough understanding of answers to the following questions:
What problem are you trying to solve?
How would open source software help in providing the solution?
Does any open source software provide all or part of the solution?
How can the maturity and stability of relevant open source software be determined?
What skills are required to install, configure, customize, integrate, operate, and maintain the open source software?
Does your organization have the needed skills? If not, how can they be acquired and institutionalized?
In which cases does the value provided by the open source software exceed the cost of using and maintaining it, compared with other solutions?
This book approaches these questions in terms of skills, risks, and fully loaded costs. An IT department that intends to adopt open source must have not only the resources to do so, but also a belief in skills building and an inclination to take increased responsibility for its IT infrastructure. In Chapters 1 through 5 of this book, we analyze the nature of open source and describe three different models that can help companies evaluate the vast world of open source in a manner that is consistent and enables them to understand their own capabilities.
The models presented are:
A set of questions that help determine the stability and maturity of an open source project, the responsibilities involved in using a particular piece of open source, and the skills needed to manage those risks
A set of questions that help determine the ability of an organization to handle various risks and the tolerance of risk for a specific project
A set of questions that help determine the total costs and risks of using open source as a solution for a project
With the information collected in using these models, half of the problem—knowing what you are getting yourself into—is solved. An IT department will be able to avoid choosing open source projects that are immature or ill-suited to its skills. The other half of the problem is finding the right open source project for a particular task, which can be vexing.
Finding open source that you can relate to your needs is all too easy. Go to http://www.sourceforge.net/ and you will find an uncharted jungle of more than 70,000 projects. At http://freshmeat.net/ more than 30,000 projects are listed. Finding the right open source for your needs and evaluating its maturity can be exhausting and time consuming. Most open source projects are useless to organizations and businesses focused on solving problems, but a small number are incredibly valuable.
Also available are more organized and higher-quality sources of open source software, such as the Apache Software Foundation and Tigris.org (supported by CollabNet). Although these sources offer a significantly smaller set of open source applications, they are relatively mature, stable, and useful.
And don’t be fooled into thinking that using open source requires you to master Linux. Plenty of open source programs work perfectly well on the Microsoft platform, including Apache, MySQL, and Perl.
Once you find an open source program that might fit your needs, a host of questions arise: how do you know how stable it is? How can you find out if someone will be around to help if you have a problem? How can you find others who are using it? None of these questions has a simple answer.
The bottom line is that if you set out to use open source, you must learn to evaluate the software’s maturity and the level of support provided by the community that surrounds the project so that you can understand the risks. That is what the Open Source Maturity model is all about.