Section 2.3. The Open Source Maturity Model

2.3. The Open Source Maturity Model

The Open Source Maturity model attempts to quantify the maturity of an open source product. This should help an enterprise decide whether to adopt the product for long-term use.

This model assumes the following:

• A functional specification of requirements exists

• A functional specification has been matched to a product functionality list, and a short list of products that match has been created

The IT department uses the results of these two steps to determine which product from the short list is suitable for adoption. It should be noted that this evaluation process might be too resource intensive for the short-term use of an open source product but is a very wise investment for medium to long-term use.

We assess maturity in three major areas:

Product criteria

Product criteria are specifics about the product itself. Since open source software (OSS) products are often under rapid development, with major advances made in a few weeks to a few months, we list momentum as a criterion to offset the age criterion. This helps us spot products that aren't mature enough today but are worthy of keeping an eye on.

Use criteria

Use criteria are specifics about what it takes to use the product from day to day, from the effort of initial installation and configuration to the work required for daily upkeep and support mechanisms available to help in tailoring the product to an enterprise's needs and fixing defects encountered.

Integration criteria

Integration criteria are specifics about what it takes to make the product work in the enterprise's environment. This is often overlooked during evaluations and is a critical factor to consider if you want to win with open source in the enterprise.

For each criterion we assign a score of 1, 2, or 3:

1 (Immature)

The product is lacking in several critical areas. It would be dangerous for an enterprise to use it in a business-critical function. Some projects remain in this state until the first major release.

2 (Reasonably mature)

The product has a sufficiently long history of stable deployments, a loyal user base, and a bright future. For example, while MySQL is lacking many features for certain types of high-performance enterprise use, most everyone agrees that it is well on its way to being a mature open source product fit for most requirements.

3 (Very mature)

The product has a long and stable history, a broad and vibrant user community, etc. Apache Web Server is a good example of a level 3 open source program.

While useful, this numerical categorization should not be used as a categorical measure. You can ignore the difference of a single point in scoring. We provide the scoring as a suggestion, mostly for convenience and as a way to organize the analysis and comparison of many open source projects. Table 2-1 shows the Open Source Maturity model.

Table 2-1. The Open Source Maturity model

Maturity criteria	Score = 1	Score = 2	Score = 3	Criteria description
Product criteria
Age	< 6 months	6 months- 2 years	> 2 years	OSS efforts that are just getting underway are risky for enterprises.
Multiple supported platforms	One platform	Many related platforms	Multiple heterogeneous platforms	Products that work on both Windows and Unix are more desirable.
Momentum	No release in last 6 months	< two releases in past year	Regular releases	This is key to helping separate vital products from ones that are withering.
Popularity	Unknown product	Viable alternative	Category leader	Popular OSS products are well tested and therefore more mature. They are also likely to be interoperable with a large number of other products.
Design quality	Monolithic application	Multiple components	Well-defined API	This criterion is key in determining the effort required to extend and adapt the product for enterprise use.
Use criteria
Setup cost	Poorly documented install process; poor documentation; help available from developers	Well- documented install process; reasonable documentation; help available from developers; help available in support forums	Well- documented install process; install wizards/scripts available; reasonable documentation; help available from developers; help available in support forums; third-party install services	Most products should require a setup effort of hours or days, not weeks or months.
Usage cost	Poor or nonexistent documentation; help available only through direct contact with developers	User manuals available; help available in support forums	Third-party training services available	This criterion is often overlooked when evaluating a product.
End-user support	No forums or mailing lists	Some forums or mailing lists	Well-run forums and mailing lists, with archives and search; third-party support options	User community (forums, mailing lists) and third-party support are vital to a product's success.
Integration criteria
Modularity	Monolithic structure; possible but hard to extend	Multiple modules; possible to extend	Multiple modules, well-defined API; possible and easy to extend
Collaboration with other products	Unknown	Known cases of integration	Lots of integration documented
Standards compliance	Unknown or proprietary	Outdated	Current industry standards
Developer support	No forums or mailing lists	Some forums or mailing lists	Well-run forums and mailing lists with archives and search; third-party support options

Armed with the information in this chapter, most IT departments will be able to do a first-rate job of evaluating open source projects. The next most important factor is whether an IT department properly understands its skills, which is the subject of the next chapter.