大教堂與市集十市集風格的先決條件

簡體傳統

十市集风格的先决条件
本文的早期审阅人和测试者不断地希望了解成功市集风格的先决条件，这包括项目负责人的资质和着手建立协作开发社区时代码的开放状况。
很明显，市集风格不能帮你从零开始编程。【注】你可以利用市集风格来测试、调试、改进代码，但是用这种风格来孕育一个项目会很困难的。李纳斯没有这样试过，我也没有。你初建的社区至少需要一个可以运行和测试的东西。
一旦你着手组建团队，就需要给出一个可行的承诺。你的程序并非必须运行良好，它可以是粗糙的、遍布瑕疵的、不完善的、也可以是缺少说明文件的。但是必须满足（1）它能运行；（2）能让潜在的协作开发者相信在不久的将来它能变得精良。
Linux和fetchmail都是在有了健硕，诱人的基础设计之后才推向公开的。我所提到的市集模式观察者们认为这是至关重要的。进而得出结论：一个睿智并且具备高超设计才能的领导是必不可少的。
但是李纳斯是从Unix出获得的设计，而我则是从早期的popclient（尽管日后改动很大，但是还无法和Linux相提并论）。那么，一个市集风格的领导者/主持人当真需要天赋异禀吗？或者他们只是四两拨千斤的动用了他人的创见？
在我看来一个项目的主持人是否能够做出足以彪炳的设计并不很关键。而至关重要的是，他是否可以从他人的创意中慧眼识英。
Linux和fetchmail都印证了这个观点。李纳斯（如同前文描述的那样），尽管不是一个惊世的原创设计者，但是却展现了识别优秀设计并整合成为Linux内核的不凡才能。我也曾描述了fetchmail中最强大独到的功能（SMTP转发）是如何源自他人的。
本文的早期读者捧我的场说我之所以容易低估市集项目中原创因素的价值，是因为我本身不缺乏创意灵感，所以就习以为常了。这番评论或许却有见地，因为（与编码和调试相比）设计确实是我的强项。
但是问题是，在软件设计中展现聪明和原创力会养成一种习惯——当你需要保持设计稳健和简洁的时候，会不自知把它们弄得有趣而复杂。我曾经因此搞砸过项目，所以在fetchmail的开发中我要避免重蹈覆辙。
所以我坚信fetchmail项目的成功应部分归因为我克制了自己的自作聪明；这（至少能够）反驳“原创设计制约市集模式成败”的观点。回头看Linux，假设李纳斯在开发操作系统核心时力主原创的话，我们现在还能见到如此稳健成功的内核吗？
一定的设计和编码技能是必须的。但是我想，任何一个深思熟虑准备试水市集项目的人都远远超出了这个底线。开源社区内部的声望机制给人们一种微妙的压力，从而大家不会去发起一些自己无力支撑的项目。目前看来，这行之有效。
我认为还有一种与软件开发无关的技能，却在市集项目中与优秀设计同等重要——甚至更胜一筹。那就是一个市集项目的主持人或领导者必须具备优秀的人际交流技能。
显而易见，要创建一个开发社区，你需要招募人手，让大家对你所做的感兴趣，并让大家对工作乐此不疲。为了达成这个目标，技术上的磨合必不可少，但却远不是故事的全部。与大家的人际融合也至关重要。
李纳斯平易近人，招人喜欢并让大家乐于帮助他——这并非偶然。我活波外向，喜欢群体工作，并且带有一些插科打诨的言谈和性情——这也绝非巧合。为了运营一个市集项目，哪怕是一点点人格魅力都对你大有助益！

注：
有关市集风格是否可以帮你从零开始构建一个项目的另一个争论是——其是否能够促成真正意义上的创新。有人声称，由于缺少强有力的领导。市集风格只能在工程学前沿克隆和演进已有创新，却无法孕育新知。这种垢弊极可能源自“万圣节文件”——两份微软内部旨在发难的开源现象备忘录。其作者认为，Linux不过是个拾人牙慧的类Unix系统，“（一旦这个计划具有了同等的领先水平）管理开销就必然变得异常庞大。”
这个观点和事实大相径庭，乃至文件作者后来自己也指出：“通常……创新首先出现在Linux上，其后才被推广/整合到其他平台。”
对我们而言，即使把上文中的“Linux”换成“开源软件”也算不得什么新鲜事。回顾历史，开源社区并没有拾人牙慧的开发出Emacs、万维网和因特网，同样也未曾担负过庞大的管理成本。现在开源项目的不断创新给我们提供了前所未有的施展空间。比如GNOME项目（信手拈来一例），已经达到了图形用户界面领域的顶尖水品。其复杂程度吸引了Linux社区外为数可观的商业关注。类似的例子不胜枚举，你可以抽空访问一下Freshmeat.net，一看便知。
其论断中还有一个本质的错误，即假定大教堂模式（或市集模式，亦或其他任何管理结构）可以顺理成章的产生革新。这是一派胡言。群体没有洞见创新的眼光——对此，市集模式中志愿组合的团队也往往无济于事。更不用说那些要为自己生计下注的社团委员会成员了。创新源自个体。其周围社会机制的最有效激励就是做出适当的回应——去培养、奖励、鞭策他们，而不是排挤。
一改过去“孤单发明家”的套路，有人会把这种创新方式描述的颇具浪漫色彩，然而事实远非如此；我并非断言团队无法再像过去那样在开发中创造突破；事实上，我们在平行开发中学到，对于高质量的产品，团队协作是必不可少的。但是我必须指出任何团队的组建都是源于某人的创想（这也是必要的火花）。无论大教堂、市集、还是其他模式都可以抓住这稍纵即逝的火花，并将它引燃。不过，它们都不能在有需要的时候就立即擦然火花。
所以说，（软件或其他领域）革新的根本问题是：首先，如何培养那么多能够创新的人才；以及如何避免排挤他们。
假定大教堂风格可以促成创新，而门槛低、流程通畅的市集模式则无能为力，显然是很荒谬的。如果创造源自一个人加一个好主意，那么能吸引成百上千人共同协作的社会环境必然优于一个必须通过政治手腕向上级推销创意的环境（为了避免不被炒鱿鱼，你必须在得到批准之后才能继续研发）。
确实，如果我们检视一下大教堂模式下的软件创新史，不难发现源自其自身的创造凤毛麟角。大企业需要通过大学中的研究获取新知（因此，万圣节文件的作者对Linux对研究成果的快速吸收深表不安）。或者收购一些由于某个创意而组建的小公司。这两种创新均非源自大教堂文化。恰恰相反，很多类似被买断的创见被（万圣节文件作者鼓吹的）“庞大的管理成本”扼杀了。
上面都是一些反证，这里应该把一个正面的例子奉献给读者。我建议大家试试下面的方法：
确立一个你能一以贯之的创新判别标准。比如“发现并加以区分（I know it when I see it）”就满足这个判别条件。
选择一款能和Linux竞争的闭源操作系统，和一个让你可以了解其开发进展的最佳资讯渠道。
在一个月内每天关注Freshmeat和你选择的消息渠道。分别记录下二者中你认为是创新的点子数。
三十天后，汇总两组数据。
在我写下这些文字的日子里，Freshmeat出现了22条新消息。其中有三条看似可以在某方面推动技术革新。虽然这几天Freshmeat不很景气，但是假如有读者在一个月内能通过任何闭源渠道发现这样的三条创新，就真的值得大书特书了。