From OpenBRR

Introduction

This page is intended to support participants in the OpenBRR community as we explore ways to expand the BRR model to include proprietary software as well as OSS. The following approach has been suggested:

1. Revisit the selection of assessment categories that we originally chose. Consider what they meant for both open and proprietary solutions.

2. Based on our the result of 1, we would adjust the metrics to measure both open and proprietary solutions fairly. This may mean using different metrics in the same category. For example, Support for OSS can be measured by looking at the quality of online documentation, responsiveness of the community, etc. Support for proprietary solutions can be measured by how responsive the support group of the software vendor. However, we should strive to use the same metrics whenever possible. Obviously this would be possible for Functionality and Usability.

3. Develop some guidelines for institutions to set Functional Orientation Weights depending on their needs.

Assessment Category

Listed below are the assessment categories identified in the BRR white paper followed by a brief description. In accordance with the processes outlined above, as part of step 1, we can document considerations for applying the categories to proprietary as well as OSS.

• Functionality: How well will the software meet the average user’s requirements?

• Usability: How good is the UI? How easy to use is the software for end-users? How easy is the software to install, configure, deploy, and maintain?

• Quality: Of what quality are the design, the code, and the tests? How complete and error-free are they?

• Security: How well does the software handle security issues? How secure is it?

• Performance:How well does the software perform?

• Scalability: How well does the software scale to a large environment?

• Architecture: How well is the software architected? How modular, portable, flexible, extensible, open, and easy to integrate is it?

• Support: How well is the software component supported?

• Documentation: Of what quality is any documentation for the software?

• Adoption: How well is the component adopted by community, market, and industry?

• Community: How active and lively is the community for the software?

• Professionalism: What is the level of the professionalism of the development process and of the project organization as a whole?