［这是《大教堂和市集》新译本的一部分，全文在http://rl.rockiestech.com/node/101 ，征求意见中。］

原始的1997年的《大教堂和市集》论文以以上的预见结束——程序员／无政府主义者的幸福网络群体胜出并压倒了传统闭源软件的阶层化世界。
然而，很多怀疑者并不信服；他们提出的问题也值得一场像样的论战。多数对市集模式的反对归结到一个观点：它的鼓吹者们低估了传统管理促进生产率的效果。
老脑筋的软件开发经理经常指责开源世界里项目群体形成－转变－消亡的随意性大大抵消了开源社区对单个闭源开发者在数目上的显然优越性。他们会指出在软件开 发里，真正重要的是长时间里不懈的努力和多大程度上顾客可以预期对产品的持续投资，而不仅仅是多少人往锅里扔一块骨头让它炖着。
没有疑问，这条争论有料；实际上，我在“The Magic Cauldron”一文中就已经展示了预期的未来服务价值是软件产业经济的关键的观点。
但是这条争论也有一个主要的潜在问题：它的暗中假设是开源开发不能形成持续的努力。事实上，有的开源项目在很长的时间段里保持了一致的方向和有效的维护团 体，而不需要传统管理上觉得关键的那些奖掖性的结构或制度性的控制。GNU Emacs编辑器的开发是一个极端的、说明问题的例子：它在超出15年的时间里吸取了成百上千贡献者的劳动、形成了一个统一的结构设计，尽管人事变换频 繁、一贯持续下来的人只有一个（它的作者）。没有闭源的编辑器或曾比得上这个长寿记录。
这建议了一个质疑传统管理模式下软件开发的优势的理由，与其它关于大教堂和市集模式的争议不相干的理由。如果GNU Emacs可以在15年里表述一个一致的框架设计，或者一个像Linux的操作系统在8年多里快速变化的硬件和平台技术中作到了同一点；如果（事实的确如 此）存在许多设计优良的开源项目超出了5年的历史——那么我们有权发问传统管理开发的庞大开销给我们买来了什么——如果有的话。
不管是什么，它显然不包括按期限、或预算、或所有指定功能的可靠执行；能满足这些目标中仅仅一条就是一个罕见的“管理好”的项目了，更不用说全部三 条了。它看来也不包括在项目进行过程中适应技术和经济环境变化的能力；在这上面，开源社区证明了远远更为有效（来简单确认这点，比方说，可以比较互联网 30年的历史和私有网络技术短短的半衰期；或者比较微软视窗从16位转换为32位的成本和Linux同一时期几乎毫不费力的升级——不仅是围绕英特尔系列 的开发，而且也扩展到包括64位Alpha芯片的十多个其他硬件平台上）。
很多人觉得从传统模式中购买到的一件东西是有人负法律责任、如果事情出了问题可能找赔偿。但这是一个幻觉；大多数的软件协议是写了来免除甚至商品化 的保证，更不用说性能了——而且从软件性能问题上成功索赔的案例少得近于虚幻。即使这类事很平常，因为有人来打官司而觉得心安是搞错了要点。您不想打官 司；您要的是能工作的软件。
那么这些管理开销都买了什么呢？
要理解这个问题，我们需要理解管理软件开发的经理们是怎么想的。我认识的一个似乎很优秀的女经理说软件项目管理有五项功能：
＊明确目标并保持大家向同一个方向努力
＊监测并确保关键的细节不被漏掉
＊动员人们做枯燥但是必要的苦力活儿
＊组织人员分配来达到最佳生产力
＊监护项目持续所需要的资源
显然是有价值的目标，所有这些都是；但是在开源模式下，并且在它周围的社会语境中，这些会奇怪地开始显得不相干。我们来按逆序讨论这几条。
我的朋友报告说许多资源监护基本是防卫性的；一旦你有了你的人员机器和办公空间，你不得不防卫其他经理竞争相同的资源，和防卫上级调用有限资源中最高效的部分。
但是开源开发者是志愿的、在兴趣和对所参与项目的贡献能力上自我挑选的（甚至在他们领了薪水为开源项目编码的情况下这条也一般适用）。志愿者的特点会自动 解决资源监护的“攻击方”；人们把自己的资源带到桌面上来。而且对管理者来说，没有或几乎没有必要来作传统意义上的“防卫”。
不管怎样，在一个便宜电脑和快速互联网连接的世界里，我们很一致的发现真正唯一的稀缺资源是有技术的努力。开源项目本质上从不会为了争夺机器或网络或办公空间而成立；它们只在开发者自己失掉兴趣的时候消亡。
在这点之外，加倍重要的是开源黑客们通过自我选择组织达到最大生产率——社会环境也无情的对能力作选择。我的朋友，对开源世界和大型闭源项目都熟 悉，认为开源的成功部分归功于它的文化只接受编程人员中最有才华的5％左右。她花费了她大多的时间来组织部署其他的95％，于是第一手观察到了那著名的、 最优秀的和仅仅及格的程序员之间一百倍的效率差别。
这个差别的巨大程度总是引发一个尴尬的问题：不管单个的项目还是整个行业，甩脱了那50％以上最差的是不是会更好一些？肯动脑的管理者很久以来就懂得，如果传统软件管理的唯一功能是把最差的一帮人从净损失转为微盈利，这事儿恐怕就不值得折腾。
开源社区的成功，通过提供硬性证据显示从互联网上招募自我选择的志愿者经常要比管理整栋楼的“身在曹营心在汉”的人们要便宜和有效的多，在相当程度上尖锐化了这个问题。
这恰好把我们带到驱动力的问题。一个同等的、常见的方式来提出我朋友的观点是：传统开发管理是对缺乏动力的程序员的必要补充，不然他们做不好工作。
这个回答一般携带着一个说法：只能指望开源社区做那种“眩目”的或技术上好玩的工作；任何其它的会被拉下（或敷衍其事）——除非金钱驱动的坐隔间的人在经 理们的鞭策下把它搅出来。我在“Homesteading the Noosphere”里解释对这个说法怀疑的心理学和社会学原因。然而就当前的目的，我觉得指出如果假定它是正确而衍生出的推论更有意思一些。
如果传统的、闭源的、冗肿管理下的软件开发真的只是在枯燥引发的问题造成的一条马其诺防线的守卫下，那么它在每一个应用领域里的寿命就只有指望没有人发现 这些问题真正有意思、而且没有他人发现绕道而行的方法。因为一旦一种“枯燥”的软件出现了开源的竞争者，顾客们会知道终于有人因为关注这个问题本身而选择 来解决它了——这一点，对软件业像对其它任何的创造性工作一样，是比单独的金钱远为有效的驱动力。
仅仅为了驱动力来要一个传统的管理结构，或许就是一个好的计谋、坏的策略，短期的利益、长期的必然亏损。
说到这里，传统式开发管理和开源相比，现在在两点（资源监护，组织）上看起来不是明智之选，而且在第三点（驱动力）上朝不保夕。可怜的受困的传统项 目经理也不会在监测一项上得到任何帮助；开源社区的最强大的一个证据就是非集中化了的同行评议在试图保证细节不被忽略上胜出了所有的传统方法。
我们可以把目标的定义留下来作为接受传统软件项目管理的成本的理由吗？可能吧；但是这样，我们需要好的理由来相信管理委员会们和公司路线图比开源世界里的扮演类似角色的项目领导和部落长者们在定义有价值的、广泛共享的目标上更为成功。
就面上来看，这很难讲得通的。困难没有多少是来自于对峙的开源一方（Emacs的长寿，或莱纳斯。托瓦兹以“统领世界”的说辞动员大群的开发者的能力）。而是来自于传统机制在定义软件项目目标上表现出来的尴尬。
软件工程里一个最出名的大众定理是60％到75％的传统软件项目要么从没完成过，要么被目标用户否决了。要是这个范围真的和事实沾边（我从没有遇到过一个有经验的管理者否定过这点），那么占多数的项目都瞄向了（a）现实里达不到的或（b）错得离谱的目标。
在今天软件工程的世界里，“管理委员会”这个词会让听者背上直冒冷气——甚至（或者尤其）当听者是管理者的时候；上述这一点比其它任何的问题都是更主要的原因。那些只有程序员们咒骂这一现象的日子早已过去了；迪尔伯特的卡通如今挂上了管理层的案头。
我们对传统软件开发经理的回答，那么就很简单——如果开源社区真的低估了传统管理的价值，为什么你们这么多人表现了对你们自己工作的轻蔑？
开源社区的例子再次把这个问题尖锐化了——因为我们做事乐在其中。我们创新的游戏已在技术、市场占有和观念的成功上以惊人的速率得分晋级。我们在证明不仅我们可以开发更好的软件，而且欢乐是一种宝贵财产。
在这篇文章第一版的两年半后，我能用来结尾的最激进的观点不再是一个开源统领的软件世界；那毕竟，在今天很多穿西服套装的人看来也是有可能的了。
相反，我想提出一个或许更广泛的、对软件业的教训，（或许也是对于任何一种创造性的或专业性的工作）。人们一般在一项任务处于一种适当难度范围的时 候享有乐趣；不要太简单了至于无聊，不要太难了不好实现。一个快乐程序员是一个既没有被浪费也没有被错误制定的目标和烦人过程摩擦所压倒的人。乐趣通往效 率。
以畏惧和厌恶来谈论你自己的工作过程（即使通过悬挂迪尔伯特卡通这种改头换面的讽刺性方式）因此本身应该被看作一个过程失败了的信号。欢乐、幽默，和趣味 是真正的财富；我在上面写的关于“快乐的一群”主要不是为了押韵，Linux的吉祥物是一个可亲的、稚气犹存的企鹅也不仅仅是玩笑。
结果很可能是，开源的成功带来的一个最重要的影响会是教育我们乐趣是创造性工作的经济上最有效的模式。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[http://rl.rockiestech.com]
洛基开放文化实验室，使用开源方法来推动社会文化进步