Question

1997 年首版的“大教堂与集市”文章结束于上面这个展望：由程序员和无政府主义者组成的快乐的网络部落，战胜和压倒了等级森严的传统闭源软件世界。

然而，很多怀疑者并不信服，应该对他们提出的问题给予公允的回应。大多数对集市模式的异议都归结到这一点：集市模式支持者低估了传统管理方式带来的生产率乘数效应。

抱有传统观念的软件开发管理者经常会反驳说，开源世界中项目团队形成、变动和解散的随意性，极大抵消了开源社区在人数上相对闭源单人开发者的明显优势。他们说，软件开发真正需要的是持久的努力和客户预期在产品上持续投资的程度，而不是到底有多少人在锅中扔入一块骨头然后让它慢慢炖着。

这并不是没有道理，事实上，我在“魔法锅”（The Magic Cauldron）一文（本书后面的一章）中提出了这样的观点：未来软件产业的经济关键是服务价值。

但这个论点有一个重要的潜在问题，它暗藏了这样的假设：开源开发不能提供“持续的努力”。事实上，有一些开源项目长期保持着连贯的方向和有效的维护社区，而没有任何传统管理认为不可或缺的奖励机制或管控机构。GNU Emacs 编辑器是一个极端的、有启发性的例子，尽管该项目的人员流动率很高，从始至今持续起作用的只有一人（Emacs 的作者），但 15 年来，仍然有数百名贡献者投入努力，他们合作造就了一个统一的架构体系，还没有哪个闭源编辑器能匹敌这样的长寿记录。

这倒是给了我们一个质疑传统开发管理有什么优势的理由（与大教堂和集市模式的争议无关）。GNU Emacs 能够在 15 年内保持一致的架构体系，像 Linux 这样的操作系统在硬件和平台技术不断变化的 8 年来亦复如是，很多设计优秀的开源项目发展都超过了 5 年（事实上确实如此）——我们当然有权利质疑，传统开发管理的巨大花费，究竟给我们带来了什么。

不管是什么，它肯定不是这三项目标的可信履行：最后期限、预算和需求书中的所有功能。能达到其中一个目标，就已经是很少见的管得不错的项目，更不用说三个全达到了。它也不是在项目生命周期内适应科技和经济变化的能力，这方面，开源社区已被证明远远更为有效（这很容易被核实，比如说，比较 Internet 至今 30 年的历史和专有网络技术很短的半衰期；或者比较微软将 Windows 从 16 位过渡到 32 位的成本以及同时期 Linux 完成同样升级的毫不费力——不仅仅是在 Intel 产品线上，而且包括 64 位 Alpha 处理器在内的十多类硬件平台）。

一些人认为购买传统模式产品会带来这样的保障：如果项目出错，有人会负责，并为可能的损失买单。但这只是一个幻觉，大多数软件许可证连对商品的保证都没有，更不用说履行责任了——因软件质量差而成功获得赔偿的案例几乎没有。即便很常见，也不要因为可以起诉某人就觉得心安，你想要的不是官司，而是能用的软件。

那么所有这些管理开销能带来什么？

为弄明白这点，我们需要了解软件开发管理者是如何看待自己工作的，我有位朋友看上去在这方面做得很好，她说软件管理有五个功能：

·明确目标并让大家朝同一个方向努力。

·监督并确保关键细节不被遗漏。

·激励人们去做那些乏味但必要的“体力活”。

·组织人员部署并获得最佳生产力。

·调配项目所需的资源。

显然所有这些目标都是有价值的，但在开源模式及其所在的社会语境中，人们会惊奇地发现这些目标毫无意义，我们按颠倒过来的顺序分析。

朋友告诉我，很多资源调配基本上是防守性的；一旦你拥有人、机器和办公空间，你就不得不防备同级管理人员对资源的竞争，以及上级对有限资源中最有效部分的调用。

但开源开发者是志愿者，是因为兴趣和能力（能否对项目有所贡献）自主选择的（即便他们因开源工作领取薪水，这也依然适用），志愿者精神倾向于自发去关心资源问题的“解决”，他们会把自己的资源带到工作中，这里几乎没有传统意义上“防守”的必要。

无论如何，在一个廉价 PC 和快速 Internet 连接的世界里，我们发现始终如一真正有限的资源是技术人员的关注，开源项目如果失败了，根本不会是因为机器、网络或办公场地，它们死掉的唯一原因就是开发者们不再感兴趣了。

这种情况下，开源黑客通过“自我组织”来最大化生产力就显得加倍重要，自愿者自主选择项目，社会环境则无情地选择能力。我那个朋友对开源世界和大型封闭项目都比较熟悉，她相信开源之所以成功，部分原因是开源文化只接受编程人员中那最有才华的 5%。她将自己的大部分时间都花在了组织部署其他的 95%，并因而第一手见证到那广为人知的差异：最有才华的程序员和那些刚刚及格的程序员之间，生产率能相差 100 倍。

人们常常会因为这种差异提出一个棘手的问题：对单个项目或者整个行业来说，撤离出那 50%能力较差的程序员会不会更好一些？思考已久的管理者们早就明白，如果传统软件管理的目的仅仅是把能力最差那部分人的净损耗转变成微弱盈余的话，那问题就简单多了。

开源社区的成功使得这个问题更加尖锐，强有力的证据表明，从互联网上招募自主选择的志愿者，通常更便宜、更有效。而传统方式管理的那些写字楼里的人，其中有很多可能宁愿去干点别的。

这很直接把我们带到“动机”问题上，一个经常听到的说法和我朋友的观点等效：传统开发管理是对缺乏激励的程序员们的必要补充，否则他们不会干得很好。

这个答案常常伴随着一种观点，认为开源社区只会去做那些很吸引人或者技术上很好玩的东西，其他“无聊”部分则会被丢在一边（或半途而废），等那些受金钱激励的坐在隔间里的苦工们在管理者的严厉鞭策下机械地将其生产出来。我将从心理学和社会学角度，在“开垦心智层”（Homesteading the Noosphere）一文中对这种观点进行质疑。

如果传统、闭源、严格管理模式的软件开发真的想靠这种由“无聊”部分组成的马其诺防线来防御，那么它之所以在某个应用领域能继续生存下去，只是因为还没人发现这些问题是真正有趣的，并且还没人发现迂回包抄的路径。一旦有开源力量介入这些领域，用户就会发现终于有人是因为问题自身的魅力而去解决它的，就像其他所有需要创造力的工作，若论激励效果，问题自身的魅力比单纯的金钱要有效得多。

单纯为解决动机问题而设立一个传统的管理架构，可能战术不错，但其战略是错误的，这一套在短期看会有效，但长远来说一定会失败。

目前来看，传统的开发管理相对于开源，至少在两方面（资源调配和组织）都没有胜算，而且似乎在第三点（动机）上也快要玩完了。可怜的传统管理者，现在是四面楚歌，在“监管”这个话题上也无法获取一丝安慰，开源社区最强大的一个长项就是非中心化的同行评审，所有致力于细节不被疏漏的传统方法，都无法和它相比。

那么，“明确目标”的作用是否可以作为传统软件项目管理值得存在的正当理由？也许是，但是，比起开源世界由项目领导人和部落长老决定目标的方式，我们需要有好的理由来相信管理委员会和公司路线图所定义的目标在价值上以及在让成员广泛接受上能做得更成功。

但我们很难得出这个结论。并不是因为开源这边（Emacs 经久不衰，Linus Torvalds 号召大量开发者们“统领世界” ^[8] ）表现太优秀，而是传统机制在定义项目目标方面做得实在太糟。

软件工程中最广为人知的一条大众定理是：传统软件项目中的 60%到 70%，要么是从未被完成，要么被他们的用户拒绝。如果这个比例还算靠谱的话（我还没见过任何一个有经验的项目管理者对此提出过异议），那么大多数项目把目标设定得要么太不现实，要么完全错误。

这正是如今软件工程领域中，一听到所谓“管委会”就让人后背发凉的原因——即便（或尤其）听者是一名管理者。以前仅仅是程序员抱怨这种模式，现在，呆伯特 ^[9] 玩偶已经出现在主管的办公桌上。

所以，我们对传统软件开发管理者的答复就很简单了——如果开源社区真的低估了传统管理的价值，那为什么你们中的这么多人都表现出对你们自己流程的不屑？

又一次，开源社区的例子把这个问题变得更为尖锐——我们做这些是为了乐趣。我们创造性的游戏已经在技术上、市场占有率上、观念认同上以令人震惊的速度获得了增长，我们不仅证明了我们可以做出更好的软件，而且证明了快乐也是一种资产。

本文第一版发布已经两年半了，我能提供用来作为结束语的最激进的观点，已经不再是“开源统领软件世界”这样的愿景了，毕竟那些很严肃的西装革履的人，也认为这种观点有些道理了。

更进一步，我想给出一个更普遍的关于软件的经验（可能适用于所有创造性或专业性工作），人类通常会从一种位于“最佳挑战区”的任务中获得乐趣，也即它不是太容易而让人无聊，也不是太困难而无法完成。一个快乐的程序员是一个既没有被浪费也没有被压垮（由于不适当的目标或过程中充满压力与冲突）的人，乐趣预示着效率。

如果你在工作过程中感到恐惧和厌恶（即便你以自嘲的形式来表达——比如悬挂呆伯特玩偶），就应该意识到过程已经出了问题。快乐、幽默和玩兴是真正的资产，前面我之所以写“快乐部落”（happy horde）并不是为了首字母押韵，而用一只憨态可掬的企鹅作为 Linux 吉祥物也绝不仅仅是为了搞笑。

现在看来，开源成功的一个最重要成果，就是告诉我们，“玩”是创造性活动中最具经济效能的工作模式。