Chapter 2. Measuring the Maturity of Open Source

The difference between evaluating open source and commercial software is that in open source it is all up to you. Nobody teaches you how the product works. No experts call to explain everything. No whitepapers provide summaries of features and functionality. Nobody buys you lunch. You have to spend time gathering information and understanding the software. In other words, evaluating open source thoroughly enough to reduce risk is real work.

This chapter is a guide to doing that work.

Measuring the maturity of any software, commercial or open source, is far more an art than a science. This chapter will focus on the specific elements of an open source project, and those elements will serve as a guide to determining its maturity. Maturity, for the purposes of this chapter, is an indicator not only of age, but also of various dimensions of quality. It is also a proxy for the question, How much work is really required to use this software?

If some of the key elements of maturity are lackingif information is difficult to find, if code is poorly structured and difficult to read, if forums are inactive and documentation is scant, if the project in general is of low qualityit translates into more work for those who would use the software. Problems will be hard to address. Help will be hard to find. Customization and configuration will be difficult. If the elements of maturity are present, the software will be much easier to use.

As the last chapter illustrated, most software, commercial or otherwise, exists in the gray area between mature and ill-formed. Almost every potentially valuable program also comes with significant drawbacks. The key to the successful deployment of software of any kind is to understand how the software will provide value and how you will avoid or compensate for the drawbacks inherent in using the software. The larger picture of whether a particular open source project will work for a particular purpose goes beyond issues of maturity, of course. Determining how the software will be used, who will be using it, and what it will fully cost are important factors that must be taken into account.

The purpose of this chapter, and the two that follow, is to lay out a comprehensive program to help you avoid the most common mistakes IT departments make when they decide to use open source software.

This chapter begins with a look at the traps an IT department can fall into if it does not take a comprehensive approach to evaluating open source, followed by a discussion of the elements of an open source project that determine maturity. The chapter ends with the formulation of an Open Source Maturity model that will be used later in the book to evaluate the open source projects in the chapters on specific areas of interest to IT departments.