Klipper: open source senza comunità
Klipper è diventato lo standard per molti proprietari di stampanti, ma un articolo di Aleksey Sviridkin sul blog di Ænix pone una domanda scomoda: cosa succede se un progetto dipende da una sola persona? L'autore precisa che si tratta della sua opinione personale e la sostiene con argomenti piuttosto concreti.
La tesi principale: il codice di Klipper è eccellente, ma il progetto non è organizzato come un'organizzazione. Il file CONTRIBUTING.md cita solo Kevin O'Connor. I revisori sono quattro, ma solo lui può fare commit su master, quindi il bus factor è uno. Il tracker delle issue è di fatto chiuso: c'è una sola issue aperta che segnala che non viene più usato, e le discussioni sono passate a un forum dove attendono oltre 200 PR.
Come esempio, l'autore analizza la PR #6826, che aggiunge l'ascolto su un socket TCP oltre al socket Unix. Secondo la sua stima, basata sull'immagine Docker mkuf/moonraker, più di 400 persone userebbero questa funzione, ma non è arrivata nessuna risposta nel merito. Così le funzioni che non entrano nel core finiscono nei fork. Snapmaker ha modificato circa il 20% della base di codice per la sua stampante U1, mentre Creality e altri produttori distribuiscono versioni vecchie congelate.
L'autore sostiene che i fork costano caro ai produttori a causa di rebase e backport, e invita a contribuire al ramo principale ovunque il canale di accettazione funzioni. Per i fork commerciali propone fondazioni neutrali sul modello di OpenTofu, Valkey e OpenSearch.
Si può non essere d'accordo con gran parte del testo, ma chi sceglie una stampante e un firmware trae vantaggio dal sapere da quale ecosistema dipende. Per me, la lezione principale è che una licenza open source non garantisce uno sviluppo aperto.
Fonte: Habr (Ænix blog)
La tesi principale: il codice di Klipper è eccellente, ma il progetto non è organizzato come un'organizzazione. Il file CONTRIBUTING.md cita solo Kevin O'Connor. I revisori sono quattro, ma solo lui può fare commit su master, quindi il bus factor è uno. Il tracker delle issue è di fatto chiuso: c'è una sola issue aperta che segnala che non viene più usato, e le discussioni sono passate a un forum dove attendono oltre 200 PR.
Come esempio, l'autore analizza la PR #6826, che aggiunge l'ascolto su un socket TCP oltre al socket Unix. Secondo la sua stima, basata sull'immagine Docker mkuf/moonraker, più di 400 persone userebbero questa funzione, ma non è arrivata nessuna risposta nel merito. Così le funzioni che non entrano nel core finiscono nei fork. Snapmaker ha modificato circa il 20% della base di codice per la sua stampante U1, mentre Creality e altri produttori distribuiscono versioni vecchie congelate.
L'autore sostiene che i fork costano caro ai produttori a causa di rebase e backport, e invita a contribuire al ramo principale ovunque il canale di accettazione funzioni. Per i fork commerciali propone fondazioni neutrali sul modello di OpenTofu, Valkey e OpenSearch.
Si può non essere d'accordo con gran parte del testo, ma chi sceglie una stampante e un firmware trae vantaggio dal sapere da quale ecosistema dipende. Per me, la lezione principale è che una licenza open source non garantisce uno sviluppo aperto.
Fonte: Habr (Ænix blog)
Commenti 0
Lascia il primo commento, in qualsiasi lingua.
Accedi per commentare