Partie 3 sur 8. La partie 2 a exposé ce que la dépendance vous coûte.
Ce que couvre ce billet
- Les années où l’open source a été combattu.
- Pourquoi le combat s’est arrêté.
- Qui maintient le logiciel aujourd’hui.
- Ce qui est arrivé quand les créateurs ont voulu faire payer.
- Ce qui arrive aux entreprises après un rachat.
- Ce que ça veut dire pour vous.
Les années où l’open source a été combattu
L’open source est un logiciel dont le code peut être lu, utilisé et modifié par quiconque.
C’est ordinaire aujourd’hui. Pendant environ 15 ans, ç’a été traité comme une menace.
En octobre 1998, un mémo interne de Microsoft a fuité. Eric Raymond l’a publié avec des notes, et il est devenu connu sous le nom de documents d’Halloween.
Le mémo était honnête sur la qualité de l’open source. Il qualifiait de remarquable la façon dont des milliers de gens y travaillent ensemble.
Puis il exposait quoi faire à ce sujet. Une ligne explique beaucoup :
By extending these protocols and developing new protocols, we can deny OSS projects entry into the market.
Un protocole est une façon convenue pour 2 systèmes de se parler.
Le plan n’était donc pas de bâtir un meilleur produit. Le plan était de changer les jonctions entre les produits, pour qu’un concurrent ne puisse pas être inséré.
Plusieurs autres étapes ont suivi au cours des 10 années suivantes.
En 2003, une entreprise appelée SCO a prétendu que Linux contenait du code qu’elle possédait. L’affaire a traîné des années et SCO n’a pas gagné. Pendant qu’elle courait, beaucoup d’organisations n’étaient pas sûres que Linux soit sûr à adopter.
Microsoft a aussi signé des accords de brevets avec des fabricants de téléphones mobiles. Pendant plusieurs années, il a touché un paiement sur chaque combiné vendu sous Android, un système d’exploitation qu’il n’avait pas écrit.
En 2008, les formats de document de Microsoft ont été approuvés comme norme internationale. Plusieurs organismes de normalisation nationaux ont contesté la façon dont ç’a été géré.
L’Europe a repoussé une partie de tout ça. La Commission européenne a infligé à Microsoft une amende de 497 millions d’euros en 2004 au sujet d’informations dont les concurrents avaient besoin pour travailler avec ses produits.
Elle a de nouveau infligé à l’entreprise une amende de 561 millions d’euros en 2013, parce qu’un remède convenu n’avait pas été mis en place.
Cette seconde amende mérite un instant. Le problème n’était pas nouveau. La solution convenue n’avait simplement pas été appliquée.
Pourquoi le combat s’est arrêté
Il s’est arrêté vers 2014, parce qu’il n’avait pas marché.
Linux était devenu le logiciel sur lequel tourne la plupart des serveurs. Il fait aussi tourner la plupart des services de cloud et la plupart des téléphones mobiles.
Vous ne pouvez pas retirer quelque chose par les tribunaux une fois que tout est bâti dessus.
Alors l’approche a fait volte-face.
Microsoft a rejoint la Linux Foundation. Il a publié certains de ses propres outils en open source. En 2018, il a racheté GitHub, le site où s’écrit une grande partie de l’open source du monde.
Amazon et Google ont bâti de très grandes affaires sur l’open source, et les 3 entreprises y remettent maintenant beaucoup de travail.
Ce travail est réel, et le logiciel s’en porte mieux. Il serait bête de prétendre le contraire.
Mais 1 chose n’a pas changé.
Les entreprises qui ont autrefois tenté de freiner l’open source comptent maintenant parmi ses plus gros financeurs. Elles sont aussi toujours les plus grandes entreprises du marché.
L’open source a gagné l’argument technique. Il n’a pas changé qui tient la main la plus forte.
Qui maintient le logiciel aujourd’hui
Voici le passage qui surprend les gens hors du logiciel.
Une grande partie de l’open source très utilisé est maintenue par de très petites équipes. Une partie par 1 seule personne, sur son temps libre, pour rien.
Ces mêmes pièces siègent ensuite à l’intérieur de produits vendus par de très grandes entreprises.
En décembre 2021, une faille est apparue dans Log4j, un petit outil que les programmes Java utilisent pour consigner ce qu’ils font.
La faille laissait des attaquants exécuter leur propre code sur les systèmes touchés. Elle a frappé un nombre énorme d’organisations d’un coup. Le National Cyber Security Centre du Royaume-Uni a publié des consignes à son sujet.
L’outil était maintenu par un petit groupe de bénévoles.
La leçon n’est pas que l’open source est risqué. La plus grande partie est très bonne, et ouverte à l’inspection d’une façon que le logiciel fermé n’est jamais.
La leçon porte sur le fait de payer les choses. Le travail partagé sur lequel beaucoup d’affaires s’appuient a besoin d’un financement, et souvent ne l’obtient pas.
Celui-là est réparable, et certaines organisations le réparent. Payer un mainteneur, ou financer une fondation, est en général un tout petit coût à côté de ce que le logiciel vous fait économiser.
Ce qui est arrivé quand les créateurs ont voulu faire payer
Certaines entreprises font de l’open source et vendent un service payant autour. Ç’a assez bien marché un bon moment.
C’est devenu plus difficile quand les fournisseurs de cloud ont commencé à offrir le même logiciel comme un service à eux.
Le fournisseur prenait les revenus. L’entreprise qui avait écrit le logiciel, non.
Plusieurs d’entre elles ont répondu en changeant leur licence, pour que d’autres ne puissent pas offrir leur logiciel comme un service concurrent.
- MongoDB a changé sa licence en 2018.
- Elastic a suivi en 2021.
- HashiCorp a changé en 2023.
- Redis a changé en 2024.
L’Open Source Initiative fixe la définition acceptée de l’open source. Elle a jugé que 1 de ces nouvelles licences n’y répondait pas.
Beaucoup de distributions Linux ont ensuite laissé tomber le logiciel touché.
La communauté au sens large a pris des copies des dernières versions ouvertes et les a poursuivies séparément. Une copie comme celle-là s’appelle un fork.
- OpenSearch poursuit le code Elasticsearch antérieur.
- OpenTofu poursuit le code Terraform antérieur.
- Valkey poursuit le code Redis antérieur.
Elastic et Redis sont depuis toutes deux revenues à des licences ouvertes.
Il vaut la peine de regarder comment ça s’est terminé, parce que personne d’impliqué n’a obtenu ce qu’il cherchait.
Une entreprise a bâti un logiciel utile. Une plus grande entreprise en a tiré plus que le créateur. Le créateur a restreint la licence pour survivre. La communauté a objecté, à juste titre, que ce n’était plus de l’open source. Un fork est apparu, souvent soutenu par les plus grandes entreprises.
Au bout du compte, le logiciel est encore libre d’usage. Les forks sont surtout pilotés par les plus gros acteurs. L’affaire qui a payé le travail d’origine est plus faible qu’à son départ.
Ce qui arrive aux entreprises après un rachat
La deuxième façon dont la valeur quitte une affaire n’a rien à voir avec les licences de logiciel.
Elle porte sur la façon dont une entreprise se fait racheter.
Voici le schéma, simplement.
Un acheteur emprunte la plus grande partie du prix d’achat. Le prêt est ensuite garanti sur l’entreprise rachetée. L’entreprise finit donc par porter la dette qui a servi à l’acheter.
L’acheteur peut ensuite vendre les bâtiments de l’entreprise et les relouer. L’argent levé peut être versé aux nouveaux propriétaires. L’entreprise paie maintenant un loyer sur des locaux qu’elle possédait avant.
Les coûts qui n’apparaissent pas cette année se font couper. Ça veut d’habitude dire la maintenance, les effectifs, la recherche et le développement de produits.
Puis l’entreprise est revendue.
La Banque d’Angleterre a examiné le côté stabilité financière de tout ça. Son étude sur le private equity note qu’un fort endettement sur les rachats rend ces entreprises plus susceptibles de faire défaut, et expose leurs prêteurs à des pertes. Elle a continué à surveiller le secteur depuis.
Tous les rachats ne fonctionnent pas ainsi, et beaucoup de propriétaires investissent plutôt qu’ils ne dépouillent. C’est un schéma à reconnaître, pas une description de tous les acheteurs.
Mais là où ça arrive, l’issue est la même à chaque fois.
L’affaire marchait en général très bien. Ce qui ne marchait pas, c’était l’affaire plus la dette contractée pour l’acheter.
Le même schéma dans le logiciel
Ça a atteint le logiciel il y a quelques années.
L’actif que l’on exploite n’est pas un bâtiment. Ce sont les clients qui ne peuvent pas facilement partir.
Un produit mûr avec des clients de longue date peut être retarifé. Ces clients ne peuvent pas bouger vite, et à ce titre la plupart paient.
En même temps, les dépenses d’ingénierie peuvent être coupées. Ça met des années à se voir, et d’ici là la vente est passée.
La partie 2 a couvert à quoi ça ressemblait pour les clients de VMware.
Il y a aussi une version financée par des investisseurs plutôt que par la dette. Elle a été décrite assez souvent pour mériter un nom : l’enshittification, un mot employé par l’écrivain canadien Cory Doctorow à partir de 2022.
Elle se déroule en 3 étapes.
- Le service est vendu en dessous de ce qu’il coûte à faire tourner, payé par des investisseurs. Il est bon marché et bon, alors les gens y viennent.
- Une fois que les gens ne peuvent plus facilement partir, il est modifié pour convenir aux clients professionnels payants à la place.
- Une fois les deux côtés engagés, les conditions changent encore pour augmenter le bénéfice.
L’étape 1 est celle qui compte pour cette série.
Une entreprise qui vend en dessous de son coût pendant des années ne gagne pas parce qu’elle est meilleure. Elle est financée pour prendre le marché.
Les petites affaires qui doivent couvrir leurs propres coûts ne peuvent pas égaler ce prix. Beaucoup ferment.
Quand les prix grimpent ensuite vers quelque chose de tenable, le choix qui existait a souvent disparu.
Ce que ça veut dire pour vous
Deux choses pratiques ressortent de ça, et les deux sont assez faciles à faire.
Vérifiez combien de gens maintiennent vos dépendances.
Regardez les outils sans lesquels vos systèmes ne pourraient pas tourner. Découvrez combien de gens maintiennent activement chacun.
Si la réponse est 1 ou 2, ça vaut la peine de le savoir. Vous voudrez peut-être financer ce travail, garder votre propre copie du code source, ou prévoir ce que vous feriez s’il s’arrêtait.
Surveillez qui possède vos fournisseurs.
Vos conditions suivent le propriétaire, pas le produit. Un changement de propriétaire peut déplacer votre renouvellement plus que tout changement dans le logiciel.
Quand vous signez, vérifiez ce que vous gardez si vous arrêtez de payer. Vérifiez si vous pouvez encore faire tourner ce que vous avez déjà installé, et si vous obtenez encore les mises à jour de sécurité.
Ni l’un ni l’autre ne prend longtemps. Les deux sont bien plus faciles avant un renouvellement que pendant.
La partie 4 regarde ce que les tribunaux et les régulateurs ont déjà décidé.
Première publication : 2026-08-25. Dernière mise à jour : 2026-08-25.