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 lacking—if 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 quality—it 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 ...