Klipper: código aberto sem comunidade
O Klipper se tornou o padrão para muitos donos de impressoras, mas um artigo de Aleksey Sviridkin no blog da Ænix faz uma pergunta incômoda: o que acontece se um projeto depende de uma única pessoa? O autor deixa claro que se trata de sua opinião pessoal e sustenta isso com argumentos bastante concretos.
A tese principal: o código do Klipper é excelente, mas o projeto não é organizado como uma organização. O CONTRIBUTING.md cita apenas Kevin O'Connor. Há quatro revisores, mas só ele tem permissão para fazer commit na master, então o fator de ônibus é um. O rastreador de problemas está praticamente fechado: resta uma única issue aberta dizendo que ele não é mais usado, e as discussões migraram para um fórum onde mais de 200 PRs esperam.
Como exemplo, o autor analisa o PR #6826, que acrescenta a escuta em um socket TCP além do socket Unix. Pela sua estimativa, baseada na imagem Docker mkuf/moonraker, mais de 400 pessoas usariam esse recurso, mas não houve resposta de mérito. Assim, funcionalidades que não entram no núcleo acabam em forks. A Snapmaker alterou cerca de 20% da base de código para sua impressora U1, e a Creality e outros fabricantes distribuem versões antigas congeladas.
O autor argumenta que os forks saem caros para os fabricantes por causa de rebases e backports, e pede que as mudanças sejam enviadas à linha principal sempre que o canal de entrada funcionar. Para forks comerciais, propõe fundações neutras, nos moldes de OpenTofu, Valkey e OpenSearch.
É possível discordar de boa parte do texto, mas quem escolhe impressora e firmware se beneficia de saber de qual ecossistema depende. Para mim, a principal conclusão é que uma licença aberta não garante desenvolvimento aberto.
Fonte: Habr (Ænix blog)
A tese principal: o código do Klipper é excelente, mas o projeto não é organizado como uma organização. O CONTRIBUTING.md cita apenas Kevin O'Connor. Há quatro revisores, mas só ele tem permissão para fazer commit na master, então o fator de ônibus é um. O rastreador de problemas está praticamente fechado: resta uma única issue aberta dizendo que ele não é mais usado, e as discussões migraram para um fórum onde mais de 200 PRs esperam.
Como exemplo, o autor analisa o PR #6826, que acrescenta a escuta em um socket TCP além do socket Unix. Pela sua estimativa, baseada na imagem Docker mkuf/moonraker, mais de 400 pessoas usariam esse recurso, mas não houve resposta de mérito. Assim, funcionalidades que não entram no núcleo acabam em forks. A Snapmaker alterou cerca de 20% da base de código para sua impressora U1, e a Creality e outros fabricantes distribuem versões antigas congeladas.
O autor argumenta que os forks saem caros para os fabricantes por causa de rebases e backports, e pede que as mudanças sejam enviadas à linha principal sempre que o canal de entrada funcionar. Para forks comerciais, propõe fundações neutras, nos moldes de OpenTofu, Valkey e OpenSearch.
É possível discordar de boa parte do texto, mas quem escolhe impressora e firmware se beneficia de saber de qual ecossistema depende. Para mim, a principal conclusão é que uma licença aberta não garante desenvolvimento aberto.
Fonte: Habr (Ænix blog)
Comentários 0
Deixe o primeiro comentário, em qualquer idioma.
Entre para comentar