[Entreprises] Comment choisir entre plusieurs solutions open source ?

Cet article a été publié il y a 14 ans 2 mois 16 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Voici une liste de points à vérifier lorsque l’on hésite entre plusieurs solutions open source formulée par Chamindra de Silva directeur du projet open source Sahana (gestion des catastrophes naturelles) créé après le tsunami asiatique de décembre 2004

1: Les clauses de la licence open source sont-elles compatibles avec mes objectifs commerciaux ? L’argument qui consiste à dire que les logiciels open source posent des problèmes du fait de leur licence est assez courant. De fait, leur diversité appairait souvent comme un facteur pouvant entraîner des risques pour les entreprises. Pour cela il faut considérer deux cas de figure :

• L’usage d’un logiciel open source a des fins purement interne. Exemple : un logiciel de gestion d’entreprise (ERP). Dans ce cas il n’y a aucun risque à utiliser des logiciels open source. Leur licence ne peut être un facteur limitant de votre activité. Bien au contraire, vous pourrez facilement faire évoluer et sans coût de licence supplémentaire votre nombre d’utilisateurs. De plus, l’ouverture du code peut vous permettre de réaliser des développements spécifiques à vos objectifs commerciaux
• L’usage de logiciel open source dans un produit que vous allez commercialiser. C’est le cas de figure qui nécessite le plus d’attention. Selon la  licence du code source embarqué dans votre produit et sa « viralité » (l’obligation de mettre à disposition votre produit sous la même licence), vous pouvez vous trouver confronter à un dilemme si  le logiciel que vous voulez commercialiser  doit être propriétaire. Dans ce cas de figure vous devez abandonner et remplacer ce code source ou en trouver un équivalent dont la licence open source ne contienne pas de clauses virales. Le plus simple est évidemment de faire un logiciel open source en prenant soin de choisir une licence compatible avec le code d’origine. Il sera bon de faire appel à un spécialiste en cas de doute.

2: Quelle est l’importance de la communauté ? Le code seul n’est rien sans une communauté pour le porter. L’importance de cette dernière est un bon indicateur de la santé d’un projet. Mais l’importance de la communauté ne fait pas tout. Dans certains cas, notamment celui des éditeurs commerciaux open source, le développement du logiciel est financé à 100% par l’éditeur. A tel point que contribuer au projet est un processus long et complexe. L’ouverture du code ne fait donc pas tout.

3: Quelle est l’étendue de l’adoption de ces produits par les utilisateurs ? Un point a étudier certes, mais qui n’est guère spécifique aux logiciels open source. Une base d’utilisateurs large et variée est toujours un gage de qualité. Des propos que je vais modérer tout de suite, car cela reviendrait à dire que les produits Microsoft sont incontournables, car largement utilisés. La loi du grand nombre n’est pas forcément la plus juste. C’est  parfois un raccourci qui peut vous faire passer à côté du logiciel peu connu, mais aux fonctionnalités particulièrement attrayantes et efficaces.

4: Puis-je obtenir des garanties ou un support commercial si nécessaire ? Dès que l’on parle de l’usage d’un logiciel en entreprise se pose la question du support qui reste indispensable si l’on souhaite offrir une disponibilité importante à une application.

5: Existe-t-il un processus qualité ? L’existence de processus qualité au sein d’un projet open source peut servir d’indicateur pour estimer sa maturité. Il faut cependant être en mesure aussi de vérifier sa bonne application. Tout sera ici encore une fois une question d’ouverture au niveau de projet. Sur le sujet de la qualité des logiciels open source vous pouvez vous reporter au site Scan.coverity que je vous présentais lors de la sortie d’une de leurs études.

6: Quelle est la qualité de la documentation ? Elle peut prendre bien des formes : depuis un simple fichier texte placé au milieu des sources à un Wiki complet et détaillé. Tous les projets ne sont pas égaux devant la documentation bien souvent. La possibilité de la consulter apporte un plus évident, car elle peut permettre dans une certaine mesure de se rendre compte de la facilité de mise en oeuvre du logiciel ou de vérifier la couverture fonctionnelle.

7: Est-ce que le système peut-être facilement personnalisé pour répondre exactement à mes besoins ? La question peut paraître saugrenue dans le cadre du logiciel open source. Pourtant, elle a un sens si l’on considère non pas le simple fait d’avoir le droit de modifier le code, mais la façon dont le logiciel a été développé pour le permettre (extension par plug-in, API, etc). Il faut aussi considérer les compétences nécessaires, le langage utilisé ou les framework de développement qu’il faut maîtriser. Ceci peut parfois réduire le nombre de prestataires capables de réaliser ces modifications à peau de chagrin et vous retrouver dans une situation quasi-similaire à l’emploi d’un logiciel propriétaire.

8: Comment le projet est-il dirigé et est-il possible d’influencer la roadmap ? Lorsque l’on étudie certains projet open source, souvent porté par des éditeurs commerciaux (mais pas uniquement), on constate qu’il est difficile de contribuer au code et que l’avis des utilisateurs ou les remontées d’anomalies ou de demandes d’évolution sont peu suivies dans les faits. C’est un point qu’il n’est pas forcément simple d’évaluer, car il demande d’observer le projet durant une période de temps assez longue pour pouvoir en tirer des conclusions. L’aspect communautaire revêt ici toute son importance, car n’oublions pas que les logiciels open source sont censés être « pilotés par l’utilisateur ».

9: Le produit pourra-t-il évoluer avec la croissance de mon entreprise ? La capacité de montée en charge du logiciel afin de répondre à une forte croissance ponctuelle ou continue est bien sûr indispensable. Mais ce n’est pas un aspect exclusif aux logiciels open source

10: Y a-t-il des mises à jour de sécurité régulières ? La sortie régulière de version mineure apportant des correctifs de sécurité est bien sûr importante et encore une fois pas seulement pour le logiciel open source. Mais on sait que l’ouverture du code permet un audit externe de ce dernier et peut donc grandement faciliter le « déminage » d’un logiciel.

En synthèse, tous ces points ne sont pas spécifiques aux logiciels open source. Il font cependant partie de la liste de contrôle indispensable avant de prendre une décision.