OSMM, le modèle de maturité des projets open-source

Open-Source Maturity Model

OSMM, ou comment évaluer la maturité d’un projet open source Par Christophe Addinquy Je ne vous ferai pas l’insulte de vous asséner l’importance et la crédibilité qu’ont acquis les projets open source dans l’industrie logicielle au cours des dernières années ! Oui, mais voilà :  De quels projets open source parlons-nous ?  De quelle industrie, de quel projet ou de quelle organisation parlons-nous ?

La variété des projets s’étend des réalisations d’avant-garde hautement innovantes, aux applications historiques s’appuyant sur des technologies vieilles de plusieurs décades.

Nous avons maintenant l’habitude (plus ou moins) d’évaluer techniquement des projets open source : adéquation au besoin, performances, qualité du code et technologies ou standards sous-jacents. Cela n’est pas suffisant. Il faut également se préoccuper du niveau d’aboutissement de ces projets, de leur utilisation dans des projets industriels ou encore du niveau d’activité qui entoure ceux-ci. De même, l’exigence de maturité ne sera pas le même que le projet soit un développement de recherche ou que le projet concerne une application de gestion classique, mais dont l’exigence de sûreté opérationnelle est élevée.

Typologie des projets et aversion à l’immaturité La désormais célèbre courbe de Moore1 nous donne une indication concrète sur l’aversion des projets ou des organisation au risque. Les même cinq zones de cette courbe définissent des besoins croissants en maturité des projets open source. Dit comme ça, ça parait compliqué, mais relisez la phrase précédente et vous verrez que c’est évident.

1

Moore nous parle également de l’impact de l’open source sur son modèle : http://itconversations.com/shows/detail494.html ; 1

Open-Source Maturity Model

Mais comment, justement, mesurer la maturité de ces projets ? Eh bien, grâce au

Modèle de maturité OSMM En résumé, le modèle OSMM consiste à renseigner pour un projet donné, la matrice suivante : Phase 1 : assesment

Phase 2

Phase 3

Define

Locate

Assess

Assign

Assign

Calculate

requirements

Resources

Element

Element

Weighting

Product Maturity

Maturity

Score

fator

Score

Product Software Support Documenta tion Training Product Integration Professional Services Dans la première phase, on collecte les informations et l’on note le projet, thème par thème. C’est évidemment la phase la plus longue. Les thèmes sont : 2

Open-Source Maturity Model  Le produit : on évalue ses fonctionnalité, sa longévité, la qualité globale et la qualité de l’équipe de développement (pour autant qu’on puisse en juger).  Le support : celui-ci peut être communautaire, payant ou « maison » si l’on a un expert de système dans ses équipes.  Documentation : on juge ici de la documentation de développement, mais aussi des articles postés par des tiers ainsi que de la documentation commerciale.  Formation : Cette rubrique permet d’estimer l’existence et la pertinence de tutoriaux en ligne ou commerciaux et des formations dispensés par l’équipe de développement ou des organismes professionnels tiers.  Intégration : On juge ici des intégrations déjà réalisées et documentées, des intégrations possibles via des développements maison, ainsi que des intégration proposées commercialement.  Services professionnels : On évalue services de développement et de consulting proposés par l’équipe de développement, par d’autres sociétés de conseil ou par des groupes internationaux.

Pour chaque thème, on établit :  Les exigences, c’est à dire les sous rubriques de chaque thème (avec un poids associé). Heureusement, OSMM propose déjà une trame de base.  La localisation des ressources associées, c'est-à-dire la référence des produits, documentation et services trouvés.  Le niveau de maturité maximal potentiel. En pratique, c’est toujours 10.  Le niveau de maturité atteint par le projet, qui est la note finale pour chaque thème.

En phase 2, on adapte la matrice de résultat aux besoins contextuel du projet : si le volet intégration est important, on appliquera un fort facteur sur ce thème, si la maintenance est essentielle, on privilégiera le support. La somme des facteurs de poids doit être de 10 (ce qui ramène la note initiale sur 60 à une note sur 100). Dissocier l’application des poids de la phase 1, permet évidemment de réutiliser une évaluation à des contextes projet différent, sans repasser par l’étape de rassemblement d’informations.

En phase 3, on calcule la note, et l’on ramène celle-ci dans un abaque d’évaluation de la maturité par rapport au type d’usage. Voici un exemple possible d’abaque : Purpose

Type of user

3

Open-Source Maturity Model Of use Early adopter

Early majority

Experimentation 25

40

Pilot 40

60

Production 60

70

OSMM, malgré un nom ambitieux est un modèle uniquement promu par une société, Navica2. Ce modèle reste très simple, gage d’une bonne applicabilité. Le corollaire est toutefois que la notation dépend essentiellement du savoir-faire de l’organisation attribuant les notes, il faudra donc un bon étalonnage, passant par un certain nombre d’évaluation, pour obtenir une certaine stabilité. Mais cette approche permet de couvrir un aspect de l’évaluation des projets open source encore dédaigné, mais dont l’importance augmentera avec l’institutionnalisation de l’intégration de l’open source dans les systèmes d’entreprise.

Ah ! Une dernière chose. Vous commencez peut-être à vous douter qu’il y a un bouquin qui traite du sujet ? C’est bien le cas3.

2

http://www.navicasoft.com/pages/osmmoverview.htm ;

3

http://www.amazon.com/exec/obidos/ASIN/0321268539/qid=1119041069 /sr=2-1/ref=pd_bbs_b_2_1/104-4725035-4986321 ; 4