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.
Toutes les parties de cet article sont accessibles ci-dessous :
- Open Source et développement - Partie 1 : Comment choisir votre composant Open Source
- Open Source et développement - Partie 2 : La vie du composant Open Source après son intégration
- Open Source et développement - Partie 3 : Questions ouvertes : bugs, IA, souveraineté et autres
Après avoir défini les critères de choix des composants, nous allons étudier les éléments techniques permettant d’effectuer un choix éclairé.
Les versions
Généralement, un composant Open Source est utilisé dans sa dernière version, mais ce n’est pas toujours le cas. Il est parfois nécessaire d’opter pour une version antérieure.
Du fait du nombre limité de contributeurs, il est rare que plusieurs versions d’un composant soient maintenues. Il faut s’en assurer quand on fait son choix et comprendre que l’impact d’une montée de version peut être important.
La plupart des projets utilisent la notation “Semantic Versioning”, avec des versions utilisant la notation X.Y.Z :
- X représente les versions majeures, qui ne sont pas compatibles entre elles. L’introduction de modifications dans l’API est souvent la raison de ce changement de version.
- Y représente les versions mineures, qui restent compatibles. L’introduction de nouvelles fonctions ne cause pas de modification de l’API, la nouvelle version reste utilisable sans changement du code qui s’appuie sur le composant.
- Z représente les correctifs apportés au composant, sans changement de l’API.
Ce type de notation n’est pas universel. Une autre logique relativement récente consiste à livrer de nouvelles versions incrémentales fréquemment. Les utilisateurs doivent alors prendre en charge les ruptures techniques à chaque changement de version. On pourrait par exemple citer les navigateurs Chrome ou Firefox qui ont un cycle de release particulièrement court (environ une par semaine). Dans tous les cas, une veille technologique est indispensable. Des outils de suivi existent, tel Dependabot qui permet de savoir au jour le jour quel composant a changé de version.
Un autre aspect important concerne l’environnement dans lequel s’exécute le projet. Il est parfois nécessaire de maintenir un projet utilisant de vieilles versions d’un langage (par exemple Java 8) ou d’une version d’OS. En pratique, il suffit souvent de vérifier le bon fonctionnement dans les différentes versions d’un environnement. L’impact est clair : cela interdit souvent l’utilisation des dernières fonctionnalités. Néanmoins il faut être conscient que l’abandon d’une version impacte une quantité non négligeable d’utilisateurs.
Le problème est que la fréquence des releases tend à s’accroître, augmentant ainsi la charge de travail. Il n’est pas à exclure que cela devienne une difficulté de plus en plus importante, dans la mesure où un projet s’appuie sur des librairies, utilisées dans un framework logiciel qui s’appuie à son tour sur un container applicatif, lui-même exécuté dans une plateforme logicielle, dans une machine virtuelle ! Par exemple, Log4J utilisé dans une application Spring, tournant sur Tomcat, dans Docker, sur VMWare…
Pour illustrer ce propos, cette image représente les versions de l’API Apache LDAP téléchargées au mois de décembre 2025 : plus de 39 versions différentes, certaines datant de 12 ans (!!!) sont toujours utilisées…
Les évolutions
On devra donc prendre en compte les évolutions de l’environnement d’exécution qui sont liées à plusieurs facteurs :
- Les versions de l’OS,
- Les versions de containers,
- Les évolutions du ou des langages utilisés,
- Les évolutions des librairies utilisées.
À cela s’ajoute les potentiels conflits de versions : il n’est pas rare que plusieurs composants intègrent eux-mêmes des librairies dont les versions sont incompatibles. C’est ce qu’on appelle classiquement le “dependency hell”.
En Java, cela peut se résoudre par l’utilisation d’une plateforme de service comme OSGi, qui permet d’isoler les composants entre eux. Il existe d’autres solutions, par exemple en JS où un composant va charger tout le code dont il dépend pour former un bloc de code autonome, au prix d’une croissance du code…
Dans tous les cas, il convient d’avoir en tête que cette gestion incombe au projet et que cela peut rapidement devenir complexe.
Les dépendances transitives
Pour aller plus loin, il est important de tenir compte des dépendances transitives, c’est à dire des dépendances utilisées par les composants choisis. C’est évidement récursif et il n’est pas rare d’avoir plusieurs niveaux de profondeur (ici, 9) :
[INFO] org.apache.directory.server:apacheds-installers:pom:2.0.0.AM28-SNAPSHOT
[INFO] +- org.apache.directory.server:apacheds-service:jar:2.0.0.AM28-SNAPSHOT:compile
…
[INFO] | +- org.apache.directory.server:apacheds-service-builder:jar:2.0.0.AM28-SNAPSHOT:compile
…
[INFO] | | +- org.apache.directory.server:apacheds-http-integration:jar:2.0.0.AM28-SNAPSHOT:compile
[INFO] | | | +- org.apache.directory.server:apacheds-http-directory-bridge:jar:2.0.0.AM28-SNAPSHOT:compile
[INFO] | | | \- org.eclipse.jetty:jetty-webapp:jar:9.4.56.v20240826:compile
[INFO] | | | +- org.eclipse.jetty:jetty-xml:jar:9.4.56.v20240826:compile
[INFO] | | | | \- org.eclipse.jetty:jetty-util:jar:9.4.56.v20240826:compile
[INFO] | | | \- org.eclipse.jetty:jetty-servlet:jar:9.4.56.v20240826:compile
[INFO] | | | +- org.eclipse.jetty:jetty-security:jar:9.4.56.v20240826:compile
[INFO] | | | | \- org.eclipse.jetty:jetty-server:jar:9.4.56.v20240826:compile
[INFO] | | | | +- javax.servlet:javax.servlet-api:jar:3.1.0:compile
[INFO] | | | | +- org.eclipse.jetty:jetty-http:jar:9.4.56.v20240826:compile
[INFO] | | | | \- org.eclipse.jetty:jetty-io:jar:9.4.56.v20240826:compile
…
Il faudra vérifier toutes les dépendances transitives, leur licence, leur version, leur signature. Ne pas négliger non plus qu’un repository peut également avoir été attaqué ou certaines dépendances avoir été modifiées…[4]
Les SBOMs, une solution ?
Le SBOM (Software Bill Of Material, ou Nomenclature Logicielle) est la liste officielle des dépendances. Il permet de contrôler les licences, de lister les dépendances transitives, de donner la version de chaque composant, de vérifier les signatures et éventuellement d’identifier les CVE associées aux versions utilisées. Il peut (et devrait !) être généré automatiquement. Il existe des outils qui génèrent le SBOM en différents formats, par exemple :
- Pour CycloneDX[5], qui fonctionne pour C/C++, Node.js, Python, Go, Ruby, Java, .NET, PHP, Javascript.
- Pour SPDX[6], qui fonctionne pour Java, Python et Go.
Ils génèrent une liste des dépendances, leur version, leur licence…
L’importance de cette nomenclature n’est pas à négliger. Un “Executive order”[7] a stipulé qu’un logiciel ne peut être utilisé par une entité publique aux USA si un SBOM n’est pas fourni. Par ailleurs, en Europe, le Cyber Resilient Act (CRA) en a fait un prérequis et le SBOM doit être livré en même temps que la documentation.
Il s’agit donc d’un élément de confiance à fournir, qui ne règle certainement pas tout, mais permet de s’assurer que l’utilisateur dispose de la liste des composants embarqués, ce qui simplifie le travail des utilisateurs.
Les licences
Dans le cadre du développement d’un produit, il faut définir la licence d’utilisation. Il n’est pas toujours possible de choisir celle que l’on souhaite adopter pour son produit. Dans certains cas, l’utilisation de composants Open Source impose le choix de la licence à utiliser.
Comme indiqué plus haut, la catégorie de licence à laquelle appartiennent les composants utilisés peut imposer le choix. C’est le cas de la licence GPL, qui est dite “contaminante”. Si vous choisissez une licence permissive, vous devrez en faire mention dans votre code et cette mention devra être accessible aux utilisateurs. Prenez votre iPhone, par exemple, allez sur Réglage -> Général -> Mentions légales et certifications -> Mentions légales, vous y trouverez la liste de toutes les licences de chaque composant utilisé. Et il y en a beaucoup ;-)
Quels sont les risques à ne pas respecter les licences, ou à en choisir une qui ne soit pas adaptée ? En réalité, tout dépend de la provenance du composant utilisé. Si celui-ci est maintenu par une société disposant d’un service juridique solide, cela peut s’avérer coûteux. En pratique, les deux risques principaux sont surtout l’obligation de publier l’intégralité de ses sources, si on a choisi un composant GPL par exemple, et l’obligation de basculer sur un autre composant dans un délai assez court. Dans tous les cas, ce n’est ni agréable, ni simple. Autant faire le bon choix dès le départ.
Le support
Partant du principe que le choix du composant a été effectué en tenant compte des différents points exposés précédemment, la suite logique est de se préoccuper de la vie de ce composant. Qui dit logiciel dit bugs, évolutions, améliorations… et l’obligation d’en tenir compte. On cherche ici à comprendre quels sont les besoins en support, qui en est responsable et les modalités de maintenance du composant choisi.
Quoi ?
La première étape est d’identifier les besoins. Cela passe par la qualification du composant sur les points suivants :
- Sa criticité dans la solution construite.
- La façon dont on a détourné les anomalies ou les manques fonctionnels lors de l’intégration.
- Le niveau de performance obtenu et attendu dans un futur proche ou moins proche.
- La présence ou non de système de supervision, de gestion d’alertes, de logs.
Il faut aussi tenir compte de la façon dont on l’utilise, selon qu’il est intégré au produit, ou hébergé (solution PaaS ou SaaS). Chacun de ses points doit être géré en amont et tout au long de la vie du produit.
Qui ?
Une fois que l’on sait ce qu’on attend d’un composant et ce qu’implique son usage, se pose la question de la responsabilité de son intégration et de sa maintenance en condition opérationnelle.
Il est possible de devenir un membre actif de la communauté, bénéficiant ainsi d’un levier important sur l’évolution du composant. C’est une des raisons pour lesquelles les éditeurs de logiciels recrutent des membres de communautés actives. Le cas de Red Hat est assez significatif, mais ce ne sont pas les seuls. Le bémol étant que la communauté est généralement diverse et que des agendas différents peuvent entrer en conflit.
On peut aussi s’appuyer sur la communauté pour obtenir un support. Rien n’est garanti, mais cela fonctionne étonnamment bien. L’être humain est doué d’empathie et, à condition de demander poliment, on obtient généralement les réponses à ses questions. Reste à voir dans quel délai…
Enfin, on peut aussi avoir recours à des experts externes (consultants, sociétés spécialisées dans le logiciel libre). La principale difficulté est la disponibilité de ces experts, leur coût et leurs compétences réelles. On peut également passer un contrat de service, charge au contractant de faire sienne cette recherche de compétences disponibles.
Comment ?
Une fois identifiée la ou les ressources pouvant répondre au besoin de support à court, moyen ou long terme, reste à définir un cadre de travail.
Dans le cas où le projet internalise ces ressources, il faudra prévoir des formations et/ou des embauches. Et sur une durée longue. L’acquisition de compétences internes est une solution solide.
L’alternative immédiate est le recours à des ressources externes. Il faut s’assurer de la compétence des intervenants, de la surface couverte par le prestataire et du coût induit. Cette solution a l’avantage de ne pas nécessiter une présence permanente : on peut y faire appel ponctuellement en fonction des besoins.
Il est également possible de ne pas internaliser le composant, mais de le ‘louer’, c’est la solution PaaS. L’avantage c’est qu’on s’adresse à une entité dont c’est le cœur d’activité, elle a donc un bon niveau de connaissance et de maîtrise du composant. C’est une solution absolument classique dès qu’on parle d’hébergement de sites web ou de bases de données. L’inconvénient est son coût, à quoi s’ajoute le risque de Vendor Lock-in : changer d’hébergeur n’est jamais simple. On l’a constaté lors du récent changement tarifaire chez VMware, la migration vers des solutions moins coûteuses (Proxmox par exemple) ne s’est pas faite sans peine…
Enfin la dernière possibilité est d’estimer que le composant est fiable, qu’une fois qu’il est intégré il n’y a pas lieu de s’en préoccuper et que, dans le pire des cas, on trouvera toujours une solution. Cela peut sembler inconséquent, mais c’est une pratique assez courante quand il s’agit de composants non critiques ou relativement simples. Les outils de test (Junit ou autre), de log (Log4J), les petites briques simples (il y en a des milliers dans le monde JS) sont fréquemment gérés de cette façon. Les risques sont de deux ordres :
- L’abandon du composant, qui n’évolue plus, faute de développeur,
- La faille de sécurité (CVE) qu’il faut corriger en urgence.
Sur ce second point, on a tous en mémoire les mésaventures de Log4J. Vous pouvez regarder la présentation qui a été faite en 2022 à ce sujet[8] et l’histoire de la correction du bug par celui qui était en charge du projet Log4j2[9].
Forker ou pas ?
Il y a de multiples raisons pour vouloir forker un composant. Il y a également de multiples raisons de ne pas le faire ;-)
Quand est-il intelligent de forker un composant ? Voici quelques raisons pertinentes :
- Quand la gouvernance du projet est inadaptée : exemple avec BDFL qui devient un Dictateur tout court, communauté fermée, projet focalisé sur un agenda commercial, projet en état de mort cérébrale, etc.
- Quand le projet change de “propriétaire” et que le nouveau ne respecte plus l’esprit initial du projet, ou risque de ne plus le respecter. Ça a été le cas de Hudson (remplacé par Jenkins après son rachat par Oracle), MySQL (remplacé par MariaDB après son rachat par SUN), OpenOffice (devenu Libre Office après son abandon par Oracle). Les exemples sont nombreux.
- Quand le projet n’est simplement plus maintenu. L’exemple le plus notable est le serveur Web NCSA qui a donné naissance à Apache httpd.
Mais il y a également autant de cas où forker est simplement une perte de temps ou une dilution de l’effort commun.
L’exemple de OpenSSL
L’histoire de OpenSSL est intéressante. Le projet a commencé comme un fork d’un autre projet (SSLEay, projet démarré en 1995, mais pour lequel les efforts de développement avaient cessés en 1998).
Jusqu’en 2014, OpenSSL a suivi une vie assez paisible, jusqu’à la survenue de la faille de sécurité HeartBleed, qui a été une des plus importantes de par son ubiquité. Cela a donné lieu à la création de forks pour diverses mauvaises raisons :
- Fork LibreSSL par des équipes de OpenBDS, suite à un audit du code. Plutôt que de décider de contribuer, ils ont préféré forker. En une semaine, 90 000 lignes de code ont été supprimées du projet initial… Le succès de ce fork reste à démontrer.
- Fork BoringSSL par Google. Pas de release, pas de communauté. Mais au moins Google a la main dessus pour son propre usage.
- Fork AWS-LC par Amazon. Au moins, il y a des releases…
- Fork QuicTLS, par Akaimai et Microsoft : l’objectif est d’intégrer la couche transport QUIC au dessus de OpenSSL 3.3. Une volonté d’intégrer la fondation Apache a été exprimée.
Au final, l’épisode malheureux a permis la création d’une fondation dédiée (OpenSSL Foundation), l’embauche de 14 salariés et la mise en place d’un budget de développement significatif.
LTS ou pas ?
Autre problème : la maintenance des composants à longue durée de vie ? Le serveur Apache httpd n’existe que dans 2 versions majeures, la 1.X et la 2.X. Aujourd’hui, seule la version 2.4 est supportée. D’autres projets proposent des versions appelées LTS (Long Time Support) avec un engagement de maintenance sur une durée garantie. Cela signifie que les bugs découverts sur les dernières versions seront éventuellement back-portés vers les anciennes versions si nécessaire et qu’une correction des anomalies est assurée.
On doit se poser la question d’opter pour de telles versions LTS, plutôt que pour des versions intermédiaires à rotation rapide. Le cas de Java est assez typique :
- des LTS toutes les 4 versions,
- un support (gratuit) de la version sur 5 ans,
- des versions intermédiaires qui ne sont supportées que jusqu’à la sortie de la nouvelle version.
En ce sens, opter pour une LTS semble raisonnable, on utilisera les versions intermédiaires comme un moyen d’anticiper les migrations ultérieures à moindre coût.
C’est également le cas d’Ubuntu qui a une politique de release de LTS et de versions intermédiaires.
Retrouver de l’information
Il faut aussi mentionner qu’il ne suffit pas d’utiliser un composant Open Source, il faut également disposer de sources d’informations fiables. Et ce n’est pas simple.
- Les versions évoluent vite et il faut constamment se tenir au courant des modifications apportées. En espérant que les projets fournissent un Change Log adapté et des outils de migration, ce qui n’est pas toujours le cas…
- Les sociétés qui supportent des projets Open Source se font racheter et il devient difficile de trouver les informations originelles.
- Internet est vivant et il arrive que les liens sur les documentations ou sources que l’on conservait précieusement soient cassés (parfois parce que le nom de domaine n’est plus renouvelé). Il n’y a plus qu’à espérer qu’InternetArchives a conservé une copie (généralement partielle) des pages.
- Le contenu peut également disparaître. Toutes les entités gérant des projets Open Source ne proposent pas de récupérer les versions historiques.
Tout cela sans compter les IA qui aujourd’hui rendent difficilement accessibles la documentation ou les échanges sur les anciennes versions, puisque entraînées sur les dernières versions, couplé au fait que les moteurs de recherche ont aujourd’hui tendance à pousser en avant la production de ces IA.
Open Source is One Person
Pour finir, il faut quand même pointer le fait qu’un composant Open Source n’est généralement pas développé ni maintenu par une structure pléthorique. Ceci est parfaitement résumé par le dessin suivant :
Le projet ecosyste.ms[10] recense un grand nombre de projets Open Source et ses conclusions sont sans appel : sur 11,6 millions de projets analysés, 7 millions sont gérés par une seule personne :
Et si on analyse les projets avec plus de 1 million de téléchargements par mois, près de la moitié n’ont qu’un seul mainteneur :
Le résumé est donné sur la page “Open Source is one person”[11].
Exemple : Apache Log4j2
Prenons un premier exemple, le projet Apache Log4j2. Sur les deux dernières années :
- Il y a eu 1 313 commits,
- Dont 354 par des outils (Dependabot, ASF CI release Manager), soit 27% des commits,
- Le développeur le plus actif a effectué 484 modifications, soit 50% du total
- Le second développeur a effectué 291 modifications, soit 30% du total
- Le troisième développeur a effectué 65 modifications, soit 7% du total.
- Les trois premiers développeurs sont donc responsables de près de 88% des modifications
- Les 34 développeurs ayant participés au projet ont collectivement produit 119 modifications, 3,5 chacun en moyenne…
Exemple : Apache Tomcat
Apache Tomcat est certainement un des composants Open Source de la fondation Apache le plus utilisé. On pourrait se dire qu’il est maintenu par une grosse équipe :
- Il y a environ 100 contributeurs sur les 20 dernières années,
- Cela représente environ 25 000 commits,
- Le premier développeur, Mark Thomas, représente plus de 75% de ces modifications,
- Le second développeur, Rémy Maucherat, a contribué à hauteur de 10% des modifications,
- Le troisième développeur, Filip Hanik, a contribué à 4% des modifications,
- Ces trois développeurs sont donc responsables de 91% des contributions de ces 20 dernières années !
Exemple : LibXML2
LibXML2 est une (petite) librairie en C utilisée pour parser des documents XML. Elle est largement utilisée par des milliers de packages sous Linux. À la fin de l’année 2025, son unique mainteneur, Nick Wellnhofer, a décidé de se retirer du projet. Son dernier commit est le suivant :
On peut légitimement s’inquiéter de cette situation[12].
Open Source et développement - Partie 3 : Questions ouvertes : bugs, IA, souveraineté et autres
Bibliographie
[4] Hundred of NPM packages compromised
[5] CycloneDX
[6] SPDX
[7] Executive Order 14028
[8] Log4shell, c’est la faute à la fondation Apache ?
[9] L’histoire inédite de Log4j et Log4Shell
[10] Open source intelligence for your project
[11] Open Source is one person
[12] Libxml2 Becomes Officially Unmaintained After Maintainer Steps Down
