大教堂与市集-2

1. 如今我们有了另一款软件，与fetchmail相比，它对市集模式假设做了更多的测试。这就是EGCS——实验性GNU编译系统（Experimental GNU Compiler System）。这个项目始于1997年8月中旬，它被视为对早期（《大教堂与市集》公开版本中）观点的有意尝试。GCC项目（GUN C语言编译器，GNU C Compiler）创始人的离开，导致其停滞了许久。大约二十个月之后GCC和EGCS开始了平行的开发——利用相同的因特网开发人员；都以相同的GCC源代码为基础；使用几乎相同的Unix开发工具和开发环境。惟一不同之处在于，对于EGCS我们使用了先前述及的市集策略。而GCC则采用了类似大教堂的开发模式——封闭的开发团队，极少的对外释放。这是我们能做到的最贴切的核对实验了，其结果颇具戏剧性。几个月里，EGCS就凭借一些特色遥遥领先——更棒的优化设计以及对FORTRAN和C++语言更好的支持。许多人发现与最近的GCC稳定版本相比EGCS发展的更迅速也更可靠。而且主要的Linux发行版都开始改用EGCS了。1999年4月，自由软件基金会（GCC的官方发起机构）决定解散原始的GCC开发团队，并正式由EGCS接管。2. 当然，克鲁泡特金的批判和李纳斯定律把社会组织控制论抬升到了更广阔的角度。进而联想到软件工程领域的另一则民间法则，康威定律（Conway's Law）：“让四个人开发编译器，你就会得到四个（4-pass）编译器”。原始表述更具有一般性：“产品必然是其组织通讯结构的缩影”。简言之就是“方法决定结果”或是“过程变为产品”。在很多层面上，开源社区没有必要形成与这适应的组织功能结构。网络无处不在：非独因特网，人们的工作也可以形成一种分布式的松散连接，一种对等网络。正是这种联系提供了恰如其分的冗余和缓解。对于这两种网络而言，一个节点的重要性取决于有多少人愿意与其相连。其中对等部分对社区惊人的生产力至关重要。SNAFU法则[2]发展了克鲁泡特金对权力观点的阐释：“只有平等才能带来真诚的交流，因为下级更习惯于取悦上级而非告知以诚。”创造性的团队协作需要坦诚的交流，所以权属关系的存在必然形成制约。有效摆脱权力羁绊的开源社区向我们展示了这有多可怕：错误、低产能与错失机会！进而SNAFU法则预言在独裁组织中，随着谄媚越来越多，决策者和事实的剥离也愈发严重。其在传统软件开发中所扮演的角色显而易见：下级有很多动机去隐匿、漠视、淡化问题。一旦这个过程转化成了产品，就是一场灾难。译者按：1. 皮奥奇·阿列克谢耶维奇·克鲁泡特金：Пётр Алексеевич Кропоткин (1842-1921) 俄国无政府主义者、地理学家、政治哲学家，他认为改善人类现状的方法是合作而不是竞争。他对俄国和英国的无政府主义运动产生了很大的影响。《我的自传》是巴金的译作，也是巴金认为对自己影响最大的一本书。其英文版名为《Memoirs of a Revolutionist》。2. SNAFU：“snafu”是二战时期军队中使用的一条缩略语。也就是Situation normal all fucked up（好日子都他妈搞砸了）。后来也写为Situation normal all fouled up（平静的状态被搅乱了）。黑客则借此解释集权模式的恶果。十二 关于管理和马其诺防线1997年最初的《大教堂与市集》以这样的预见收束——程序员/无政府主义者快乐的网络部族，战胜并压倒了等级森严的传统闭源世界。然而，许多人对此持怀疑态度，他们提出的问题应该得到中正的回应。多数对市集模式的异议可以归结为以下观点：开源支持者们低估了传统管理对生产力的提升作用。传统思维的软件开发经理经常会指责开源项目组的创建-变动-解散太随意了。这种随意性大大抵消了（对于单个闭源开发者来说）开源社区在人数上的优势。他们会指出软件开发取决于长时间的持续投入，和预期的消费者持续购买程度。而不只是取决于有多少人往锅里扔骨头，然后等着它炖熟。无可否认，这些论调有一定道理。其实我早就在《魔法大锅炉》（The Magic Cauldron）一文中预计增值服务将会是未来软件业的经济命脉。但是这个论调却回避了一个重要的问题，它暗自假设开源开发不能提供持续的投入。事实上，有些开源项目已经在相当长的周期里保持了一致的发展方向和有效的维护社区，而不需要传统管理中必不可少的激励模式和制度约束。GNU的Emacs编辑器就是一个极端的、发人深思的例子。不管人事变动有多么频繁（实际上一以贯之的只有作者一人），几百位贡献者还是在长达15年的时间里用全心全意的投入建筑了一个统一的架构。没有一个闭源编辑器能问津这个长寿记录。这到是提供了一个质疑传统软件开发模式（和大教堂与市集模式的争论不相干）的原因。如果GNU的Emacs在15年的岁月里保持了一致的架构；如果一个像Linux这样的操作系统在硬件和平台技术飞速变换的8年里也做到了这一点；如果（事实如此）许多设计精良的开源项目维系了超过5年的时间——那么我们有资格发问，传统开发的巨额管理费用（如果有的话）究竟给我买到了什么？不管是什么，它显然不包括按期、按预算、按指定功能完成计划的可靠运营手段。如果能满足其中一条，就是一个罕见的“管理好”的项目了，更不用说全部了。它看来也不包括在让项目在开发过程种拥有适应技术和经济环境变化的能力。在这些方面开源社区已经遥遥领先了（比方说，你可以对比一下因特网30年的历史和那些专利网络短命的半衰期，也可以对比一下从16位到32位Linux毫不费力的升级和微软为此消耗的成本。特别要提醒你的是，Linux可不是只围绕英特尔系列打转，而是支持了包括64位Alpha芯片在内的十几家芯片厂商的产品）。很多人认为从传统模式产品中可以买到法律保障——一旦出现问题会有人站出来负责，并得到补偿。但是这只是个幻觉，大部分软件许可证甚至没有写入商业担保，更不用说履行了。因为软件不工作而获得赔付的成功案例基本为零。退一步讲，就算有很多成功案例，你也不能因为有了打官司的对象就安心了啊！软件是为我们工作的，不是拿来打官司用的！那么这些管理成本到底买来了什么呢？要理解这个问题，就要看看软件开发经理是怎么想的。我认识的一位看似工作很出色的女经理说，软件项目管理有以下五项功能：确立目标，并确保大家朝着同一个方向努力监督，保证关键细节无一遗漏激励，让大家去做一些枯燥但是必须的苦力活组织，分配人手以达到最佳产出资源监护，满足项目所需显然所有这些目标都是有价值的。但是在开源模式以及其社会语境中，这些目标会变得出奇的不靠谱。我们颠倒次序来讨论。我的朋友告诉我，许多“资源监护”基本都是防御性的。一旦你有了人手、机器、办公空间，就不得不防备其他经理与你竞争相同的资源，也要防备上级攫取有限资源中的精华。但是开源开发者都是志愿的，他们通过能力和兴趣自主选择项目（即使他们因为开源开发而获得报酬，这条也依旧适用）。志愿的特点会自动解决资源监护中的“进攻方”，因为大家桌上放的全部是自己的资源。这对管理者而言，意味着几乎没有必要进行传统的“防御”。总之，在一个拥有廉价电脑和快速因特网链接的世界里，我们不约而同的发现惟一真正的稀缺资源是技术关注。本质上，开源项目永远不会为了争夺机器、网络、办公空间而建立。只有当开发者失去兴趣的时候它们才会消亡。除此之外，加倍重要的是开源黑客们通过基于自主选择的“自我组织”来达到最大产能——社会环境对于能力的选择是近乎残酷的。我的那位朋友对开源世界和大型闭源项目都很熟悉，她认为开源的成功应归功于其只吸纳了程序员中最具才华的5%。而她则将自己的时间都消耗在如何组织剩下的95%上了。因此她在一线上感受到了这种众所周知的差异——对于刚刚够格的程序员，精兵强将足以以一顶百。这个巨大差异总是引发一个尴尬的问题：无论对于单个项目还是整个行业，甩掉能力最差的50%会不会好些？明智的经理早就明白，如果传统管理的惟一作用是为了将最差部分由净亏损转变为边际收益的话，未免太得不偿失了。开源社区的成功把这个问题变得相当尖刻，因为我们提供了硬性的证据：与管理整栋楼“身在曹营心在汉”的人相比，通过因特网招募自主选择的志愿者算是相当的“物美价廉”了。这恰好把我们转向了“动机”的问题，对于我朋友的观点，有另外一种等价的，也时常听到的描述：传统开发管理是对缺少动力的程序员的必要补偿，否则他们不会好好干活。这个回答通常伴随着一个说法，那就只能指望开源社区做那种“迷人”的或者技术上有趣的工作，否则都会半途而废（或敷衍了事）——除非能把他们变成那种经理鞭打下收入微薄的苦工。我在《开拓智域》（Homesteading the Noosphere）一文中就心理学和社会学的角度阐述了对这一观点的质疑。就目前而言，我们暂且假定这个推论正确会更有趣！如果传统的、闭源的、管理臃肿的软件开发模式只能托庇于一种令问题愈发枯燥的马其诺防线的话，那他们就要祈祷了，祈祷在每个领域都没人能发现问题的真正趣味，祈祷没人发现绕过防线的路径。因为对于“枯燥”的领域，一旦有开源软件加入战团，用户就会立刻明白——终于有人发现了问题的迷人之处并着手解决了！对软件业，如同其他的创造性工作一样，这比单一的金钱激励要有效的多。只是为了获取激励而采用传统的管理结构，也许是个好战术，但绝非优秀的战略——短期的胜利换来长效的溃败。说到这，传统开发管理和开源开发相比，在两点上（组织和资源监护）显然是不智之举，对于第三点（激励）则显得鼠目寸光。被团团包围的可怜的传统经理人也不会等到“监督”的任何援兵了。因为对于确保细节无一遗漏，开源社区强健的同行评议要胜过所有传统方法。我们能把“确立目标”留下来作为接受传统管理开销的理由吗？或许吧。如果这样做了，我们就必须有充分的理由相信这些管理委员会和社团有能力制定出更具远见卓识的目标，而且要做的比开源世界中同司此职的项目领导和“部族长老”们更加成功。这从表面上就很难说得通。并非开源一方的发难（Emacs的长寿？李纳斯以“统治世界”的说辞集结“游牧部落”的能力？）打破了平衡。相反，是传统模式对目标的制定令自己处境尴尬。这里有一个久负盛名的民间定理是关于软件工程的——60%到75%的传统软件项目要么半途而废了，要么就是被目标用户拒之门外了。如果这个数字和事实贴切的话（我至今还未曾遇到过有经验的管理者否认这点），那么就可以说大多数的项目都选错了目标，要么（a）不切实际，要么（b）错得离谱。这也正是如今软件工程领域大家一听到“管理委员会”就凉彻脊骨的原因，甚至（或者尤其）是当听众本身就是管理者的时候。原本只有程序员才会抱怨的日子早就过去了，现如今呆伯特[1]已经跳上了主管们的案头。给传统软件开发经理的答复很简单，如果真的只是开源社区低估了传统管理的价值，那么你们其中的许多人又何苦对自己的工作进程不屑一顾呢？开源社区的例子又一次把问题变得尖刻了——因为我们乐在其中。我们的创新游戏已经在技术上、市场份额上、以及观念上取得了惊人的成功晋级。我们正在证实，我们不仅可以创造更好的软件，并且（证实了）快乐是一种财富！本文第一版的两年半之后，我能用来收束本书的最激进的观点就已经不再是“开源领军软件世界”了。毕竟，如今许多西服革履的人[2]也认同了这种可能性。进而，我打算提出一则关于软件的更宽泛的经验（或许这事关每一种创新或专业工作）。人们通常在恰到好处的挑战中享受工作的乐趣。不要简单到兴味索然，也不要难到不切实际。一个既没有被浪费，也没有因为病态目标和进程冲突而不堪重负的程序员才是快乐的。乐趣决定效率。一旦你对自己的工作进程感到恐惧和厌恶（哪怕你改用悬挂呆伯特卡通这种改头换面的讽刺方式）通常就应该视作过程失败的信号。快乐、幽默、和趣味才是真正的财富。我不是为了押韵才选了“快乐部族”这个词，Linux用一只稚气未脱、让人想抱抱的企鹅当吉祥物也不是为了开玩笑的。或许，开源最重要的影响是教会了我们——乐趣才是创造性工作中最有用经济效能。译者按：1.呆伯特（Dilbert），是美国漫画家兼作家史考特·亚当斯(Scott Adams)的著名职场卡通人物。热爱科技，憨厚老实的呆伯特在工作上经常被主管过份要求、亏待或利用。如今dilbert（首字母小写）已经成为了一个动词。比如说 “I’m dilberted”就是说“我被老板欺负了”“工作太苛刻了”等等。可以从这里看到每日的新作：http://www.dilbert.com/2.西服革履：原文中作“people in suits”。黑客的生活是很自由的，不需要着正装。就算是公司的普通职员也只需着正装而不必穿套装（Suits）。所以这个说法通常被黑客用于指代和揶揄公司高管。3.本章中提及了作者的其他两部作品：《魔法大锅炉》和《开拓智域》。我采用的都是网上已有中文译版的译名