Rules for Selecting Open Source

I came across this article and it seemed to me that these are great guidelines for selection of open source (and perhaps commercial) software frameworks and packages. I adapted these a bit to fit more of what I think is important:

• Project Requirements: should drive the evaluation/selection. The amount of functionality provided out of the box and of experience needed to support the framework/solution should be considered as well.
• License Requirements: Always check the license to make sure you can live up to it!
• Platform Support: Although most frameworks support common platforms (Java/.NET/browsers), “…there are often some exceptions in the fine print” – test these on your most critical platforms.
• Strength of Development Team supporting the framework/project. The best frameworks/projects are maintained by a core team of developers. This will result in faster response time to bug reports and questions as well as in more rigor in testing and adherence to guidelines. Find out how these developers really make their money…open-source is cool, but everyone has to eat.
• Maturity of the framework: More than anything, the maturity of a framework demonstrates a commitment to longevity, as well as a solid foundation. A mature framework will no longer be in beta… A thriving community and support for a Subversion and CVS version repository, formalized issue tracking system, formal SLC process for revisions, features, releases, etc. are other signs of maturity
• Frequency of Public Updates and Releases: Long delays and bloated releases are also a sure sign that you will not enjoy supporting the framework/project on future solutions. Alternatively, too many public releases could indicate instability, or a lack of focus. Releases should be followed quickly by patches.
• Documentation quality: Documentation is an important differentiator; strong documentation includes the API, books, tutorials and blogs while “the worst documentation is the sort that is only focused on syntax”. Documentation should be consistent across the core software and extensions. Is there training and are there advocacy events publicy planned?
• Existence of an Active Community: “Are experienced users willing and able to lend a helping hand, or will they send you elsewhere for assistance? Are developers creating extensions, or contributing to the core framework?” The community character can also be a predictor of future reliability on community help. Is the community formalized? Do they have an LLC or a “corporation” formed that formally owns the technology? Do they elect officers? Do they have annual meetings? Sprint events?
• Extensibility of the Framework/Project: The extensibility of the architecture over time and the resilience of extensions during platform upgrades is a key indicator of design strength and maturity. Is there a well defined method for building addins to the project? Is there a well defined process for contributing to the project?
• API Style: This is an important, but complicated question that is answered for most developers only after using several frameworks on numerous projects. Terseness, as well as chainability, are two very important features that should not be overlooked. Stability and consistency across packages and objects is critical. Also – a formalized deprecation process is a key indicator of thinking about change before it happens.