职业与工作方法michael.stapelberg.ch
我如何逐步退出 Debian 的参与
Winding down my Debian involvement
2019 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Michael Stapelberg 在这篇2019年的文章中解释了他为何逐步退出 Debian 开发。他列举了 Debian 在工具链、流程和社区响应速度上的种种问题，认为这些阻碍了他实现自己认为有价值的改进。文章引发了关于大型开源项目治理与开发者体验的广泛讨论。
为什么经久不衰：它触及了大型开源社区中个人贡献者与官僚化流程之间的永恒矛盾，至今仍是理解 Debian 乃至许多老牌项目困境的经典文本。
HN 评论精选
Debian 的打包流程对新手开发者极不友好，入门成本过高。
作为用户我喜欢 Debian 十多年了，但作为开发者，我觉得它极其令人沮丧。我好几次尝试把自己的开源项目打包进 Debian，但过程简直是噩梦。据我理解，首先得找个有合适权限的人来指导我，而我应该能直接提交一个候选包供审查才对。然后还有海量的打包文档，但哪本300页的指南才是对的并不清楚，该用哪套打包工具也不明确。最终，入门所需的时间投入让我一直没能贡献。
jcoffland查看英文原文
I've been using Debian for over 10 years and I still love it as a user. But as a developer, I find it extremely frustrating. I've several times attempted to figure out how to package my open-source projects [1] [2] for Debian but the process is a nightmare. As I understand it, I first have to find someone with appropriate privileges to mentor me. I should be able to just submit a potential package for review. Then there is a ton of documentation on creating packages but which 300 page guide is the right one to use is unclear. And which set of packaging tools should I use? In the end, the time investment required to get started has kept me from contributing. [1] https://camotics.org/ [2] https://foldingathome.org/
Nix 等现代工具链在开发者体验上远胜 Debian，好工具终将胜出。
根据我的经验，更好的工具从长远看总会胜出。我以前构建过 Debian 包，后来用 Nix 打包了同样的软件，就很难不觉得 Debian 的工具和打包方式是在毫无必要地浪费时间。nixpkgs 的模式——你只需要一个 git clone 就能构建一切，做一个改动只需发个 pull request 然后等一系列自动化测试告诉你没问题（既测构建也测包的“使用”），而要让贡献的改动落地只需点一个按钮——看起来明显更好。多年来我听很多人说“但 shell 脚本、FTP 服务器和神秘的辅助工具就是我们几十年来做事的方式，永远不会变”，但最终这些项目会萎缩，而那些开发者体验好、工具干净的项目会超越它们。
nh2查看英文原文
In my experience, better tooling always wins in the long run. I've built Debian packages in the past, and after packaging the same software with Nix, it's very hard to not feel that Debian tooling and packaging is time consuming for no good reason. The nixpkgs model, where all you need to build everything is one `git clone`, all you need to make a change is a pull request and wait for a range of automated tests to tell you it's good (for both build and the _uses_ of a package!), and all you need to land a contributed change is click one button, seems strictly better. Over the years I've heard many people say "but shell scripts, FTP servers and arcane helper tools is the way we've done it for decades and that will never change" in many projects, but eventually, these projects shrink and those with a good developer experience and clean tooling overtake them. Similarly, after experiencing automatic, safe refactoring across billion-line typed-checked code bases, you can't help but wonder why people put up with spending their time going through heoric community efforts distributing work across people that a machine could easily do if you used good tooling. In my opinion, the real strength and legacy of Debian is successfully running a large, diverse, distributed project over decades with (reasonable) cohesion, democracy, and (reasonably) good organisation and project management. But even some non-technical problems go away with good tooling, and more time gets freed up to solve those hard tasks. Concrete example: In nixpkgs it is very easy to build overlays for the whole of NixOS that allow you to switch from dynamic to static linking or add hardening flags across all packages, avoiding big debates over which is the "one true way" because providing both is so easy, and both can be merged upstream. I think any big and successful project should continuously invest into better tooling, and simplify and automate things. That keeps contributors motivated and on board. (14-years happy Ubuntu [and thus Debian] user, and 10-years i3 user, so thanks for your efforts, Michael.)
亲身经历对比：Gentoo 一周内响应并落实需求，Debian 则推诿否定，官僚主义严重。
有趣的文章。我曾有机会就某个特定功能（让获取开发者 GPG 密钥更容易）询问两个发行版。我首先联系的是 Gentoo：他们很快把我的邮件抄送给了相关人员，他们内部讨论后一周内部署了变更。然后我联系 Debian 问同样的事，邮件基本一样，但回复大体是否定的，抱怨细节，公开回避工作。整个互动让我想起大公司里任何变革都会遭遇为反对而反对。
Boulth查看英文原文
> I have more ideas that seem really compelling to me, but, based on how my previous projects have been going, I don’t think I can make any of these ideas happen within the Debian project. Interesting article. I had a chance of asking two distributions about some particular feature (making it easier to get GPG keys of developers). The first one I contacted was Gentoo: they quickly CCed my email to relevant people, discussed the matter between themselves and deployed the change in a week. Then I contacted Debian about the same thing. The email was basically identical. But the reply was largely negative, complaining about details and openly avoiding work. The entire interaction reminded me of large corporations where any change is met with resistance for resistance sake. (I use Arch btw.)
Debian 的持久力源于其意识形态和社区模式，而非技术优势。
Debian 就像民主：是最差的制造操作系统的方式，除了所有其他已尝试过的方式之外。BeOS、AmigaOS、Solaris、大多数其他80年代的操作系统——实际上都死了。Windows 和 macOS 实际上已经死过一次。BSD 有时会停滞数年。大多数 Linux 发行版（包括 RedHat）通常只和背后商业（或偶尔公共）实体的命运一样好。在这一切中，Debian 凭借其缓慢但不可阻挡的进步持续存在，仅仅因为它的意识形态基础——而非技术基础——明显优于所有其他。Debian 贡献者不是为了钱，所以当钱花光时他们还在；他们也不是为了酷，所以当操作系统工作不酷时他们还在。人来人往，但“民主操作系统”的理想将永远存在——因此，Debian 也会。
toyg查看英文原文
Debian is like democracy: the worst way of producing an OS, except all the others that have been tried from time to time. BeOS, AmigaOS, Solaris, most other 80s OSes - they’re effectively dead. Windows and macOS have effectively died once already. The BSDs can stall for years at times. Most Linux distributions (including RedHat) are typically only as good as the fortunes of the commercial (or occasionally public) entity they have behind. In all this, Debian endures, with its slow but inexorable progress, simply because its ideological foundations - not its technical ones - are eminently superior to all the others. Debian contributors don’t do it for the money, so they will be there when money runs out; and they don’t do it for being cool either, so they will be there when OS work is not cool. People will come and go, but the ideal of the “democratic OS” will always be there - hence, Debian will be too.
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com