Business Readiness Rating : un modèle pour l'évaluation des logiciels Open Source

Un constat : le choix d'un logiciel open source est complexe et est trop souvent la résultante d'une évaluation "ad hoc"

Le fondement de l'initiative lancée par Open BRR est fondé sur un constat : malgré les qualités des logiciels open source (coût potentiellement moindres, transparence et ouverture du code, utilisation de standards ouverts) un certain nombre de facteurs freinent leur adoption par les entreprises :

• la sélection d'une solution : pour certaines catégories de logiciels (notamment les CMS), le choix est extrêmement étendu (rappelons qu'au total, il y a plus de 135 000 projets référencés sur SourceForge).
• le support : le support technique est souvent limité à un support communautaire, gratuit mais sans engagement contractuel comme pourrait l'être un support payant
• la longévité : la continuité d'un projet dépend du bon fonctionnement de la communauté qui le soutien, ce qui est souvent difficile à évaluer.
• la volatilité : les équipes de développement sont souvent entraînées dans un cycle de développement rapide pour satisfaire la demande des communautés en terme de nouvelles versions. La plupart des entreprises hésitent à s'engager vis à vis d'une solution de peur de se retrouver dans une situation de mise à jour perpétuelle.

La création d'un modèle d'évaluation répond donc à un besoin, celui d'un cadre d'évaluation structuré permettant de faciliter et rationnaliser le choix. Comme le souligne les initiateurs d'Open BRR, la plupart des évaluations sont actuellement conduite "ad hoc", sans méthodologie et par conséquent risquées.

Principe fondateurs du modèle Open BRR

Le modèle d'open BRR se défini comme :

• exhaustif : le modèle doit prendre en compte toutes les caractéristique du produit, qu'elles soient favorables ou non, de manière à éviter les biais.
• simple : l'adoption d'un modèle, et son utilité, sont largement fondées sur sa simplicité. Le modèle doit être compréhensible et orienté utilisateur sans sacrifier l'exhaustivité.
• adaptable : du fait des changements rapides dans l'industrie du logiciel, il est impossible de garantir sa pertinence future. Il est toutefois possible de laisser le modèle aussi ouvert et générique que possible pour permettre une évolution dans le temps.
• cohérent : les échelles de mesure doivent être cohérentes quelque soit le type de logiciel.

Une première évaluation rapide

Côté méthodologique, le modèle suggère une première phase d'élimination, via un ensemble de question :

• Quelle est la licence du logiciel ?
• Le logiciel est-il conforme aux standards ouverts ?
• Quels sont les organisations qui l'utilisent ?
• Une ou plusieurs entreprises soutiennent-elles les efforts de développement ?
• Quelles sont les langues proposées et aussi le logiciel est-il localisé et internationnalisé ?
• Existe t-il des test du logiciel par des tierces parties ?
• Des livres ont-ils été publié sur le logiciel ?

(...)

Une évaluation en 12 points

Le modèle défini 12 catégories à évaluer :

• Fonctionnalités : le logiciel satisfait-il les besoins principaux des utilisateurs ?
• Utilisabilité : Que donne l'interface ? Quelle est la facilité d'utilisation ?
• Qualité: Existe t-il une équipe de testeurs ? Quelle est la qualité du code (respect des bonnes pratiques) ? L'application génère t-elle des erreurs ?
• Securité : Quelle est la sécurité de l'application ? Combien d'alertes et quelle est la rapidité des réponses (patch) ?
• Performance : Quel est la performance du logiciel ?
• Scalabilité : Comment le logiciel répond t-il à la montée en charge / un déploiement à large échelle ?
• Architecture : Quelle est l'architecture du logiciel ? Est-il modulaire, flexible, extensible, ouvert et facile à intégrer à d'autres applications ?
• Support : Le logiciel et ses composants font-ils l'objet d'un support technique ? Si oui, quelle est sa qualité (garanties, délais de réponse) ?
• Documentation : Quelle est la qualité de la documentation ?
• Adoption : Quelle est la diffusion du logiciel sur le marché ? Communauté, marché, industriels ?
• Community : Quel est le degré d'activité de la communauté ?
• Professionalisme : Le développement du logiciel est-il professionnel et organisé ?