OpenBRR: Methodology


Course: Dynamics of libre software communities

               Israel Herraiz
             <herraiz...
Outline
    OpenBRR already presented as part of the
●


    Introduction course
    Part of the Dynamics course is assesm...
Summary of OpenBRR
   This Business Readiness Rating model is
  intended to help IT managers assess which
open source soft...
Master on Free Software
Metrics
    Some of them can be automatically
●


    gathered
    Some other not
●



    Guidelines for scoring in the w...
Mature communities
1. Separation of development and stable branch.
2. The software is backed by a foundation, a corporatio...
Mature communities
5. The project has existed at least 1 year.
6. There is a well-defined process to enter the core
  deve...
Mature communities
9. User documentation is extensive, available in many
  formats.
10. Separation of mailing lists: user ...
Mature communities
14. The software component has reasonable native unit
  and functional tests and
   the code coverage f...
Mature communities
19. Performance metrics are available.
20. A deployment guide is available.
21. Well-known large-scale ...
Upcoming SlideShare
Loading in …5
×

Openbrr Methodology

2,117 views

Published on

Published in: Economy & Finance, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,117
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
30
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Openbrr Methodology

  1. 1. OpenBRR: Methodology Course: Dynamics of libre software communities Israel Herraiz <herraiz@gsyc.es> th A Coruña, November 30 2007 Master on Free Software
  2. 2. Outline OpenBRR already presented as part of the ● Introduction course Part of the Dynamics course is assesment ● of free software projects “Low-level” usage of the OpenBRR ● methodology to already studied case studies Evolution, Sylpheed and Balsa – Master on Free Software
  3. 3. Summary of OpenBRR This Business Readiness Rating model is intended to help IT managers assess which open source software would be most suitable for their needs. Open source users can also share their evaluation ratings with potential adopters, continuing the virtuous cycle and “architecture of participation” of open source. Master on Free Software
  4. 4. Master on Free Software
  5. 5. Metrics Some of them can be automatically ● gathered Some other not ● Guidelines for scoring in the white paper ● Master on Free Software
  6. 6. Mature communities 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. Master on Free Software
  7. 7. Mature communities 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. Master on Free Software
  8. 8. Mature communities 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. Master on Free Software
  9. 9. Mature communities 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) Master on Free Software
  10. 10. Mature communities 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. Master on Free Software

×