this post was submitted on 22 Sep 2026
65 points (100.0% liked)
Open Source
49226 readers
236 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 7 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Several reasons, I guess?
1. The PGP (later, OpenPGP) protocol.
The proprietary PGP software, which was the initial implementation of the PGP protocol(s) also suffered from usability problems:
2. GnuPG maintainers are implicitly using asymptotic software versioning
Donald Knuth was probably the most notable proponent of the idea that software packages should increasingly tend toward stability, with fewer and fewer patches needed. He used explicitly asymptotic version numbering for TeX and Metafont.
Some of the quotes in OP's video make imply GnuPG's maintainers are implicitly following a similar approach, e.g. the section about "Sequoia's need for churn".
With encryption software, there is an especially strong argument for being conservative about changes. Patches may have unforeseen consequences, adding subtle vulnerabilities.
However, the downside of this, as the gpg.fail team pointed out, is that it biases the GnuPG maintainers towards excessive rejection of patches. Especially patches that would improve usability. Arguably, TeX suffered from a similar bias; hence the development of LaTeX and newer TeX front-ends to improve usability.
3. Changing the interface would be effortful
Improving GnuPG's interface would require quite a lot of work in itself, both to the codebase and the documentation.
Releasing a version with those changes would also require fielding a lot of support queries for many years, because decades of software manuals all over the web were written for the traditional GnuPG interface, and aren't going to be updated overnight. Some of those manuals will surely never get updated, because they are no longer maintained even though they are still online and still used.
I can sympathise with the GnuPG maintainers for finding this daunting. But the improvements are needed. Thankfully, developers of tools like
minisign,age, andsequoiaare taking on much of this work; it's just a pity that the work had to be done in this fragmented way through third-party efforts, instead of in GnuPG itself.