Emmanuel LÉCHARNY

Expert Infrastructure

Cet article a pour objectif de lister les différents points à ne pas négliger quand on commence un projet intégrant des composants Open Source.

On va tout d’abord présenter l’impact économique de l’Open Source et de son emploi. On s’attachera ensuite à définir les critères de choix des composants, puis les contraintes associées. On terminera par quelques exemples du monde réel pour mettre en exergue les points d’achoppement et la difficulté de s’appuyer sur ces composants.

Toutes les parties de cet article sont accessibles ci-dessous :

Commençons par définir les besoins et les contraintes au niveau technique et économique, mais aussi juridique et organisationnel.

Rapide balayage historique

Le mouvement Open Source n’est pas récent. Il fut un temps où la notion de “propriété intellectuelle” n’existait tout simplement pas. Il faut attendre le 18ème siècle pour que soit instauré le droit d’auteur. Le partage était néanmoins limité par la difficulté de se procurer des supports à moindre coût. Les copistes du Moyen-Age étaient un parfait exemple de système de partage de connaissances, certes limité à un domaine assez restreint…

Dans le domaine de l’informatique, le partage de code et de spécifications se pratique très vite. Les RFC (“Request for Comments”) sont publiées à partir de 1969. Toutefois, le partage de code a existé depuis au moins1955, quand les membres du groupe SHARE mettaient à disposition de tous les modifications logicielles du code tournant sur des serveurs IBM.

Le mouvement “Open Source” se développe fortement dans les années 1980 et 1990. On parlait alors de “free software”. Mais pour supprimer l’ambiguïté du mot “free”, le terme Open Source a été validé qu’en 1998.

À cette même période, voient le jour des projets comme GNU et Linux et des fondations comme The ASF, qui deviennent rapidement des acteurs incontournables de l’Open Source. Considérés comme un “cancer” par certains gros éditeurs, ils vont effectivement métastaser l’écosystème, au point qu’il est difficile aujourd’hui d’imaginer un développement informatique ne comportant pas de composants Open Source. Et cela sans tuer les sociétés qui les utilisent ;-)

L’OSS en 2026

On peut donc considérer qu’en 2026, l’Open Source (OSS) est partout. Dans l’étude “The Value of Open Source Software”[1], on peut lire :

…recent studies have come to similar conclusions showing that open source software (OSS) – software whose source code is publicly available for inspection, use, and modification and is often created in a decentralized manner and distributed for free – appears in 96% of codebases (Synopsys 2023), and that some commercial software consists of up to 99.9% freely available OSS (Musseau et al., 2022)

La quasi totalité du logiciel produit s’appuie donc sur des composants Open Source. Il est illusoire d’imaginer un retour en arrière.

Quelle est la valeur de l’OSS et comment la mesurer ?

Se pose la question de la valorisation de l’Open Source et de son coût. Tout d’abord, on peut évaluer son coût de “remplacement”, à savoir combien coûterait le développement des composants Open Source si chaque acteur économique les utilisant devait les réécrire, ou les acheter. Sur quelle base cette valorisation est-elle effectuée ? Un produit commercial a une valeur théorique qui correspond à un prix de vente multiplié par une quantité vendue. Dans le cas de l’Open Source, le prix de vente peut être considéré comme nul (même s’il est toujours possible de vendre un logiciel Open Source, si on trouve un acheteur…). On calcule alors la valeur de remplacement à partir :

  • du coût du logiciel s’il devait être réécrit,
  • du nombre d’entreprises l’utilisant,
  • Ou de l’achat d’un logiciel propriétaire équivalent, avec le coût du support récurant.

L’étude “The Value of Open Source Software” citée plus haut donne cette évaluation :

  • Le coût de remplacement s’élèverait à 8,8T$, soit environ le PIB du Japon et de l’Inde combinés.
  • Le coût d’écriture unitaire représenterait 4,15G$.
  • Les acteurs économiques dépenseraient 3,5 fois plus en logiciels si l’Open Source n’existait pas.

Un petit exemple

Apache Directory Studio est un logiciel assez largement utilisé dans le monde LDAP.

Il comporte environ 260 000 lignes de code (sans compter les sauts de ligne ou les commentaires, ce qui en double le nombre), soit 10 millions de dollars (selon le modèle COCOMO - Constructive Cost Model -). Le remplacement de ce logiciel Open Source représenterait un effort total de 2,7 ans pour une équipe de 26 développeurs.

En réalité, Apache Directory Studio a été développé à 98% par 3 personnes. Le projet a démarré il y a 20 ans même si l’essentiel du travail s’est concentré sur 7 années.

Il est donc clair que les contraintes du monde professionnel ne s’appliquent pas à l’Open Source, en général. Néanmoins cela donne une idée de ce que peut représenter le coût du développement d’un logiciel Open Source.

Les choix techniques

Bien choisir un composant est essentiel, puisqu’on ne va pas le réécrire. Il est primordial de déterminer les critères de sélection. Ils se répartissent en deux catégories :

  • Les critères mesurables
    • L’adéquation au besoin
    • La compétence interne sur le composant choisi
    • Les performances attendues du composant
    • L’intégration avec les autres composants
    • Les limitations du composant
    • La facilité à administrer et à monitorer le composant
  • Les critères non mesurables
    • La maintenance du projet d’où est issu le composant
    • La possibilité d’y apporter des corrections
    • La qualité de la documentation
    • Le support des failles de sécurité

Cette liste n’est pas exhaustive, mais représente tout de même un ensemble de points pertinents permettant de comparer les composants disponibles et de faire un choix.

Les critères mesurables

De toute évidence, le composant doit répondre à votre besoin technique et fonctionnel. C’est la première étape. Pour valider cette adéquation, il convient de conduire des tests et de réaliser des études de cas ainsi qu’une évaluation fonctionnelle.

Cela suppose que les personnes en charge de cette étude aient la compétence requise pour la mener à bien ou aient recours à des compétences extérieures, ce qui engendre un coût supplémentaire.

La notion de performance est importante, elle sera un des facteurs de dimensionnement de la plateforme sur laquelle tournera le logiciel. Il faut tenir compte des effets de saturation, où les performances peuvent diminuer de façon non linéaire.

L’intégration est à mettre en regard des technologies déjà utilisées et maîtrisées (langage, OS, etc). De même les APIs doivent être étudiées avec soin pour s’assurer qu’elles sont adaptées au besoin.

Un composant Open Source a des limitations, de même qu’un composant privatif. S’il est possible de demander des corrections et des évolutions à une société commerciale, c’est beaucoup plus compliqué pour un projet Open Source, dont le développement est généralement assuré par des volontaires.

Enfin une fois le composant intégré, il faudra le maintenir : montées de versions, analyse des problèmes, corrections des anomalies, sans compter la formation des utilisateurs.

Tout ces critères mesurables vont représenter un coût à internaliser, qu’il ne faut pas négliger lors du choix.

Les critères non mesurables

Ils regroupent les facteurs qu’il n’est pas possible d’évaluer techniquement.

Quand on choisit un composant Open Source, on choisit une communauté : celle qui développe et maintient le produit. Cette communauté n’a aucune obligation autre que celles qu’elle s’impose. Il faut en être conscient, accepter ce risque et l’intégrer dans son plan produit. Un composant Open Source développé au sein d’une fondation comme The ASF ou Eclipse Foundation offre tout de même une garantie plus poussée de pérennité et de qualité sur le long terme, du fait des contraintes imposées aux projets. Par exemple, en ce qui concerne The ASF, on peut citer ces règles :

  • Un projet ne peut rejoindre la fondation que s’il a atteint un niveau de maturité suffisant.
  • Il doit passer par une phase d’incubation sous la supervision d’au moins trois membres de la fondation.
  • Il ne peut sortir de l’incubation tant qu’une release n’a été fournie.
  • Un projet doit disposer d’au moins trois participants actifs de trois sociétés différentes, ce qui interdit la main-mise d’une seule entreprise sur ce projet.
  • Des revues trimestrielles sont à fournir au Board par le responsable de chaque projet.
  • Enfin un projet inactif sera reversé dans l’Attic.

Il est également possible de corriger par soi-même une anomalie critique ou bloquante, ou de développer une fonctionnalité manquante, puisqu’il s’agit d’Open Source. Reste à savoir dans quelle mesure ces corrections ou ajouts vont être intégrés dans les futures versions. Le risque étant d’avoir à maintenir un “fork”.

Un autre aspect qui est souvent reproché aux composants Open Source est la qualité de la documentation. Les projets Open Source n’ont pas nécessairement les moyens de disposer de rédacteurs techniques en charge de la documentation, et c’est généralement du “best effort”. Il n’est pas rare d’avoir des composants dont la seule documentation est le code source, et l’API exposée. Internet reste souvent un moyen d’obtenir l’information manquante, en s’appuyant sur la communauté des utilisateurs.

Enfin il faut tenir compte de la capacité d’une communauté Open Source à prendre en compte les failles de sécurité critiques. L’information est généralement fournie trop tard, lorsqu’elle est déjà publique. En effet, il y a rarement une politique d’alerte privée permettant d’informer les utilisateurs principaux avant la divulgation de la faille corrigée, ce qui est plutôt logique étant donné qu’un projet Open Source ne connaît pas ses utilisateurs (sauf cas d’espèce). Si un processus documenté de gestion des CVE (Common Vulnerabilities and Exposures) existe déjà, c’est un plus. The ASF dispose d’un tel processus[2], par exemple.

Au final, il est compliqué d’associer un coût à ces critères, mais il est nécessaire à tout le moins de les intégrer en terme de gestion du risque.

Les choix organisationnels

Les éléments qui doivent être pris en compte lors du choix d’un composant Open Source sont également directement liés à des choix organisationnels :

  • Disponibilité des ressources internes,
  • Disponibilité de support,
  • Vitalité du projet,
  • État de la communauté,
  • Type de communauté.

Le composant sélectionné doit être pris en main par les équipes internes. Il leur faut l’intégrer, en comprendre le fonctionnement, le tester, valider les performances par rapport aux besoins, gérer les alarmes, le monitorer… En un mot, se l’approprier.

Il est possible d’employer des consultants externes connaissant le composant, encore faut-il les trouver ! Plus le composant est connu, plus il est facile de trouver une ressource externe.

On peut également se poser la question du support : les composants les plus connus sont généralement supportés par de nombreuses entreprises. Reste à qualifier leur niveau de compétence…

Un aspect à ne pas négliger est l’état de la communauté autour du projet. Y-a-t-il une liste de diffusion sur laquelle envoyer les questions que l’on se pose ? Est-elle active ? Les releases sont-elles fréquentes ? Les anomalies remontées sont-elles prises en charge rapidement et efficacement ? Plus généralement, combien y-a-t-il de participants actifs ? Github permet par exemple de vérifier l’activité sur une période de temps afin de se rendre compte si le projet est toujours activement maintenu et développé, pour autant qu’il soit hébergé sur cette plateforme.

Quand aux contributeurs, il faut également se poser la question de leur implication et du cadre de leurs contributions. S’ils sont salariés par des entreprises qui financent leurs travaux, la question de savoir s’ils continueront en cas de changement de cadre professionnel se pose. L’âge des contributeurs est également un facteur à prendre en considération : personne n’est éternel (et chacun va prendre sa retraite à un moment donné…) !

Enfin le type de communauté donne une idée de la direction que peut prendre un projet. Il existe plusieurs modes de fonctionnement, du ‘‘one man show’’ en passant par le BDFL (Benevolent Dictator For Life) jusqu’à un système totalement décentralisé sans direction formelle, où les décisions se prennent collégialement. En pratique, on se trouve souvent confronté à de très petites communautés, ou bien à des communautés adossées à des entreprises commerciales.

Les choix économiques

À ne pas négliger ! Sauf à disposer d’une équipe “couteau suisse” capable de prendre en charge la totalité des composants choisis, il sera sans doute nécessaire d’avoir recours à des experts sur quelques composants essentiels. Et ce n’est pas gratuit !

L’alternative est de souscrire à un contrat de support, ce qui se pratique fréquemment. On entre alors dans un modèle proche de celui d’un éditeur logiciel dont on a acheté un produit, le prix du produit en moins. En réalité, c’est ainsi que se financent de nombreux éditeurs Open Source.

Si votre composant est amené à être exécuté dans le cloud, ou si vous recourez à un service PaaS, il y aura des coûts induits, qui peuvent être conséquents. De nombreux éditeurs logiciels Open Source ont modifié leur modèle de licence pour interdire l’utilisation de leurs produits par des fournisseurs PaaS pour des raisons évidentes. L’impact est alors majeur pour les utilisateurs. Par exemple, une base de données comme MongoDB ne peut pas être utilisée dans sa version Open Source en mode “as a service”. Les coûts peuvent vite se monter à plusieurs dizaines de milliers d’euros par mois pour des volumétries importantes, si on a recours à des solutions basées sur ce produit.

Globalement, les services de type PaaS ne sont pas gratuits et nécessitent une évaluation de l’impact financier lié à ce choix.

Les choix juridiques

Un dernier aspect à prendre en compte, qui n’est pas le moins important, est le type de licence du composant. Toutes les licences Open Source ne se valent pas, certaines sont permissives, d’autres non. Il est primordial d’en comprendre les tenants et aboutissants avant d’opter pour une solution. Il y a trois grandes catégories de licences :

  • “copyleft”, ou “contaminantes” : GPL et dérivées. Ce type de licence impose que les versions dérivées sont soumises aux règles de la licence d’origine.
  • “Permissives” : AL, MIT, BSD… Ce type de licence autorise l’utilisation des composants sans imposer de règles autre que celle de tracer la paternité du code (en l’occurrence, rendre accessible le texte de la licence dans le produit final).
  • “Asymétriques” : Il s’agit de licences autorisant l’utilisation du composant dans un certain cadre, tout en limitant son usage en dehors de ce cadre. C’est, par exemple, une autorisation d’utiliser le composant pour le propre usage d’une entreprise, mais une interdiction d’en permettre l’usage pour les clients de cette même entreprise.

Il existe plusieurs dizaines d’autres licences. Il est nécessaire d’en faire le recensement et d’en étudier les contraintes juridiques avant d’intégrer les composants associés. A ce titre, il peut être judicieux de recourir aux conseils d’un juriste.

Enfin, il faut tenir compte des dépendances transitives ! Un composant Open Source n’arrive jamais seul, il est la plupart du temps lui même consommateur d’autres composants Open Source. Il convient de faire l’étude de chacune de ces dépendances pour faire son choix en connaissance de cause.

Le document produit par The Linux Foundation[3] donne une idée assez précise de ce qu’il convient de prendre en compte lors d’une étude de “compliance” d’un composant.

Lire la suite : Open Source et développement - Partie 2 : Versions, licences, évolutions et maintenance, la vie du composant Open Source après son intégration

Bibliographie

[1] The Value of Open Source Software
[2] ASF Project Security for Committers
[3] Open Source Compliance

Vous pourriez aimer aussi