Introduction

L’Argus du libre est un guide de choix créé comme une photographie à un instant « t » des principales solutions libres. Il représente l’état de l’art, selon des critères que nous exposons plus loin, de ces logiciels.

L’historique des mises à jour permettra également de constituer un observatoire dans le temps de ces projets.

Les critères d’évaluation ont été choisis pour permettre d’assurer :

• Les calculs de ROI (retour sur investissement)

• Les coûts d’entrées, mais également de sortie,

• Les offres commerciales existantes,

• Les diverses difficultés relatives que peut rencontrer un projet,

Ils permettent, en particulier, d’anticiper les coûts de maintenance et de support.

Outre le recensement des caractéristiques techniques, c’est une évaluation destinée aux DSI qui leur permet de disposer des clés de compréhension pour réaliser leur choix d’industrialisation. Il vise également à offrir un descriptif éclairé, afin d’assister les autres acteurs du projet lors de la phase de choix de la solution.

Décliné en une édition papier qui résume les principales informations, le référentiel est également disponible par le biais du site Web http://www.argus-du-libre.com. Celui-ci propose :

• Des critères quantitatifs, issus d’observations et de mesures effectuées périodiquement,

• Des critères qualitatifs déterminés au travers d’une méthodologie d’évaluation et du retour d’expérience des consultants de Linagora qui travaillent au quotidien avec ces projets.

L’Argus du libre ne se veut pas :

• Une mesure unilatérale des projets,

• Un guide contenant des critères basés sur le sentiment partial du rédacteur,

• Un catalogue commercial d’offres sur étagères sponsorisées par un acteur du marché.

 

Licence

L’Argus du libre est publié sous licence GFDL. Le site est mis à jour en permanence par les consultants et experts de Linagora. Le guide est, quant à lui, mis à jour de façon hebdomadaire et automatisée.

Méthodologie de constitution

L’Argus est constitué :

Dans un premier temps par des acteurs de Linagora, et à terme par tous les membres de l’ASSLL pour former un référentiel des solutions préconisées par ces acteurs,

Par l’évaluation impartiale des porteurs d’offres de Linagora dans chacun des domaines concernés,

Par la validation, par un collège d’architectes et d’experts qui tranche parmi les logiciels proposés,

Par l’alimentation de la base de données située sur le site http://www.argus-du-libre.com, qui permet d’alimenter le précédent document.

Répartition

L’Argus requiert une relation permanente entre les consultants de Linagora et les communautés, raison pour laquelle le périmètre logiciel n’est pas ouvert à tous les projets Open Source, mais plutôt restreint aux logiciels pertinents dans les différents domaines sur lesquels Linagora sait d’ores et déjà s’engager en terme de support et de maintenance au travers de son offre de TM2L.

Chaque projet est réparti parmi 7 domaines et dans une vingtaine de groupes de logiciels. Il est donc plus simple pour les utilisateurs d’identifier les différents logiciels évalués pour un domaine particulier.

Avertissement

Les critères précisés ci – dessous classés ont été évalués par nos soins, ne reflètent qu’un avis et non une réalité mesurable et tangible. Ils sont pourtant le reflet exact de notre avancement, des écueils et des succès rencontrés avec chacune d’entre elles.

Les critères

Chaque projet est présenté par les éléments suivants, qui constituent sa carte d’identité :

• Son nom,

• Une description succincte,

• Son URL,

• Eventuellement, de quel autre projet (produit) il est dérivé,

• Son groupe d’appartenance fonctionnelle,

• Le consultant de Linagora qui en charge de la mise à jour des informations le concernant,

• Sa licence. Certains projets possèdent plusieurs licences, de façon à protéger de façon différente du code issu d’un produit commercial, et du code issu des travaux des développeurs de la communauté. Il s’agit par exemple du cas d’OpenOffice.org, simultanément sous licence GPL et SISSL. Dans ce cas, l’Argus indique, pour l’instant, la licence la plus contraignante (dans l’exemple précédent, SISSL). Dans une seconde version l’ensemble des licences seront recensées pour chaque projet,

• Date de lancement du projet (ou de la première version),

• Date de clôture du projet. Cette date n’est précisée que si le projet est clôturé, ce qui signifie qu’il est en général suivi par un autre (cas de NetSaint devenu Nagios),

• Date de dernière release majeure,

• Temps moyen entre deux versions majeures. Ce temps est donné ici à titre indicatif (et exprimé en jours) en se basant sur le délai entre les deux versions majeures précédentes. Etant donné la numérotation choisie par certains projets, le calcul n’est présenté que pour la dernière version.

• Nombre de versions mineures entre deux versions majeures. Etant donné le délai entre deux versions majeures pour certains projets, ce chiffre permet d’avoir une idée du nombre d’étapes intermédiaires, et donc de la régularité de la communauté correspondante.

• Nombre de développeurs du projet. Il s’agit là d’un nombre très variable suivant les projets, et il n’est pas aisé de pouvoir clairement identifier les différentes catégories de développeurs d’un projet. Toutefois, le nombre indiqué pour chaque projet essaye d’être le plus proche possible d’un nombre réaliste, c'est-à-dire du nombre effectif de développeurs sur un projet donné.

• Nombre moyen de courriers électroniques échangés par mois. Ce nombre indique le dynamisme de la communauté. Il est calculé sur la base des deux mois précédents la dernière mise à jour (hors mois d’été et périodes de congés), et se base sur la volumétrie des listes de développement cumulée à celles des utilisateurs dépendant directement du site principal du projet (il s’agit de l’activité réelle observée sur les listes de la communauté, bien que celles-ci puissent être largement complétées par des listes extérieures non prises en compte dans l’Argus),

• Langage principal de développement du projet,

• Nombre de lignes de code dans le projet. Le volume de ligne de code est le résultat total du calcul du programme SLOCCount (http://www.dwheeler.com/sloccount/) reconnu par la communauté comme la référence en la matière. Ces informations permettent  d’appréhender les efforts et l’investissement nécessaires afin d’intégrer et coder au sein d’une communauté. Le langage de développement principal est donc celui qui ressort parmi l’ensemble des types de programmes utilisés et référencés par le comptage effectué via SLOCCount. La multiplicité de la nature des programmes, ainsi que la volumétrie du code interviennent sur la difficulté pour supporter le projet correspondant,

• Nombre de pages d’aides disponibles en accès direct depuis le système (manpages ou Winhelp),

• Volume indicatif de pages d’assistance et de documentation sur le composant,

• Disponibilité de listes de questions fréquemment posées et de « HOWTO ». Signe manifeste de maturité d’un projet Open Source, la documentation, qu’elle soit en ligne ou sous forme de pages d’assistance, constitue toujours un facteur important d’élargissement d’un projet. Quant à l’assistance offerte par les FAQ ou les HOWTO, il s’agit de l’expression du retour d’expérience des utilisateurs sur un projet, ce qui atteste en général du niveau technique et de l’implication des membres d’une communauté. Ce type de document contient également l’ensemble des « recettes » que les différents intervenants ont mises au point de façon à satisfaire des besoins d’administration ou d’exploitation du projet au sein de leur organisation,

• Nombre de RFC (IETF) issus du projet,

• Nombre de draft (IETF) issus du projet. Le processus de normalisation à l’IETF est organisé en comités. Ceux-ci, comme n’importe quel particulier ou entreprise, peut soumettre une demande de normalisation sous forme de « draft », forme embryonnaire de la RFC (requête pour commentaires). Ce processus nécessite en général plusieurs tentatives et de nombreux mois voire quelques années. Un projet Open Source se doit non seulement de respecter les standards, mais également d’être moteur dans leur rédaction, dans leur élaboration et dans le cycle final de validation, comme l’est par exemple la communauté OpenLDAP autour de la liste ldap-ext, regroupant le comité de travail sur la recommandation d’extension du protocole LDAP,

• Langue principale de la communauté,

• Représentativité de la communauté francophone. Ce type d’information permet d’identifier l’existence d’une communauté française de façon à partager les mêmes problématiques techniques, mais également certaines problématiques organisationnelles localisées, dans sa langue maternelle,

• Facilité d'intégration ou de réintégration d'une modification,

• Nombre moyen de bugs déclarés par mois. Ce nombre reflète du nombre de problèmes identifiés par les utilisateurs d’un projet, c'est-à-dire de la faculté de déclaration et d’intégration (processus initial de prise en compte des bugs). Trop faible, cela signifie que la communauté n’est pas assez active ou bien que l’utilisation du logiciel n’est pas encore répandue. Dans certains cas, le projet est arrivé à maturité et le nombre réel de bugs peut diminué de façon conséquente,

• Nombre moyen de bugs en attente de corrections. Ce nombre indique que les problèmes identifiés sont en attente de correctifs, ou de validation par des tiers. Ils persistent donc dans les différentes releases effectuées entre temps. Cela signifie en général que le problème ne peut être simplement résolu mais nécessite un changement de fond du logiciel, uniquement envisagé dans une phase de changement de version majeure,

• Nombre moyen de jours nécessaires au processus de correction des bugs. Ce délai permet d’observer le temps nécessaire à la correction d’un bug. Il indique uniquement le temps de résolution, tests inclus. Cela ne signifie pas qu’une release sera proposée immédiatement après la propagation de la correction dans le code du projet. Cela signifie donc que le bug peut n’être effectivement corrigé que dans la prochaine version du projet, dont la date de livraison est rarement garantie.

Par ailleurs, deux tableaux complémentaires sont fournis afin de pouvoir :

• Mesurer la compatibilité du projet sur les différents systèmes identifiés,

• Mesurer l’internationalisation du composant (disponibilité en différentes langues).

Ces critères sont donnés à titre indicatif sur la base de quatre niveaux permettant de déterminer si la compatibilité et l’internationalisation sont :

• Disponibles,

• En cours,

• En projet

• Impossible.

 

Synthèse et critères principaux

L’ensemble de ces facteurs nous a permis de déterminer trois dimensions pour apprécier une communauté :

• L’axe de la communication :

• Perméabilité et intégration :

Que ce soit au travers des contacts établis avec les développeurs principaux, ou avec d’autres développeurs, cet indice permet d’appréhender la complexité d’interagir avec une communauté afin de trouver une assistance (en générale purement technique).

• Documentation, aide en ligne et assistance

Important avant tout, il constitue la première approche d’une personne avec le projet, il s’agit de la documentation, des FAQ, HOWTO… Il se mesure principalement au présent (au contraire des deux autres axes) et prend en compte la volumétrie, la clarté, la disponibilité dans des langues différentes de la documentation et de la communauté.

• L’axe technique :

• Ouverture de la communauté :

Il s’agit d’un indice permettant d’observer l’acceptabilité d’un patch, d’idées ou plus généralement d’interactions techniques en terme de développement avec la communauté. Ce critère est noté sur la base de notre expérience lors de nos différents projets de communication et de reversement à la communauté, ce qui nous a permis de déterminer le degrés d’interactions possibles avec chacune d’entre elles et donc la possibilité de pouvoir offrir de nouvelles fonctionnalités ou des corrections de bugs au travers d’une contribution.

Cet indice est non seulement évalué à un instant donné, mais également sur son évolution attendue.

• Stabilité et robustesse du projet :

Suivant les conditions d’utilisation, un même projet, et surtout deux versions même relativement proches, peuvent se révéler fondamentalement différentes. Nous avons donc essayé d’indiquer retour d’expérience sur des tests en condition d’utilisation réelle, mais surtout en tenant compte des possibilités pour le faire évoluer (haute disponibilité, équilibrage de charge, …) afin d’assurer sa mission en environnement critique.

Il s’agit d’un facteur important, impactant le coût du support d’un tel projet, car intervenant dans la complexité et la tenue en charge de l’infrastructure dans laquelle il est déployé.

Ce critère est également observé de façon instantanée, mais est lissé, au regard de l’historique et des évolutions récentes de la communauté et du projet.

• L’axe projet :

• L’état instantané du projet :

Il s’agit de donner une mesure qualitative permettant de mesurer l’utilisabilité, l’intégrabilité, l’adéquation aux besoins finaux des utilisateurs, l’exploitabilité, etc. C'est-à-dire l’ensemble des caractéristiques du projet qui découlent de sa mise en œuvre et de son suivi dans les organisations. De ces points découle la maturité du projet concerné.

• Les possibilités d’évolutivités : Elles sont liées à :

• La qualité de la conception permettant de reprendre certains parties importantes lors de l’évolution du système (utilisation d’I/O non bloquantes, etc.),

• L’intégration de codes extérieurs sous forme de plugin, modules, ou tout élément facilement intégrable qui ne dépend pas directement du projet, ce qui permet d’avancer beaucoup plus rapidement sans alourdir de façon trop importante la procédure d’intégration et de support,

• La présence d’API clairement documentées permettant de rajouter simplement des modules au logiciel,

• Le respect des normes d’interopérabilité, des standards de fait (comme l’utilisation systématique de XML, des webservices, etc.)