Grâce à un coût de licence nul, les logiciels libres semblent une bonne alternative pour réduire les dépenses en ces moments de crise. Leur acquisition ne va pas néanmoins sans risque. Comme dans tout écosystème, le monde du libre contient de bonnes et de moins bonnes initiatives. Il est donc important de savoir comment évaluer les risques liés à l’acquisition d’un logiciel libre afin d’éviter les pièges.
QualOSS, un projet de recherche Européen mené par le CETIC, développe une approche pour évaluer systématiquement les risques liés à l’acquisition de logiciels libres. En voici un aperçu.
Avec un coût de licence nul, les logiciels « open source » ou logiciels libres [pied de page : cet article ne rentre pas dans la distinction entre les logiciels libres et les logiciels open source qui n’a qu’une signification philosophique. En revanche d’un point de vue pragmatique, les logiciels libres et « open source » peuvent être considérés comme similaires.] semblent offrir une alternative intéressante pour les entreprises désireuses de diminuer les frais consacrés actuellement aux licences de logiciels propriétaires. Il est certain qu’à lui seul, le coût de licence ne doit pas déterminer une décision de migration vers l’open source. En effet, le budget global d’un logiciel inclut aussi les coûts de mise et de maintien en opération sans oublier les frais de formation (inclus le temps consacré à l’autoformation). De plus, l’acquisition d’un logiciel open source ne va pas sans risque car comme dans tout écosystème, il existe de bons et de moins bons éléments parmi l’ensemble des initiatives de développement de logiciels libres.
Afin de prendre une décision informée, une entreprise se doit de bien analyser la situation. Au delà de l’aspect économique, une étude d’incidence doit aussi permettre à une entreprise d’évaluer la confiance à accorder à une initiative de développement libre et au logiciel libre résultant. Établir cette confiance seulement sur base de l’analyse du composant logiciel ne serait pas suffisant. Comme pour les logiciels propriétaires, une acquisition se décide non seulement sur le produit logiciel lui-même mais aussi sur la confiance attribuée à l’éditeur qui produit ce logiciel. Dans le monde des logiciels propriétaires, les méthodes généralement utilisées pour déterminer la confiance se basent sur la solidité financière de l’éditeur. Malheureusement, une telle analyse a beaucoup moins de sens dans le monde des logiciels libres. En revanche, et contrairement aux entreprises traditionnelles, une initiative de développement libre partage toute une série d’informations incluant le code source mais aussi les échanges passés entre les divers contributeurs lors du développement et du support du logiciel libre en question. Il est fréquent de trouver des discussions entre développeurs et utilisateurs dans des fora, des archives de mailing listes ou autres bugtrackers. L’accès au gestionnaire de versions utilisé durant l’initiative de développement libre permet aussi de retracer l’évolution exacte des changements dans le code source et d’identifier qui a effectué ces changements.
Afin de déterminer la confiance qu’une initiative de développement libre mérite, une évaluation holistique étudiera :
Quand une initiative de développement libre a bien enregistré et conservé les données générées durant le développement, les résultats d’une évaluation devraient même être considérés comme bien plus convaincants qu’un rapport financier fourni par un éditeur de logiciels propriétaires.
La confiance accordée à une initiative de développement libre sera fortement influencée par la capacité que l’initiative de développement libre à résoudre les problèmes dans le court terme (robustesse) ainsi que la capacité qu’elle a à évoluer dans le moyen et le long terme (évolutivité). Il est donc possible de déterminer la confiance méritée en évaluant le degré de robustesse et d’évolutivité d’une initiative de développement libre. L’illustration 1 énumère les caractéristiques importantes des 4 éléments d’une initiative de développement libre qui permettront d’évaluer les risques liés à la robustesse et l’évolutivité d’une initiative de développement libre.
Évaluer ces 4 éléments prend toute son ampleur quand le logiciel libre en question aura un impact significatif sur l’entreprise qui pense l’acquérir ; l’impact pouvant toujours se ramener à la conséquence financière de prendre la mauvaise décision d’acquisition qui entraînerait une perte de temps, de coût de formation, et de migration vers une autre solution.
Il existe maints scénarii d’acquisition de logiciel et chacun n’accordera pas la même importance aux 4 éléments d’une initiative de développement libre. Donc, avant même d’élaborer une méthode qui permettra de les évaluer, il est important d’étudier les divers scénarii d’acquisition de logiciel libre fréquemment rencontrés en entreprise. Ensuite, pour chaque scénario, l’importance de chacun des 4 éléments sera déterminée.
Scénario 1 d’Exploitation Simple. Une entreprise veut déployer un logiciel libre sur l’ordinateur de ses employés et leur payer des formations pour bien maîtriser le logiciel.
Scénario 2 de Fourche. Une entreprise veut intégrer un logiciel dans un des ces produits mais ne collaborera pas avec l’initiative qui l’a développé, elle choisira de créer une fourche en lançant sa propre initiative de développement interne.
Scénario 3 de Reprise d’une Initiative. Une entreprise veut prendre le contrôle d’une initiative de développement libre existante afin de diriger l’évolution du logiciel libre et de s’assurer qu’il est et restera rapidement intégrable à ses produits.
Scénario 4 de Collaboration Complète. Une entreprise veut intégrer un logiciel dans un des ses produits tout en gardant la ligne de collaboration ouverte avec l’initiative de développement libre.
Lors d’une évaluation, il suffira de pondérer chaque élément en rapport à son importance pour finalement prendre une décision réfléchie.
L’évaluation de chaque caractéristique suit la trame présentée dans l’exemple ci-dessous qui se concentre sur l’évaluation de la taille et la régénération de la communauté (Size and Regeneration Adequacy).
Premièrement, afin de s’assurer que l’évaluation répond aux questions concrètes d’une entreprise, nous identifions les rôles d’entreprise impliqués dans l’acquisition d’un logiciel et ensuite nous élaborons des questions auxquelles ces rôles veulent des réponses. Les rôles sont le Chef de Produit (Product Manager) qui a une vue à long terme, le Chef de Projet (Project Manager) ainsi que des rôles plus techniques comme l’Analyste, le Développeur, le Testeur et le Rédacteur de documentation qui ont tous deux une vue à plus court terme concentrée sur le projet d’intégration qui utilisera le composant libre sélectionné. Les questions ci-dessous connectées à la taille et la régénération de la communauté seront souvent soulevées par le Product Manager :
Les réponses aux questions ci-dessus peuvent se faire sur base de mesures objectives. Pour la première question par exemple, l’évolution du nombre de nouvelles personnes rapportant des bugs s’effectue en analysant l’information trouvée dans un bugtracker. Il suffit d’étudier par exemple par période de 3 mois, le nombre de personnes qui rapportent un bug (ou participent à la discussion d’un bug rapporté) pour la première fois.
Diverses mesures du même genre répondront aux autres questions. Ensuite les mesures pourront être agrégées en un ou plusieurs indicateurs afin de quantifier le risque lié à une caractéristique, en l’occurrence la taille et la régénération de la communauté. Pour faciliter l’interprétation, les valeurs d’un indicateur doivent rester simple. Par exemple, un indicateur aura un score entre 1 et 4 où 1 indique un risque très élevé (noir), 2 indique un risque important (rouge), 3 signifie un risque modéré (orange) et 4 indique un risque quasi nul (vert).
Ci dessous sont présentés deux indicateurs utiles au Product Manager pour évaluer le risque lié à la taille et la capacité de régénération de la communauté.
Indicateur 1 : Risque lié à la taille de la communauté globale
NOIR : Si les nombres de nouvelles personnes rapportant de bugs, contribuant du code ou autre données pour la première fois ont tous trois tendance à diminuer sur la dernière année et que la somme de ces nouvelles personnes pour le semestre actuel est plus petite que 5.
ROUGE : Si pas NOIR et si le nombre de nouvelles personnes rapportant des bugs, contribuant du code ou autre données pour la première fois ont tous trois tendance à diminuer ou rester stable sur la dernière année et que la somme de ces nouvelles personnes pour le semestre actuel est plus petite que 5.
ORANGE : Si pas ROUGE et si le nombre de nouvelles personnes rapportant des bugs, contribuant du code ou autre données pour la première fois ont tous trois tendance à rester stable sur la dernière année et que la somme de ces nouvelles personnes pour le semestre actuel est plus petite que 10.
VERT : Si pas ORANGE.
Indicateur 2 : Risque lié à l’implication ou non de personnes fortement actives
NOIR : Si l’évolution du nombre de nouvelles personnes très actives dans la communauté à tendance à diminuer sur l’année passée et que le nombre de personne anciennement actives (qui n’ont plus contribué depuis plus d’un an, par exemple) n’a pas tendance à diminuer et que le nombre de nouvelles personnes est plus petit que celui d’anciennes personnes sur l’année passée.
ROUGE : Si pas NOIR et si l’évolution du nombre de nouvelles personnes très actives dans la communauté à tendance à diminuer sur l’année passée et que le nombre de personne anciennement actives (qui n’ont plus contribué depuis plus d’un an, par exemple) n’a pas tendance à diminuer et que le nombre de nouvelles personnes est plus grand que celui d’anciennes personnes sur l’année passée.
ORANGE : Si pas ROUGE et si l’évolution du nombre de nouvelles personnes très actives dans la communauté à tendance à ne pas diminuer sur l’année passée et que le nombre de personne anciennement actives (qui n’ont plus contribué depuis plus d’un an, par exemple) n’a pas tendance à augmenter et que le nombre de nouvelles personnes est plus petit que celui d’ancienne personnes sur l’année passée.
VERT : Si pas ORANGE.
Le Product Manager pourra alors décider du poids à donner à ces deux indicateurs en rapport au contexte exact de l’acquisition du logiciel libre en question. Par exemple, pour un logiciel libre complexe où il faut du temps pour devenir un contributeur très actif, le second indicateur sera sûrement considéré comme plus important que le premier indicateur.
L’agrégation peut continuer à remonter le long de l’arbre. Au niveau supérieur, il faudra décider du poids à attribuer à l’évaluation de la taille et de la régénération de la communauté en rapport aux autres caractéristiques de la communauté et finalement, aussi le poids à l’évaluation de la communauté en rapport aux trois autres éléments d’une initiative de développement libre. Comme le Tableau 1 le montre ces poids se décideront en fonction du contexte d’acquisition.
Dans les prochains numéros de la newsletter, des scénarios précis d’acquisition de logiciels libres seront décrits suivi de l’évaluation des initiatives de développement de ces logiciels libres.