Klipper : l'open source sans communauté
Klipper est devenu la norme pour de nombreux propriétaires d'imprimantes, mais un article d'Aleksey Sviridkin sur le blog Ænix pose une question dérangeante : que se passe-t-il si un projet repose sur une seule personne ? L'auteur précise qu'il s'agit de son opinion personnelle et appuie son propos sur des arguments assez concrets.
La thèse principale : le code de Klipper est excellent, mais le projet n'est pas organisé comme une organisation. Le fichier CONTRIBUTING.md ne cite que Kevin O'Connor. Il y a quatre relecteurs, mais seul lui peut committer sur master, si bien que le facteur bus est de un. Le gestionnaire de tickets est pratiquement fermé : un seul ticket reste ouvert et indique qu'il n'est plus utilisé, et les discussions se sont déplacées vers un forum où plus de 200 PR attendent.
L'auteur prend l'exemple de la PR n° 6826, qui ajoute l'écoute sur un socket TCP en plus du socket Unix. Selon son estimation, basée sur l'image Docker mkuf/moonraker, plus de 400 personnes utiliseraient cette fonction, mais aucune réponse de fond n'est venue. Résultat, les fonctions absentes du noyau finissent dans des forks. Snapmaker a modifié environ 20 % de la base de code pour son imprimante U1, et Creality ainsi que d'autres constructeurs livrent d'anciennes versions figées.
L'auteur estime que les forks coûtent cher aux constructeurs à cause des rebases et des backports, et appelle à contribuer à la branche principale là où le canal d'intégration fonctionne. Pour les forks commerciaux, il propose des fondations neutres sur le modèle d'OpenTofu, Valkey et OpenSearch.
On peut ne pas être d'accord avec beaucoup de ce qui est dit, mais pour qui choisit une imprimante et un firmware, il est utile de savoir sur quel écosystème on s'appuie. Pour moi, la leçon principale est qu'une licence open source ne garantit pas un développement ouvert.
Source : Habr (Ænix blog)
La thèse principale : le code de Klipper est excellent, mais le projet n'est pas organisé comme une organisation. Le fichier CONTRIBUTING.md ne cite que Kevin O'Connor. Il y a quatre relecteurs, mais seul lui peut committer sur master, si bien que le facteur bus est de un. Le gestionnaire de tickets est pratiquement fermé : un seul ticket reste ouvert et indique qu'il n'est plus utilisé, et les discussions se sont déplacées vers un forum où plus de 200 PR attendent.
L'auteur prend l'exemple de la PR n° 6826, qui ajoute l'écoute sur un socket TCP en plus du socket Unix. Selon son estimation, basée sur l'image Docker mkuf/moonraker, plus de 400 personnes utiliseraient cette fonction, mais aucune réponse de fond n'est venue. Résultat, les fonctions absentes du noyau finissent dans des forks. Snapmaker a modifié environ 20 % de la base de code pour son imprimante U1, et Creality ainsi que d'autres constructeurs livrent d'anciennes versions figées.
L'auteur estime que les forks coûtent cher aux constructeurs à cause des rebases et des backports, et appelle à contribuer à la branche principale là où le canal d'intégration fonctionne. Pour les forks commerciaux, il propose des fondations neutres sur le modèle d'OpenTofu, Valkey et OpenSearch.
On peut ne pas être d'accord avec beaucoup de ce qui est dit, mais pour qui choisit une imprimante et un firmware, il est utile de savoir sur quel écosystème on s'appuie. Pour moi, la leçon principale est qu'une licence open source ne garantit pas un développement ouvert.
Source : Habr (Ænix blog)
Commentaires 0
Laissez le premier commentaire, dans la langue de votre choix.
Connectez-vous pour commenter