Klipper: open source without a community
Klipper has become the standard for many printer owners, but an article by Aleksey Sviridkin on the Ænix blog asks an uncomfortable question: what happens if a project rests on one person? The author makes clear that this is his personal opinion, and he backs it with fairly specific arguments.
The main thesis: Klipper's code is excellent, but the project is not organized like an organization. CONTRIBUTING.md names only Kevin O'Connor. There are four reviewers, but only he has commit rights to master, so the bus factor is one. The issue tracker is effectively closed: one open issue says the tracker is no longer used, and discussion has moved to a forum where more than 200 PRs are waiting.
As an example, the author looks at PR #6826, which adds listening on a TCP socket alongside the Unix socket. By his estimate, based on the mkuf/moonraker Docker image, more than 400 people would use such a feature, yet no substantive answer came. As a result, features that are not in the core end up in forks. Snapmaker changed about 20% of the codebase for its U1 printer, and Creality and other vendors ship frozen older versions.
The author argues that forks are expensive for vendors because of rebases and backports, and urges contributors to send changes to mainline wherever the intake channel works. For commercial forks, he proposes neutral foundations modeled on OpenTofu, Valkey and OpenSearch.
You can disagree with much of it, but anyone choosing a printer and firmware benefits from knowing which ecosystem they depend on. For me, the main takeaway is that an open license does not guarantee open development.
Source: Habr (Ænix blog)
The main thesis: Klipper's code is excellent, but the project is not organized like an organization. CONTRIBUTING.md names only Kevin O'Connor. There are four reviewers, but only he has commit rights to master, so the bus factor is one. The issue tracker is effectively closed: one open issue says the tracker is no longer used, and discussion has moved to a forum where more than 200 PRs are waiting.
As an example, the author looks at PR #6826, which adds listening on a TCP socket alongside the Unix socket. By his estimate, based on the mkuf/moonraker Docker image, more than 400 people would use such a feature, yet no substantive answer came. As a result, features that are not in the core end up in forks. Snapmaker changed about 20% of the codebase for its U1 printer, and Creality and other vendors ship frozen older versions.
The author argues that forks are expensive for vendors because of rebases and backports, and urges contributors to send changes to mainline wherever the intake channel works. For commercial forks, he proposes neutral foundations modeled on OpenTofu, Valkey and OpenSearch.
You can disagree with much of it, but anyone choosing a printer and firmware benefits from knowing which ecosystem they depend on. For me, the main takeaway is that an open license does not guarantee open development.
Source: Habr (Ænix blog)
Comments 0
Leave the first comment, in any language.
Log in to comment