Klipper: código abierto sin comunidad

Klipper se ha convertido en el estándar para muchos propietarios de impresoras, pero un artículo de Aleksey Sviridkin en el blog de Ænix plantea una pregunta incómoda: ¿qué pasa si un proyecto depende de una sola persona? El autor aclara que se trata de su opinión personal y la respalda con argumentos bastante concretos.

La tesis principal: el código de Klipper es excelente, pero el proyecto no está organizado como una organización. En CONTRIBUTING.md solo aparece Kevin O'Connor. Hay cuatro revisores, pero solo él tiene derecho a hacer commit en master, así que el factor de autobús es uno. El gestor de incidencias está prácticamente cerrado: hay una única incidencia abierta que indica que ya no se usa, y las discusiones se han trasladado a un foro donde esperan más de 200 PR.

Como ejemplo, el autor analiza la PR #6826, que añade la escucha en un socket TCP además del socket Unix. Según su estimación, basada en la imagen Docker de mkuf/moonraker, más de 400 personas necesitarían esa función, pero no hubo una respuesta de fondo. Por eso, las funciones que no están en el núcleo acaban en forks. Snapmaker cambió alrededor del 20 % de la base de código para su impresora U1, y Creality y otros fabricantes distribuyen versiones antiguas congeladas.

El autor sostiene que los forks cuestan caro a los fabricantes por los rebases y los backports, y pide aportar a la rama principal siempre que el canal de entrada funcione. Para los forks comerciales propone fundaciones neutrales, siguiendo el modelo de OpenTofu, Valkey y OpenSearch.

Se puede no estar de acuerdo con buena parte del texto, pero quien elige impresora y firmware se beneficia de saber de qué ecosistema depende. Para mí, la conclusión principal es que una licencia abierta no garantiza un desarrollo abierto.

Fuente: Habr (blog de Ænix)