Opensource on Zwindler's Reflection

Moins d'articles, plus de briques : mes nouveaux projets d'impression 3D

Fri, 17 Apr 2026 09:00:00 +0200

Mais il est passé où, zwindler ? 🏴‍☠️

Vous avez peut-être remarqué que j’ai été (relativement aux mois derniers) un peu plus silencieux ces derniers temps sur le blog. Pas de panique, je ne suis pas (encore) parti ouvrir un foodtruck. Non, la raison est plus prosaïque : je suis retombé à fond dans la conception de modèles 3D.

Si vous avez suivi mes aventures avec MicroStack, mon rack modulaire pour mini-PC, vous savez déjà que j’ai un faible pour la modélisation et l’impression 3D. Mais cette fois, le déclencheur a été inattendu : c’est le talk “Makers de Père en Fils” de Sylvain et Matthias Gougouzian à Touraine Tech 2026 qui m’a donné envie de retenter des trucs. Dans ce talk, ils montraient notamment comment ils utilisaient TinkerCAD pour leurs projets makers en famille.

Du coup, j’ai voulu essayer TinkerCAD, dont j’avais déjà entendu parler sans jamais prendre le temps de m’y mettre. Un premier modèle, puis deux, puis… vous connaissez la suite. Je suis parti dans une direction un peu différente de MicroStack et plus fun : les “““briques””” (vous savez, celles qui sont compatibles avec les petites briques danoises bien connues 😏) et les labyrinthes paramétriques.

Note : oui bien sûr j’aurais pu juste dire LEGO. Mais c’est justement la blague : LEGO est un terme interdit sur les stores de modèles 3D (pour des problèmes de propriété intellectuelle), donc tout le monde utilise “brick”.

Castle Mound : le projet qui a tout lancé

Mon premier modèle “briques” a été une plaque de base surélevée en forme de monticule. C’est celui qui m’a fait basculer dans le rabbit hole.

Des châteaux forts LEGO dans ma jeunesse, j’en ai fait 1000 (au moins). Mais il manquait toujours ce petit côté relief, que j’aurais pu faire mais qui aurait consommé trop de briques (j’essayais de faire LE PLUS GROS château possible avec ce que j’avais, chaque brique compte).

L’idée, c’est d’ajouter de la verticalité au lieu de tout poser à plat. Le modèle propose une pyramide tronquée centrale avec des escaliers intégrés sur les quatre côtés, parfaitement dimensionnés pour les minifigurines.

Je l’ai conçu à l’origine pour servir de fondation à un château médiéval (le look classique “motte castrale”), mais ça marche très bien pour surélever une maison, une tour de guet, un manoir hanté…

Le fil rouge : OpenSCAD et le paramétrique

TinkerCAD c’est bien, mais on reste dans la conception 3D “classique” (drag & drop de formes). Même si j’ai bien aimé l’outil pour sa prise en main immédiate, j’avais envie d’essayer autre chose. En parallèle, pour le travail, on m’incite beaucoup à tester la génération de code par IA, voire l’IA agentique.

Et c’est là que j’ai redécouvert OpenSCAD : “The Programmers Solid 3D CAD Modeller”. Le principe : on ne dessine pas, on code ses modèles 3D. Et du code, ça, un LLM sait en générer…

Je me suis donc demandé si un bon modèle serait capable de produire du SCAD exploitable. J’ai pas mal itéré jusqu’à trouver un workflow cohérent :

Rédiger une spec avec toutes les bonnes pratiques OpenSCAD (le gros du travail)
Faire générer un premier jet par le LLM
Générer des previews de l’objet depuis plusieurs angles
Noter les remarques et corrections
Itérer jusqu’à satisfaction
Générer le STL final pour l’impression

Au-delà du côté “rigolo” de la génération par IA, l’intérêt majeur c’est que ça produit des modèles paramétriques : des variables que tout un chacun peut modifier en fonction de son besoin, directement depuis le Customizer de MakerWorld, sans toucher une ligne de code.

Parametric Circular Maze Coaster : un sous-verre qui se résout

Premier projet (hors POC) avec OpenSCAD et probablement le plus nerdy de tous : un générateur de labyrinthes circulaires paramétriques, sous forme de sous-verre.

Le principe : chaque valeur de seed génère un labyrinthe unique. Vous pouvez imprimer un set identique pour votre table basse, ou changer le seed à chaque impression pour avoir une collection unique. Tout est paramétrique :

Diamètre et épaisseur : du porte-clés au labyrinthe mural géant
Complexité : ajustez le nombre d’anneaux concentriques pour aller de “facile” à “expert”
Dimensions des murs : jouez sur la hauteur et l’épaisseur pour différents effets visuels

Ce projet est sous licence CC-BY-NC, avec le code OpenSCAD en opensource. Si vous voulez l’adapter, le modifier, ou juste comprendre comment on génère un labyrinthe procéduralement… le code est là !

Pirate’s Cove : nostalgie des années 90

Une fois le Castle Mound terminé, et OpenSCAD pris en main avec le LLM, j’ai voulu pousser le concept plus loin. Si comme moi vous avez grandi avec les sets LEGO Pirates des années 90, vous allez comprendre immédiatement l’inspiration.

J’ai modélisé une baseplate 24x24 “Pirate’s Cove”, fortement inspirée de l’iconique 6267 Lagoon Lock-up et de 6265 Sabre Island.

C’est une île complète avec une transition entre la mer (bleu profond) et la plage (sable), soit en simple pause d’impression, soit en utilisant l’AMS pour un rendu multicolore.

Pour le Castle Mound, je m’étais basé sur des alignements de studs (tenons en bon français) faits par d’autres concepteurs 3D. Là, j’ai dû tout refaire moi-même et pas mal itérer pour trouver les bonnes valeurs : chaque stud doit être juste assez gros pour que les briques s’emboîtent bien, et ça dépend du filament et de sa calibration.

Le modèle fait 24x24 studs (192x192mm), soit une taille comparable aux sets des années 90. C’est le projet qui m’a pris le plus de temps (et de plaisir) de toute la série, et il y a un potentiel “infini” ici, car contrairement à la base surélevée pour le château, comme c’est du code, j’ai la possibilité de faire tout un archipel modulaire (c’était l’idée initiale derrière le projet).

Pas sûr que j’en arrive là cela dit, mais c’est une possibilité.

Brick Filament Swatch : organisez votre collection

Celui-ci, c’est le projet utilitaire de la série. Ça m’a permis d’expérimenter l’empilement (anti-studs) et l’impression de briques “creuses”. C’était intéressant à concevoir (anti-studs, orientation du filament pour les ponts, zone de transparence) mais probablement pas très intéressant à raconter.

Le lien pour les swatches de filament en forme de brique.

Et la suite ?

Promis, je n’abandonne pas le blog pour autant. J’ai toujours des articles tech en préparation (notamment un gros side project abandonné il y a 5 ans).

(Quel teasing incroyable)

101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s'améliore

Sun, 29 Mar 2026 18:00:00 +0200

Il bouge encore

Depuis la sortie de l’interface web du projet début février, le projet a continué à évoluer. Ajout de solutions manquantes, petites améliorations de l’UI, contributions externes, optimisations de performances… Bref, un bon petit mois bien rempli pour ce gros side project que j’aimerais faire grossir.

101-ways-to-deploy-kubernetes

Note : si vous n’avez pas suivi les épisodes précédents :

93 façons de déployer Kubernetes — le Google Sheet original
101 façons de déployer Kubernetes (v2) — passage sur GitHub
Une nouvelle UI pour explorer les 118+ solutions — l’appli Astro + Tailwind

7 nouvelles solutions

Le catalogue est passé de 118 à 125 solutions. Voici les ajouts depuis le dernier article :

Xen Orchestra - ajouté pendant un stream de Cuistops => Déploiement de clusters Kubernetes (MicroK8s) via les “recettes” de Xen Orchestra, la plateforme de management de Vates. Catégorie ManagementPlatform.
Charmed Kubernetes - suite à un commentaire sur LinkedIn, j’ai remplacé l’entrée “Juju” par Charmed Kubernetes, qui est le vrai nom du produit Canonical pour déployer Kubernetes via Juju.
kubeaver - découvert en scrollant bluesky sans but => un installateur Kubernetes offline/online avec une GUI, basé sur Kubespray et Ansible. Certifié CNCF conformance (pour ce que ça vaut…).
talos-bootstrap - script interactif de Cozystack pour bootstrapper des clusters Kubernetes sur Talos OS.
boot-to-talos - Outil de Cozystack (encore) qui convertit n’importe quel OS existant en Talos Linux, complètement depuis le userspace. Partiellement utilisé par Quentin dans un contexte que je ne peux révéler ;-)
TOPF - Talos Orchestrator by PostFinance, un CLI pour gérer des clusters Kubernetes basés sur Talos. Découvert sur le discord de Cuistops
Talhelper - Outil CLI pour créer des clusters Talos en mode GitOps, à partir d’un seul fichier YAML déclaratif. Je l’avais initialement mis de côté mais à y réfléchir, pourquoi pas le mettre.

On notera qu’au même titre que kubeadm et k3s, il y a beaucoup de solutions qui s’appuient sur Talos Linux. De mon point de vue, ça valide l’OS et ça confirme l’adoption croissante de cet OS immutable pour Kubernetes.

Refonte complète des tags

Un gros chantier a été la refonte de tous les tags du catalogue. Ils étaient incohérents : des noms d’outils utilisés comme tags (openshift, rancher…), des tags redondants (on-premise + self-hosted), des tags manquants ou parfois faux (par ex. “lightweight” sur des outils qui lancent des VMs).

J’ai nettoyé les tags de toutes les catégories :

Desktop : suppression des noms d’outils comme tags, ajout de gui pour Docker Desktop, Orbstack, Podman Desktop, Rancher Desktop
Selfhosted : suppression du tag redondant on-premise (29 solutions), ajout de tags pertinents (automation, edge, lightweight, bare-metal…)
ManagementPlatform : toutes les solutions ont maintenant 3 tags (multi-cloud, managed, gui, automation…)
KubernetesInKubernetes : correction de vcluster (virtualization → lightweight)

De nouveaux filtres dans l’UI

J’ai ajouté un filtre par nombre d’étoiles GitHub qui n’apparaît que quand le filtre “Open Source only” est activé. Plutôt pratique pour identifier rapidement les projets les plus populaires (> 100, > 1k, > 10k stars).

L’occasion aussi de réorganiser la barre de filtres : le sélecteur de statut (Active/Abandoned) est passé en dropdown compact, et le layout général a été retravaillé pour rester lisible même avec plus de filtres.

Dernier point, lorsque vous faites une recherche dans la barre principale, une variable vient d’ajouter à l’URL : pratique pour partager des solutions directement avec le lien.

Les contributions d’Antoine Caron (Slashgear)

Un grand merci à Antoine Caron (@slashgear) qui, au-delà de m’avoir aidé sur les performances et la sécurité de ce blog, a aussi contribué directement au projet 101 ways avec plusieurs PRs !

Hiérarchie des headings - les cartes utilisaient des <h3> sans <h2> dans la page. Antoine a corrigé ça pour une hiérarchie correcte (h1 → h2), ce qui améliore la navigation pour les lecteurs d’écran.
Accessibilité du champ de recherche - ajout d’un vrai <label> (en sr-only) et passage du type="text" à type="search" pour une meilleure sémantique.
Skip links - ajout de liens “skip to content” pour la navigation au clavier (WCAG 2.1, critère 2.4.1). Trois liens : vers la recherche, les filtres, et le contenu principal.

Amélioration des performances

En parlant de performances, le site s’est aussi amélioré côté PageSpeed. Voici un avant/après sur Lighthouse mobile :

De 82 à 99 en performances mobiles, avec du 100/100 en bonnes pratiques et SEO.

Ces gains viennent d’un ensemble de corrections, notamment la résolution du clipping des cartes au hover, un bug CSS assez vicieux lié à content-visibility: auto qui impliquait contain: paint et coupait le haut des cartes quand elles se soulevaient au survol. Antoine avait identifié le problème avec l’overflow-hidden, et Copilot a trouvé la cause racine dans le CSS containment.

Merci !

Un grand merci à tous ceux qui contribuent, que ce soit en me mentionnant les outils manquants, en soumettant des PRs, ou simplement en partageant le projet.

Merci spécial à Antoine Caron pour ses PRs sur l’accessibilité et la CI - c’est vraiment chouette de voir quelqu’un prendre le temps d’améliorer un projet open source qui n’est pas le sien. Et c’est d’autant plus appréciable qu’Antoine m’avait déjà aidé sur ce blog avec l’optimisation des images en AVIF et les security headers HTTP. 🙏

Le projet compte maintenant 125 solutions. Si vous en connaissez d’autres, n’hésitez pas à ouvrir une issue ou une PR (ou juste à me ping, en cas de flemme) !

👉 zwindler.github.io/101-ways-to-deploy-kubernetes

101 façons de déployer Kubernetes : une nouvelle UI pour explorer les 118+ solutions

Mon, 09 Feb 2026 18:00:00 +0200

De Google Sheet à une vraie application web

Vous vous souvenez peut-être de mes précédents articles sur ce projet : d’abord un simple Google Sheet avec 93 méthodes, puis un dépôt GitHub avec plus de 100 entrées.

Aujourd’hui, je peux présenter la dernière itération de ce projet : une vraie interface web pour explorer toutes ces solutions !

👉 101-ways-to-deploy-kubernetes

Pourquoi une UI ?

Le tableau Markdown sur GitHub, c’était déjà mieux que le Google Sheet pour la collaboration, mais à peine. Difficile à parser, difficile de rajouter des colonnes sans que ça devienne trop le bazar (c’était déjà le cas, ahah), et surtout, ultra MOCHE.

J’ai donc décidé de transformer tout ça en une interface moderne et intuitive, avec l’aide d’un LLM.

Stack technique : Astro + Tailwind

Pour ce projet, j’ai choisi une stack simple mais efficace :

Astro : un framework moderne qui génère des sites statiques ultra-rapides
Tailwind CSS : pour un design responsive sans prise de tête

Le résultat ? Un site léger, plutôt rapide, et qui fonctionne aussi bien sur desktop que sur mobile (même si l’expérience desktop reste plus confortable vu la quantité de données).

Les fonctionnalités

Des cartes pour chaque solution

Fini le tableau digne d’un dev back (non, pire, un ingé kube…) ! Chaque outil dispose maintenant de sa propre “carte” animée avec :

Le logo du projet
Le type de licence (OSS ou propriétaire)
Le nombre d’étoiles GitHub
Des liens directs vers le projet et des ressources tierces (blogs indépendants, REX, tutos…)

Des filtres puissants

Vous cherchez uniquement des solutions open source ? Des outils pour le développement local ? Des plateformes de management ?

Les filtres par catégories permettent de naviguer facilement :

Desktop (développement local)
Managed (offres cloud)
Self-hosted (automatisation on-premise)
Infra As Code
Kubernetes OS (systèmes spécialisés)
Management Platform
Kubernetes in Kubernetes

Et vous pouvez aussi filtrer par statut (actif, abandonné) ou afficher uniquement les solutions open source ou production ready.

Une barre de recherche

Vous savez ce que vous cherchez ? Tapez directement le nom dans la barre de recherche pour trouver la solution en un instant.

Des tags pour affiner

Au-delà des catégories, les tags permettent d’identifier rapidement les technologies sous-jacentes (kubeadm, k3s, k0s…).

Le saviez-vous ? Au moins 18 outils utilisent kubeadm !

En compilant toutes ces données, j’ai découvert quelque chose de fascinant : au moins 18 outils utilisent kubeadm comme backend pour déployer Kubernetes ! 🤯

Et ce n’est même pas en comptant les offres managées des cloud providers !

C’est typiquement le genre d’information qu’on peut maintenant visualiser instantanément grâce à cette nouvelle interface.

Un projet collaboratif

Le projet reste 100% open source et collaboratif. Les données sont toujours stockées dans le dépôt GitHub, et l’UI est générée automatiquement à partir de ces données (j’ai même rajouté des previews pour les PRs).

Il manque un outil ou un provider ? Vous avez repéré un bug ? N’hésitez pas à ouvrir une issue ou à soumettre une Pull Request !

Le projet compte maintenant 118 solutions (et je sais qu’il en manque certainement), avec pour chacune :

Des liens à jour
Le statut du projet
Des références externes (tutoriels, retours d’expérience…)

Essayez, commentez, partagez

Rendez-vous sur zwindler.github.io/101-ways-to-deploy-kubernetes pour explorer toutes ces solutions !

OK, c’est un infâme “call to action” comme on en voit sur tous les réseaux sociaux. Soit.

Cependant, je ne peux pas savoir si c’est utile (ou non) si vous ne le faites pas. Je peux le laisser en l’état (ça n’est pas génant en soit, j’ai plein d’autres side projects qui n’attendent que mon temps libre) ou le faire vivre, si ça vous plait / sert.

Et si vous trouvez ce projet utile, n’hésitez pas à :

Star le projet sur GitHub
Partager avec vos collègues de la communauté Cloud Native
Contribuer en ajoutant des outils manquants ou en corrigeant des erreurs

Merci d’avance ! 🙏

101 façons de déployer Kubernetes (v2) : maintenant sur Github avec plus de méthodes, plus de détails, plus de tout

Sun, 04 Jan 2026 10:00:00 +0200

Une nouvelle version, une nouvelle maison

Il y a quelques mois, je vous présentais mon tableau recensant 93 façons différentes de déployer Kubernetes, sur Google Sheets.

À la suite de la remarque de Ludovic Piot qui aurait aimé contribuer un ou deux outils manquants, j’ai pris un peu (beaucoup, en vrai) de temps pendant ces vacances pour déménager tout ça sur Github : 101-ways-to-deploy-kubernetes

Pourquoi sur un dépôt git plutôt que sur un Google Sheet comme au début ? Parce que ça me permet facilement de rendre ce projet vraiment collaboratif, notamment via des PRs (et surtout leur validation ou non).

Google Sheets, c’était bien pour commencer, quand c’était un outil perso pour m’aider à écrire mon livre, mais pour la collaboration, c’était pas viable.

Quoi de neuf dans cette v2 ?

Contributions facilitées

Le projet dispose maintenant d’un CONTRIBUTING.md qui explique comment participer.

Vous connaissez une solution qui n’est pas listée ? Vous avez repéré une erreur ? Un lien cassé ? Il vous suffit de faire une Pull Request !

De nombreuses nouvelles méthodes (j’ai pas compté mais probablement une douzaine)

Le projet est passé de 93 à plus de 100 méthodes ! J’ai continué mes explorations et ajouté une douzaine de nouvelles solutions, dont certaines que vous m’aviez suggérées.

Informations sur les licences

J’ai enrichi le tableau avec des détails sur les licences de chaque projet. C’est particulièrement important pour identifier d’un coup d’oeil si un produit est réellement open source ou si c’est une solution à licence propriétaire ou commerciale.

J’ai eu le débat avec Ludovic justement, qui voulait comprendre pourquoi je n’avais pas listé “MKE (Mirantis Kubernetes Engine)”. Je lui avais répondu à l’époque que c’était parce que je ne pouvais pas avoir accès à une version d’essai en tant que “random des Internets” sans passer par un commercial, mais l’argument n’était pas hyper solide.

Pour trouver une règle “unique” à indiquer dans le CONTRIBUTING.md, j’ai donc réintégré une partie des solutions que j’avais “censurées”.

While the heart of the cloud native ecosystem is open source, both open source and closed source (proprietary) tools are accepted in this list. What matters is whether the tool helps deploy Kubernetes clusters, not its licensing model.

Nombreuses références externes

J’ai fait un important travail sur la partie “références externes”. L’idée du répo, au delà de juste fournir une liste à la prévert, est de référencer des articles de tiers indiquant comment mettre en place ces solutions et bénéficier des retours d’expérience de la communauté.

Dans l’idée de rendre le projet plus international (ça sera tout aussi utile aux anglophones qu’aux petits frenchies de ma communauté), j’ai récupéré en priorité des liens en anglais, pour le plus de solutions possibles de cette liste. Il en reste encore qui n’en ont pas, mais ça progresse.

Note importante : au-delà de la documentation officielle (qui existe très souvent pour la grande majorité des projets), j’ai en priorité voulu recenser :

Des tutoriels de qualité de la communauté
Des articles de blog détaillés
Des retours d’expérience concrets

Un projet toujours sous CC BY-SA 4.0

Le contenu reste sous licence CC BY-SA 4.0 (Attribution - Share Alike).

Cela signifie que vous êtes libre de :

Partager : copier et redistribuer le contenu
Adapter : remixer, transformer et créer à partir de ce matériel

Sous les conditions suivantes :

Attribution : vous devez créditer le projet
Partage dans les mêmes conditions : si vous adaptez le contenu, vous devez le distribuer sous la même licence

Comment contribuer ?

C’est simple :

Forkez le dépôt 101-ways-to-deploy-kubernetes
Ajoutez ou modifiez le contenu (en suivant le format du tableau)
Soumettez une Pull Request

Lisez le CONTRIBUTING.md pour plus de détails sur le processus et les bonnes pratiques.

Toutes les contributions sont les bienvenues : nouvelles entrées, corrections, enrichissements, suggestions…

Et la suite ?

Le projet va continuer à évoluer au fil des découvertes et de vos contributions.

Je continue aussi à explorer de nouvelles solutions et à enrichir les informations existantes. Et qui sait, peut-être qu’on dépassera les 150 méthodes d’ici la fin de l’année ? 😄

C’est le moment où je fais mon influenceur et que je vous demande de ne pas hésiter à :

Star le projet sur Github si vous le trouvez utile ⭐⭐⭐
Contribuer en ajoutant vos découvertes
Partager autour de vous si vous le trouvez utile

Rendez-vous sur github.com/zwindler/101-ways-to-deploy-kubernetes !

Elastic redevient un ensemble de produits open source

Fri, 30 Aug 2024 10:00:00 +0200

Récap'

En 2021, j’avais écrit un article assez acide sur la décision d’Elastic (la société qui développe en grande partie les outils ElasticSearch, Kibana, Logstach, etc) de quitter de facto le monde de l’open source en remplaçant la licence par la SSPL, une licence inventée par MongoDB (qui n’est pas open source au sens de l’OSI). MongoDB avait fait le même move exact qu’ElasticSearch quelques années plus tôt.

J’avais été extrêmement critique face à ces changements, mais aussi l’attitude de Shay Bannon (patron d’Elastic), qui avait été extrêmement agressif, réduisaient toutes critiques (certaines légitimes à mon sens) à du simple FUD sans aucune argumentation sensée.

L’open source saute à L’Elastic avec la SSPL

Depuis, plusieurs autres entreprises ont fait le même move, celle qui a fait couler le plus d’encre (numérique surtout) cette année étant Hashicorp, juste avant le rachat par IBM (changement en BSL avec des conditions très restrictives).

AGPLv3, la revanche du retour de la vengeance

Très grosse news d’Elastic hier.

Shay Bannon annonce qu’Elastic fait le chemin inverse et réintroduit une vraie licence open source (au sens de l’OSI), l’AGPLv3.

www.elastic.co/fr/blog - Elasticsearch is open source, again

L’AGPLv3 est une très bonne licence, qui est certes restrictive, car elle oblige l’utilisateur à reverser énormément (ce qui peut bloquer certaines entreprises, mais c’est peut-être pour le mieux ?) mais est parfaitement conforme en tant que “vrai” licence open source.

Pour ceux qui veulent plus de détails, je vous conseille l’excellent tldrLegal

tl;drLegal - GNU Affero General Public License v3 (AGPL-3.0)

Mon avis

Même si Shay Bannon s’en défend, je ne peux m’empêcher d’y voir un début de mea culpa. Peut-être que la cible initiale du changement de licence était effectivement Amazon, mais contrairement à ce que Shay disait avant aujourd’hui, ElasticSearch n’était plus open source (il le reconnait aujourd’hui).

Et ça a blessé / mis en colère une partie des utilisateurs ET des contributeurs, au point qu’une partie, pourtant pas concurrents d’Elastic, ont changé de crèmerie et sont partis soutenir OpenSearch d’Amazon (!!!).

Open source is in my DNA. It is in Elastic DNA. Being able to call Elasticsearch Open Source again is pure joy.

Revenir sur cette décision était donc un moyen de dire “ok, on est quand même content d’avoir vos contributions, revenez”. Cependant, un lecteur me disait à juste titre que la confiance se perd plus facilement qu’elle se (re)gagne.

Cela étant dit, si la communauté parvient à “pardonner” à Elastic, on peut aussi voir ce move comme un énième f**k à Amazon, qui a investi sur son fork et qui verra (peut-être ?) des contributeurs revenir côté Elastic.

Tout ça n’est que pure spéculation de ma part, bien entendu, et les prochains mois vont être déterminant pour jauger de l’efficacité ou non de ce revirement de situation.

Quoi qu’il en soit, je ne peux aujourd’hui que féliciter Elastic pour ce move inverse, à contre-courant des récentes modifications de licences dans l’OSS. Bravo :)

L’open source saute à L’Elastic avec la SSPL

Sat, 23 Jan 2021 21:32:48 +0000

[Mise à jour : 30 aout 2024] : Shay Bannon est revenu sur sa décision, Elastic est de nouveau Open source au sens de l’OSI. Voir ce petit article de blog pour plus de détails :

SSPL, le retour de la vengeance

Depuis 2018 et le passage de MongoDB d’AGPLv3 en SSPL, j’ai envie d’écrire un article là-dessus. Ou alors d’en parler dans mon talk « Le logiciel libre a-t-il de beaux jours devant lui » que j’ai déjà donné en conf à Bordeaux et à Nantes. Mais je n’ai jamais pris le temps de le faire…

Alors forcément, quand Elastic (la société qui édite la « suite Elastic » que vous connaissez très probablement pour les outils ElasticSearch et Kibana, entre autres) a décidé d’emboiter le pas à Mongo et d’embrasser elle aussi la SSPL, c’était l’occasion rêvée d’en reparler.

C’est un sujet super complexe et si vous avez écumé le web ces derniers temps, vous aurez peut-être remarqué que personne n’est vraiment d’accord sur comment interpréter ce changement de licence par Elastic.

Grosso modo, il y a un groupe majoritaire qui dit « AWS, c’est des méchants ». Mais si on gratte un peu, vous verrez que c’est un peu plus subtil.

J’ai donc écrit cet article dans l’idée de donner une vue plus complète (et documentée par des gens bien plus talentueux que moi) de la question.

[Edit] Je ne nie pas à Elastic ou MongoDB le fait qu’ils aient le droit de changer de licence. Ils peuvent le faire car ils font signer à tous les contributeurs des CLA, qui demande à l’auteur du patch d’abandonner une partie de ses droits, notamment dans ce genre de cas.[/Edit]

[Edit2]On m’a fait remarqué que, comme je parle très peu d’AWS, ça laisse penser que j’en pense du bien dans cette affaire. Ce n’est pas le cas. Je pense que l’attitude d’AWS n’est pas clean. Mais j’ai trouvé que tapper uniquement sur AWS était trop simpliste et que Shay Banon nous prennait un peu trop de pour des sots.[/Edit]

Les licences

Les licences, c’est un sujet qui me touche dans mon travail, notamment celles de MongoDB et d’Elastic puisque je travaille avec. Ça fait des années que je bosse dans des contextes où les licences de logiciels libres/open source (plus généralement) sont un sujet de discussions animées.

Souvent, la crainte des licences, c’est du bête FUD. Une peur un peu vague entretenue par les vendeurs de logiciels privateurs et repartagée par ceux qui en ont été biberonnés depuis des années. Et dans le monde des PME qui tournent en full Microsoft / Oracle / whatever, c’est encore très très ancré.

Il y a moins d’un mois, dans une discussion qui n’avaient rien à voir (le cloud Gaia X), voilà le genre de tweets qu’on pouvait trouver :

Je vais pouvoir encore donner mon talk « Le logiciel libre a-t-il de beaux jours devant lui » un paquet de fois, je pense.

Mais parfois les craintes peuvent être moins illégitimes.

Back to 2018

On rembobine. En 2018, MongoDB, la société qui s’occupe majoritairement du logiciel de base de données NoSQL MongoDB est en conflit avec AWS.

MongoDB reproche à AWS de distribuer une version SaaS de son logiciel, d’y faire des améliorations, mais de ne pas reverser les modifications dans le code de MongoDB, comme la licence AGPL l’y oblige.

(Ce qui n’est pas à exclure, ne soyons pas Candides…)

En creux, mais sans jamais vraiment le dire, MongoDB reproche surtout à AWS de lui piquer son business, mais c’est plus dur de fédérer des gens autour de ce point précis.

Pour fédérer les gens, mieux vaut dire que big-AWS, c’est des gros vilains qui ne respectent pas l’AGPL (une faute légale), plutôt que d’expliquer que Mongo perd du business parce qu’AWS se sert de l’open source pour faire du blé sans pour autant contribuer à l’effort de développement du logiciel (une faute morale).

South Park : « Ils nous volent notre travail »

Que décide de faire MongoDB ?

MongoDB décide de sortir une feuille de papier, de prendre l’AGPL v3, de rayer la section 13 et d’écrire tout ce qui lui passe par la tête. Et ça donne ça :

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

J’ai surligné les deux passages que je pense importants.

Mais c’est incompréhensible ton truc !

Oui, c’est bien le problème, c’est incompréhensible. Heureusement, l’article de Matthew Garrett, posté en octobre 2018, explique bien ce qui est problématique (en anglais).

Initial thoughts on MongoDB’s new Server Side Public License

Le problème principal est que cette section 13 est volontairement floue et extrêmement large, dans le but avoué de faire la nique à tous les éditeurs SaaS. Grosso modo, elle oblige quiconque « offre un service dont la valeur dérive entièrement ou principalement de la valeur du programme à open source tout le code de son application en SSPL, mais également le code de tout ce qui permet de faire fonctionner le service ».

Déjà, c’est quoi « majoritairement » ? J’ai bossé avec des logiciels qu’on vendait en SaaS et qui utilisaient extensivement MongoDB comme base de données NoSQL.

Si je lis la FAQ de MongoDB, je ne suis pas concerné. Mais une FAQ, ce n’est pas une licence. La FAQ n’a aucune portée dans un tribunal.

Oui mais Elastic et Mongo, c’est les gentils; ils veulent juste se défendre contre AWS même si leur licence est floue

Toi, t’as jamais subi un audit Oracle

Ensuite, si on interprète littéralement, cela ne touche donc pas juste votre code. Ca concerne tout ce qui permet de faire tourner votre service. Et si je suis jusqu’auboutiste ça va jusqu’au microcode du CPU, en passant par l’OS et tout ce qui contient du code entre les deux.

Tout ça, ce n’est pas moi qui le dit.

C’est VM (Vicky) Brasseur (ancienne VP à Open Source Initiative), dans un article passionnant qui vient de sortir peu après l’annonce du passage en SSPL d’Elastic. Si vous avez un peu de temps, je vous invite à lire son avis (en anglais aussi du coup).

By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. It’s not a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal.

Elasticsearch and Kibana are now business risks

SS - PL - on en - veut - pas !

N’hésitez pas à m’appeler si vous avez besoin de moi pour vos sloggans de manif’, I’m on fire

Au-delà de ces deux individus, ça a beaucoup déplu quand la SSPL est sortie.

Plusieurs concurrents open source ont dit que c’était cracra, notamment Scylla DB, une autre base de données AGPL. Vous allez me dire « c’est des concurrents, c’est normal ». Mais leur point de vue est bien argumenté et très bien construit, notamment sur le fait que contrairement à ce qu’Elastic tente de faire croire dans son blogpost, ça ne concerne PAS QUE les cloud providers de SaaS mais bien tous les utilisateurs (sauf ceux qui payent)

Here’s where things get complicated. Let’s imagine the usage of a hypothetical company like a Twilio or a PubNub (these are just presented for example, this is not to assert whether they do or ever have used MongoDB). Imagine they use MongoDB and provide APIs on top of their core service. Would this be considered a fair usage? They do provide a service and make money by using database APIs and offering additional/different APIs on top of it. At what point is the implementation far enough from the original?

Percona, une entreprise tierce d’expertise en bases de données donne un avis intéressant également sur la façon dont MongoDB tue la compétition avec la SSPL :

SSPL requires anyone who wants to offer MongoDB as a DBaaS to either release all surrounding infrastructure as SSPL or get a commercial license from MongoDB. The first is impractical for cloud vendors as licensing MongoDB directly allows MongoDB Inc. to exercise significant control over end-user pricing, meaning there is no true competition.

Why is MongoDB’s SSPL Bad For You?

C’est d’ailleurs dans cet article que j’ai appris que le CEO avait dit dans une interview texto qu’ils n’avaient pas vraiment Open sourcé mongoDB par conviction mais juste pour mettre en place un business Freemium.

“MongoDB was built by MongoDB. There was no prior art. We didn’t open source it for help; we open sourced it as a freemium strategy”

Dev Ittycheria (lien mort, j’utilise Internet Archive)

Ce qui renforce ma conviction qu’ils ont surtout « le seum » qu’AWS leur pique leurs clients plutôt qu’un problème de non-respect de l’AGPL…

Devant la nocivité de cette licence et les risques légaux (licence floue) induits, Debian et Redhat ont retirés tous les produits en SSPL de leurs distributions :

Red Hat drops MongoDB over concerns related to its Server Side Public License (SSPL) (lien mort)

To consider the SSPL to be “Free” or “Open Source” causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk

Fedora

The SSPL is clearly not in the spirit of the DFSG (Debian’s free software guidelines), let alone complimentary to the Debian’s goals of promoting software or user freedom”

Debian

Last, but not least, le passage de mongoDB de l’AGPL à la SSPL a été mal vécu par de nombreux contributeurs, qui ont vu leurs contributions passées intégrées dans une licence fermée qui baffouent leur conviction.

Et Elastic dans tout ça ?

En 2021, Elastic dit avoir les mêmes problèmes que MongoDB. AWS utilise le soft pour vendre un service SaaS, l’améliorer mais sans reverser ces améliorations.

Dans une série de tweet, Shay Banon (le PDG d’Elastic) fait une liste à la prévert de toutes les choses « NOT OK » qu’AWS a faite. Certaines sont clairement abusives, notamment le fait d’utiliser Elastic dans le nom de ses produits alors qu’il s’agit d’une marque déposée, et le fait d’intégrer du code propriétaire sans autorisation. D’autres, me font lever les yeux au ciel…

Tu as déposé un brevet sur tes features ou bien ?

Mais une fois encore, ce qui est reproché sans jamais vraiment le dire, c’est qu’Amazon fasse de l’argent sur le dos d’ElasticStack, sans pour autant contribuer significativement à son développement.

[…] Amazon Elasticsearch Service […] profit from our open source software without contributing back

www.elastic.co/fr/blog/licensing-change

Je rappelle qu’Elastic était sous licence Apache, bien moins restrictive que l’AGPL de MongoDB. Se plaindre qu’AWS ne contribue pas à la hauteur des gains qu’ils engrenge est encore plus difficile, selon moi, à défendre, quand on a délibérément choisi une licence dite « permissive ». D’autant qu’Amazon a poussé quelques patchs (peu si on en crois leur blog post, mais pas 0).

Et je ne parle même pas des gens qui, comme pour MongoDB, se retrouve à avoir contribué et donné du temps pour un logiciel qui décide d’abandonner l’open source.

Elastic has spit in the face of every single one of 1,573 contributors, and everyone who gave Elastic their trust, loyalty, and patronage. This is an Oracle-level move.

Elasticsearch does not belong to Elastic

Car notez que le blog post à propos du changement de licence n’utilise plus le terme open source pour qualifier le futur produit sous SSPL. Shay Banon sait très bien que cette licence n’est pas une licence Open Source approuvée par l’OSI (et ne le sera jamais).

The license du jour is the Server Side Public License. This license was submitted to the Open Source Initiative for approval but later withdrawn by the license steward when it became clear that the license would not be approved.

Open Source Initiative - The SSPL is Not an Open Source License

Conclusion

Dans l’article Doubling down on open, Part II (sic), Shay Banon explique qu’il sait que ses concurrents risquent de le basher sur ce choix de la SSPL et qu’ils vont répandre du méchant FUD

We expect that a few of our competitors will attempt to spread all kinds of FUD around this change. Let me be clear to any naysayers. We believe deeply in the principles of free and open products, and of transparency with the community. Our track record speaks to this commitment, and we will continue to build upon it.

Mais pas besoin de naysayers. Le FUD, il le répand lui même en choisissant une licence largement décriée depuis sa création en 2018, car mal écrite et volontairement floue (cf les interrogations de VM Vasseur et de Matthew Garrett) !

Bref. Elastic m’a vraiment énervé. Autant que MongoDB m’avait énervé.

En voulant se battre contre Amazon, la seule chose qu’ils vont réussir à faire avec leur licence moisie, c’est entretenir un flou, une angoisse, auprès de leurs clients et des avocats en entreprise.

En gros, du FUD. Ce contre quoi on se bat depuis des années.

Amazon, pendant se temps, s’est fendue d’un blog post qui fleure bon le « LOL, RAF ».

Comme prévu, ils ont toute la puissance de feu nécessaire pour faire un fork, qui sera probablement de qualité et on se retrouve juste avec une communauté scindée en deux.

GG Elastic.

Les IBM, Oracle et autres vendeurs de FUD doivent bien se marrer.

Bonus

[Edit3]Le point de vue d’un avocat qui pense le contraire d’une partie de ce que j’écris et surtout des gens que j’ai cité dans cet article : writing.kemitchell.com/2021/01/20/Righteous-Expedient-Wrong.html [/Edit]

Pour aller plus loin, une TRES bonne lecture l’Open Source et les gens qui en font un business. A lire absolument (en anglais aussi)

Open source confronts its midlife crisis

Des débats passionnants à ce sujet de cette news sur Ycombinator

news.ycombinator.com/item?id=25776657