2.12 论管理与马奇诺防线

1997 年《大教堂与集市》一文的结尾描绘了上述愿景——一群快乐的、互相联结的程序员/安那其主义者“乌合之众”，在竞争中击败并压制了体制森严的传统闭源软件行业。

不过很多质疑者并不认可这套说法，他们提出的问题值得好好讨论。反对集市模式的声音，大多都指向同一个观点：推崇集市模式的人，低估了传统管理对开发效率的提升效果。

思想传统的软件开发经理常会反对说，开源社区的协作小组组建、变动、解散都十分随性，这份不稳定性直接抵消了开源人手充足的优势。在他们看来，软件开发看重长久稳定的投入，以及客户对持续维护更新的稳定期待，而不是大家随便往锅里丢点骨头，就放任项目自己慢慢熬。

这种说法当然有合理的地方。我曾在“魔法锅炉”一文中详细论述过：用户所预期的长期后续维护服务价值，是软件生产经济学的关键。

但这套观点本身藏着一个关键漏洞：它默认开源项目没办法长期稳定投入维护。可现实里有不少开源项目，完全不靠传统企业必备的薪酬激励、层级管控体系，照样长年守住统一开发方向，维护社群稳定高效运转。GNU Emacs 编辑器就是一个很有说服力的极端例子，15 年间开发者来来去去、人员流动极大，全程只有作者一人始终持续跟进，却把好几百个贡献者的代码都整合进了统一完整的架构思路里。市面上没有任何一款闭源编辑器，能维持这么久的持续迭代生命周期。

这就给了我们独立于 “大教堂 vs 集市” 之争的全新视角，去重新审视传统管控式开发的优势。既然 Emacs 能连续 15 年坚守统一架构，Linux 系统也能在硬件、平台技术飞速迭代的八年间保持整体设计连贯；更何况大量架构完善的开源项目，稳定运营周期都超过 5 年，那我们不妨好好想一想，传统开发模式付出高昂的管理成本，到底换来了什么实实在在的收益？

传统管理模式换来的那些东西里，绝对不含按期交付、不超预算、完整落地需求文档全部功能这三样。企业管控项目能达成其中任意一项都算少见，三者同时达标更是几乎没有。它也没法让产品在开发周期内灵活适配技术、市场环境的变动，这一点开源社区的表现要好得多。举两个直观例子：互联网稳定发展 30 年，反观各类私有网络技术生命周期都很短；再看系统位数升级，当年 Windows 从 16 位转到 32 位付出巨大成本，同期 Linux 的升级迁移却几乎没什么阻力，不光适配全系列 Intel 芯片，还顺利移植到十多种硬件平台，64 位 Alpha 架构也包含在内。

不少人觉得传统闭源模式的一大优势是出问题能找到法人主体追责，甚至索要赔偿。但这只是空想。绝大多数软件许可协议都会直接免除商品适销担保，更不会承诺运行效果；真因为软件故障索赔成功的案例少到几乎找不到。就算索赔容易实现，一门心思指望出事去打官司也完全搞错重点。大家的核心诉求从来不是起诉厂商，而是拿到稳定可用的软件。

那这么高昂的管理成本，到底换来了什么？

想弄明白这个问题，得先搞清楚软件项目经理自认的核心价值。我认识一位业内做得很出色的项目管理者，她总结出项目管理一共承担的 5 项职责：

• 明确项目目标，保证所有人发力方向统一

• 全程跟进把控，避免关键细节出现遗漏

• 调动员工积极性，推动大家完成枯燥却必不可少的基础杂活

• 合理调配人手，最大化团队产出效率

• 统筹各类资源，保障项目能够持续推进

这些职责单看确实都很合理，可放到开源模式和对应的社群环境里，就显得没那么必要了。下面我们倒着逐条分析。

我那位做管理的朋友说，资源调配在很大程度上是一场防御性战役。你好不容易争取到人手、设备、办公场地，一边要设防抵御同级经理对这些资源的侧翼进攻，同时还要抵挡上层重新拆分有限资源池的压力。

但开源开发者都是自愿参与的，本身就因为感兴趣、有能力才主动加入项目，就算有人拿工资做开源开发，这个底层逻辑也没变。志愿协作的氛围直接解决了资源调配的“进攻”问题——大家自带电脑、网络等资源参与进来，完全不需要像传统管理者那样“打防守”。

况且现在电脑便宜、网络普及，真正稀缺的资源从来不是硬件，而是资深开发者投入的精力。开源项目很少会因为缺设备、缺网络、缺办公场地做不下去；只有开发者失去热情，项目才会彻底停滞。

既然是这个逻辑，那开源开发者靠自主筛选、自发组队来拉满整体效率这件事就格外关键 —— 整个社群环境会毫不留情地筛掉能力跟不上的人。我那位既熟悉开源、也操盘过大型闭源项目的朋友认为，开源能做成，一部分原因是这套生态只吸纳程序员群体里顶尖那 5% 的高手。而她日常绝大部分工作，就是管理剩下 95% 的普通开发人员，也亲眼印证了业内公认的现状：顶尖程序员和仅仅够用的普通开发者之间，产出效率能差上百倍。

如此悬殊的效率差距，一直抛出来一个很难回避的问题：如果直接筛掉垫底半数能力不足的人，不管是单个项目还是整个行业，会不会运转得更好？有见地的管理者早就想明白一件事：假如传统管理唯一的作用，只是把能力最差的那群人从纯拖后腿变成勉强不亏，那整套管理流程其实根本得不偿失。

而开源社群的成功，把这个疑问摆到了台面上，还给出实打实的佐证：网上自发聚集、自愿参与的贡献者，远比管理一整栋心思根本不在这份工作上的全职员工，成本更低、效果也好得多。

这便自然引出了激励的问题。阐述我朋友观点的一个常见等效说法是，传统开发管理是对积极性不高的程序员的必要补偿，也就是要推着那些本身没什么干劲的程序员好好干活，否则他们无法产出好的工作。

持这套看法的人一般还会附带一个论调：开源开发者只愿意碰有意思、技术酷炫的活儿；枯燥琐碎的工作没人愿意碰，就算做也做得稀烂，这类任务只能靠拿工资的办公室员工，在管理层的督促下硬着头皮完成。我在《垦殖智域》里从心理、社群层面分析过，为什么这个说法站不住脚。不过现在我们不妨先假设这个论调是对的，看看能推出什么结论。

如果传统高度管控的闭源开发模式，唯一能守住的阵地就只有那些没人感兴趣的枯燥工作，那它能存续的时间就十分有限——只要哪天有人觉得这块枯燥业务值得钻研，或是找到了别的实现路径，这套模式就会被攻破，如同形同虚设的马奇诺防线。一旦某种枯燥软件出现开源竞品，用户就能明显感受到差异：开源贡献者是发自内心想解决这个难题才动手开发。不管是写软件还是其他创造性工作，发自内心的热爱，带来的驱动力远不是单纯薪资能比的。

那如果搭建整套传统管理架构仅仅只是为了驱动员工干活，那可能是一种好的战术，却是糟糕的战略——短期或许能赢，但长期来看则必输无疑。

梳理到这里能看出来，传统开发管理对比开源，在两件事上完全落了下风：资源统筹、人员编排；至于员工激励这块，也只是苟延残喘、撑不了多久。而这位可怜的、四面楚歌的传统管理者，在流程监督这一项上同样找不到优势。开源最硬核的优势就是分布式同行评审，想要杜绝细节疏漏，这套机制碾压企业里所有传统管控手段。

那最后只剩 “制定统一目标” 这一点，能不能拿来证明高额管理成本有存在的必要？或许还有一丝可能，但前提是要有足够依据证明：企业管理层、官方产品路线图，定下的目标更有价值、更容易让所有人达成共识，效果胜过开源社群的负责人和部落长老这类角色。

单从表面来看，这套说法很难站得住脚。倒不是开源这边的案例太有说服力——比如 Emacs 长达十几年的生命力，或是林纳斯·托瓦兹召集“乌合之众”发表“统治世界”^a的演讲，就能集结大批开发者。而真正拉垮对比结果的，是传统企业用来定项目目标的流程实际表现惨不忍睹。

软件工程有一条广为熟知的行业结论：60% 至 75% 的传统软件项目，要么无法收尾完工，要么交付后被目标用户舍弃。如果这个比例基本属实（我接触过的所有资深管理者都不曾反驳），那么大多数项目锁定的目标要么 (a) 脱离现实、根本无法落地实现，要么 (b) 根本方向就是错的。

和其他各种问题相比，这也是如今软件行业里，哪怕听者本身就是管理者（甚至管理者感触更深），光是听到 “管理委员会” 这个词也让他们心里发怵的核心理由。过去只有程序员吐槽这套模式的时代早已远去，如今高管的办公桌上，都会贴着讽刺企业管理的《呆伯特》（Dilbert）漫画。

那我们对传统软件开发管理者的回应其实很简单，如果开源社群真的严重低估了传统管理的价值，那为什么你们有这么多人打心底里嫌弃自己这套流程呢？

开源社群的现状再次把这个问题摆得明明白白，我们做开发本身就是乐在其中。这份带着趣味的创造性实践，在技术成果、市场份额、行业认知影响力上都收获了惊人的成绩。我们不只证明自己能产出更优质的软件，更证明发自内心的愉悦本身就是一种宝贵的资产。

距离这篇文章第一版发布已有两年半，我文末想抛出的最有颠覆性的观点，已经不再是畅想一个由开源主导的软件行业；毕竟现在也有不少行事严谨、西装革履的人觉得这个图景具备可行性。

但我想提炼一条适用范围更广的道理，不只针对软件开发，可能所有创意类、专业类工作都通用：人只有身处恰到好处的挑战区间，才能从任务里获得乐趣，它不至于简单枯燥，也不会难到无从下手。一名状态舒展的开发者，自身能力不会被闲置，也不会被模糊混乱的目标、内耗沉重的流程拖累。享受工作，就意味着更高的效率。

如果从业者发自内心抵触、厌恶整套工作流程，哪怕只是通过贴《呆伯特》漫画这种讽刺自嘲的方式表现出来，这本身就说明这套流程已经彻底失效。愉悦、幽默感、轻松的创作氛围，都是实打实的宝贵优势。前文我写下 “快乐的‘乌合之众’”（happy hordes），不只是为了玩文字头韵（alliteration）的修辞；Linux 的吉祥物是软萌幼态的小企鹅，也绝不是随便一个玩笑。

开源取得成功，最重要的启示或许就是：以轻松自在的玩乐心态去创作，才是创意工作里性价比、经济效率最高的模式。