I recently had a chance to use some of the early work I did for OpenBRR. This time though, I am on the other side of the fence. I now have to evaluate our own Open Source software. In preparation, I re-read the whitepaper to refresh my memory and found this gem in the Appendix.
The Characteristics of Mature Open Source Software
1. Separation of development and stable branch.
2. The software is backed by a foundation, a corporation, or a strong
community.
3. The community is organized into groups, each responsible for separate tasks
(the maintainer, the documentation group, the development group, the
evangelism group).
4. Project extensions are available.
5. The project has existed at least 1 year.
6. There is a well-defined process to enter the core development team.
7. The project’s license is acknowledged by the Open Source Initiative
(http://opensource.org).
8. Separation of documentations: User documentation, Installation
documentation, Admin documentation, and, crucially, development
documentation.
9. User documentation is extensive, available in many formats.
10. Separation of mailing lists: user mailing list, developer mailing list, security
mailing list, evangelism mailing list, etc.
11. Not very aggressive in doing minor or major releases. Quick point releases
are fine. (For Major.Minor.Point release numbering system.)
12. Books are readily available.
13. Large-scale adoption and usage of the software exists by organizations and/or
individuals.
14. The software component has reasonable native unit and functional tests and
the code coverage for these tests should be reasonable (30-80% range).
15. The component needs to be well integratable with other containing/contained
components.
16. The component’s bug database should indicate the revision numbers, unified
diffs to each bug that is fixed.
17. The software is easy to install. It has well-documented installation
instructions.
18. The software has a clean user interface. (GUI or command-line)
19. Performance metrics are available.
20. A deployment guide is available.
21. Well-known large-scale deployments (e.g. Wikipedia for mediawiki).
22. Intuitive to use and no convoluted designs (e.g., MoinMoin vs. Tikiwiki).
23. Ported across multiple platforms (Linux, Windows, Solaris, and Mac).
24. Non-intrusive, for example a small runtime footprint.
25. Separation of delivery of security patches, bug fixes, and new
features/enhancements.
In case you are still wondering, OpenBRR is an evaluation framework, which gives a business the ability to evaluate a Free and Open Source Software component and derive a Business Readiness Rating (BRR) ranging from 1 (un-acceptable) to 5 (ideal for adoption). The evaluation is done using the above list as a foundation on a spreadsheet (which is pretty much the framework)
The whitepaper and some community contributed sample evaluations can be downloaded from the OpenBRR site.
The Characteristics of Mature Open Source Software
1. Separation of development and stable branch.
2. The software is backed by a foundation, a corporation, or a strong
community.
3. The community is organized into groups, each responsible for separate tasks
(the maintainer, the documentation group, the development group, the
evangelism group).
4. Project extensions are available.
5. The project has existed at least 1 year.
6. There is a well-defined process to enter the core development team.
7. The project’s license is acknowledged by the Open Source Initiative
(http://opensource.org).
8. Separation of documentations: User documentation, Installation
documentation, Admin documentation, and, crucially, development
documentation.
9. User documentation is extensive, available in many formats.
10. Separation of mailing lists: user mailing list, developer mailing list, security
mailing list, evangelism mailing list, etc.
11. Not very aggressive in doing minor or major releases. Quick point releases
are fine. (For Major.Minor.Point release numbering system.)
12. Books are readily available.
13. Large-scale adoption and usage of the software exists by organizations and/or
individuals.
14. The software component has reasonable native unit and functional tests and
the code coverage for these tests should be reasonable (30-80% range).
15. The component needs to be well integratable with other containing/contained
components.
16. The component’s bug database should indicate the revision numbers, unified
diffs to each bug that is fixed.
17. The software is easy to install. It has well-documented installation
instructions.
18. The software has a clean user interface. (GUI or command-line)
19. Performance metrics are available.
20. A deployment guide is available.
21. Well-known large-scale deployments (e.g. Wikipedia for mediawiki).
22. Intuitive to use and no convoluted designs (e.g., MoinMoin vs. Tikiwiki).
23. Ported across multiple platforms (Linux, Windows, Solaris, and Mac).
24. Non-intrusive, for example a small runtime footprint.
25. Separation of delivery of security patches, bug fixes, and new
features/enhancements.
In case you are still wondering, OpenBRR is an evaluation framework, which gives a business the ability to evaluate a Free and Open Source Software component and derive a Business Readiness Rating (BRR) ranging from 1 (un-acceptable) to 5 (ideal for adoption). The evaluation is done using the above list as a foundation on a spreadsheet (which is pretty much the framework)
The whitepaper and some community contributed sample evaluations can be downloaded from the OpenBRR site.
