注：本文为 "Alan Cox | Cathedrals, Bazaars and the Town Council" 相关合辑。
英文引文，机翻未校。
中文引文，略作重排。
未整理去重，如有内容异常，请看原文。
Cathedrals, Bazaars and the Town Council
Alan Cox, 1998
大教堂、市集与镇议会
These are some of my thoughts on the Bazaar model that I figure are worth sharing. Its also a guide to how to completely screw up a free software project. I've picked a classic example of what I think is best dubbed the "Town Council" effect (although town councillors may think otherwise).
以下是我关于市集模式的一些思考，我认为这些内容值得分享，同时也能说明如何彻底搞砸一个自由软件项目。我选取了一个典型案例，用以阐释我所说的 "镇议会效应"（尽管镇议员们可能并不认同这一说法）。
There are certain things you have to understand about software developers. The first thing to understand is that really good programmers are relatively unusual. Not only that but the difference between a true "real programmer" and the masses is significantly greater than that between "great" and "average" in many other professions. Studies have quoted 30 : 1 30:1 30:1 differences in productivity between the best and the rest.
关于软件开发人员，有几点必须明确。第一，真正优秀的程序员相对稀缺。不仅如此，一名资深程序员与普通从业者之间的差距，远大于许多其他行业中优秀从业者与普通从业者的差距。有研究表明，顶尖程序员与普通程序员的生产效率之比可达 30 : 1 30:1 30:1。
Secondly you need to understand that a lot of the wannabe real programmers are very good at having opinions. Many of them also catch buzzword disease or have some speciality they consider the "one true path". On the Internet talk is cheap.
第二，许多一心想成为资深程序员的人，总爱发表各种观点。他们中的不少人还会陷入术语堆砌的误区，或是将自己擅长的领域奉为 "唯一正确之路"。在网络上，空谈向来无需成本。
The third part of any software project is what we shall call "the masses". They range between people who don't program but contribute massively in other areas - documentation, helping users and artwork to the sort of people that are often used to argue that you should require a license to connect to the Internet.
任何软件项目中都存在一个群体，我们称之为 "普通参与者"。这一群体的构成跨度极大：有不会编程但在文档撰写、用户支持、视觉设计等领域做出巨大贡献的人，也有那些甚至主张 "接入互联网需要获得许可" 的极端者。
The project I'm going to take as an example of how to screw up completely is the Linux 8086 project. Porting a subset of Linux to the 8086 is one of the worlds more pointless exercises on the whole, and something that started as a joke and got out of hand.
我将以 Linux 8086 项目为例，说明如何彻底搞砸一个项目。整体而言，将 Linux 的一个子集移植到 8086 架构上，是世界上最无意义的尝试之一，这一项目最初只是一个玩笑，最终却逐渐失控。
There are a very small number of real programmers with the time and the right (or is that wrong) kind of mental state to contribute to a project whose sole real worth is "Hack Value". As a result of this at any given time the project has two or three core contributing people.
只有极少数资深程序员有时间、且愿意以这种（或许可以说是不合时宜的）心态，为一个唯一的实际价值仅在于 "技术探索价值" 的项目付出。这也导致该项目在任一阶段，核心贡献者都只有两三个人。
Unfortunately there are a lot of people who think it would be neat to run Linux on an 8086 who feel obliged to "take part". Most of them in this case are in the "wannabe programmer" category as the masses spotted the "silly" factor of the project from a safe distance.
遗憾的是，许多人觉得能在 8086 架构上运行 Linux 是件很酷的事，于是执意要参与其中。在这个案例中，这些人大多属于 "一心想成为程序员的群体"，而普通参与者则早已远远看出了这个项目的不合理之处。
The problem that started to arise was the arrival of a lot of (mostly well meaning) and dangerously half clued people with opinions - not code, opinions. They knew enough to know how it should be written but most of them couldn't write "hello world" in C. So they argue for weeks about it and they vote about what compiler to use and whether to write one - a year after the project started using a perfectly adequate compiler. They were busy debating how to generate large model binaries while ignoring the kernel swapper design.
项目的问题开始浮现：大量一知半解的人涌入其中，他们大多初衷不坏，却带来了极大的负面影响 ------ 这些人只懂发表观点，而非编写代码。他们自认为知道项目该如何开发，可其中大多数人甚至无法用 C 编写 "Hello World" 程序。项目启用的编译器本已完全够用，可一年后，他们还为使用何种编译器、是否需要自研编译器争论数周，甚至还进行投票。他们一心争论如何生成大模式二进制文件，却对内核交换程序的设计视而不见。
Linux 8086 went on, the real developers have many of the other list members in their kill files so they can communicate via the list and there are simply too many half clued people milling around. It ceased to be a bazaar model and turns into a core team, which to a lot of people is a polite word for a clique. It is an inevitable defensive position in the circumstances.
Linux 8086 项目仍在继续，资深开发者将邮件列表中的许多人加入了屏蔽列表，才能正常通过列表沟通，而项目中仍有大量一知半解的人在四处搅局。这个项目不再是市集模式，转而变成了核心团队模式，而在很多人看来，"核心团队" 不过是 "小圈子" 的委婉说法。在这种情况下，这是一种无可避免的防御性举措。
In the Linux case the user/programmer base grew slowly and it grew from a background group of people who did contribute code and either had a basis in the original Minix hacking community or learned a few things the hard way reboot by reboot. As the project grew people who would have turned into "The committee for the administration of the structural planning of the Linux kernel" instead got dropped in an environment where they were expected to deliver and where failure wasn't seen as a problem. To quote Linus "show me the source".
反观 Linux 主项目，其用户和程序员群体的增长速度缓慢，且最初的参与者都是真正贡献代码的人：他们要么出身于早期 Minix 黑客社区，要么通过一次次重启试错，在实践中积累经验。随着项目发展，那些本可能成立 "Linux 内核结构规划管理委员会" 的人，身处的环境要求他们拿出实际成果，且失败并不会被视作问题。用林纳斯的话来说，就是 "拿出代码来"。
If someone got stuck they posted questions and there was and is a sufficiently large base that someone normally has both the time and the knowledge to reply. In the Linux8086 case the developers had long since walled themselves off. Given a better ratio of active programmers to potentially useful wannabe programmers would have rapidly turned some of the noise into productivity. The project would have gained more useful programmers and they in turn would have taught others. As with any learning exercise you are better off having only a few trainees.
在 Linux 主项目中，有人遇到问题时会发布提问，而项目的参与者基数一直足够大，总会有人有时间、有能力给出解答。但 Linux 8086 项目的开发者早已陷入了自我封闭的状态。如果活跃程序员与有潜力的准程序员之间的比例更为合理，项目中的诸多无意义争论本可以迅速转化为实际生产力。项目本可以培养出更多优秀的程序员，而这些程序员又能反过来帮助其他人成长。正如任何学习过程一样，学徒的数量宜少不宜多。
There is an assumption some people make that you can't turn the "lesser programmers" into real programmers. From personal experience in the Linux project there are plenty of people who given a little help and a bit of confidence boosting will become one with the best. There are many who won't but enough that will. [1]
有些人认为，普通程序员无法成长为资深程序员。但从我在 Linux 项目中的亲身经历来看，许多人只需一点帮助和鼓励，建立起信心，就能跻身优秀程序员的行列。当然，并非所有人都能做到，但做到的人数量已然足够。[1]
The Linux 8086 project has mostly recovered from its 'infestation' and is now a small quiet project, using CVS trees and led by Alastair Riddoch who has been doing a sterling job. With the town councillors De-camped its now possible to ask questions, join in and help the project.
如今，Linux 8086 项目已基本摆脱了此前的乱象，成为一个规模不大、发展平稳的项目。该项目采用 CVS 代码树进行管理，由阿拉斯泰尔・里多克领导，他在任上的工作表现十分出色。那些如同 "镇议员" 一般空谈的人离开后，人们终于可以在项目中正常提问、参与开发并提供帮助了。
The lessons from this project, and others that went the same way (and sometimes died - remember the earlier Linux word processor projects) are fairly clear:
从这个项目，以及其他重蹈覆辙的项目（有些甚至已夭折 ------ 还记得早期的 Linux 文字处理软件项目吗）中，我们可以总结出十分明确的经验教训：
-
Release code right from the start. It doesn't matter if its not very useful. The best way to sort a town council is to simply do the job then tell them it has been done. Linux, KDE and GNOME have all taken this attitude and all done well from it. You can argue about the right way to program for a lifetime. Once there is code out there people (whatever their skill) can play with it.
从项目初期就发布代码，即便这些代码暂时没有实际用处也无妨。解决 "镇议会效应" 的最佳方式，就是干脆直接完成工作，再告知他们结果。Linux、KDE 和 GNOME 均秉持这一理念，也都取得了良好的发展。关于编程的正确方式，人们可以争论一辈子，但一旦有实际代码面世，无论技术水平高低，所有人都能参与其中、实践探索。
-
Appreciate there are people who with a bit of help will contribute very much to a project. If their first patches are buggy don't put them down, explain why there is a problem and suggest solutions or places to look for examples of solutions. Every minute spent answering real questions helping someone work on a project will be paid back ten-fold to the project, and incalculably to society.
要意识到，许多人只需一点帮助，就能为项目做出巨大贡献。如果他们提交的首个补丁存在漏洞，不要贬低他们，而是向其解释问题所在，并给出解决方案建议，或是告知其可以参考的案例。为解答实际问题、帮助他人参与项目所花费的每一分钟，最终都会为项目带来十倍的回报，为社会带来难以估量的价值。
-
Don't forget non programmers. I find it sad that many people when asked "name the most important five Linux kernel people" rarely name some of the most important folk of all - the all to forgotten people who maintain web sites, change logs, mailing lists and documentation are as important. Linus says "Show me the code". That is a narrow view of a real project. When you hear "I'd love to help but I can't program", you hear a documenter. When they say "But English is not my first language" you have a documenter and translator for another language.
不要忽视非程序员群体。当被问及 "说出五位对 Linux 内核最重要的人" 时，许多人都极少提及那些真正关键的人，这让我感到遗憾 ------ 维护网站、更新变更日志、管理邮件列表、撰写文档的人常常被遗忘，而他们的作用同样重要。林纳斯说 "拿出代码来"，但这一观点对于一个真正的项目而言过于狭隘。当你听到有人说 "我很想帮忙，但我不会编程"，你看到的是一位潜在的文档撰写者；当他们接着说 "我的母语不是英语"，你看到的是一位潜在的多语言文档撰写者与翻译者。
-
Try and separate useful people from the noise. It is hard to separate people trying to help from a mass of pointless discussion and in the Linux 8086 case I definitely did the wrong thing by giving up on that goal. How to remove just those who talk and do not do anything is a research topic 8).
尝试将有实际贡献的人与无意义的争论隔离开。要从大量无意义的讨论中区分出真正想要提供帮助的人，并非易事。在 Linux 8086 项目中，我选择放弃这一努力，这无疑是错误的。如何精准剔除那些只说不做的人，仍是一个值得研究的课题。
So next time someone wants to vote on a project, or discuss issues for a month and then implement it - be warned. They may end up with the right solution. The odds are however in your favour for carrying on regardless. Just ask them to send you a patch when it works.
因此，下次如果有人想要对项目事宜进行投票，或是计划先讨论一个月再着手开发时，你需要保持警惕。他们或许最终能得出正确的解决方案，但更大概率的是，你坚持按自己的方式推进项目，会取得更好的结果。只需告诉他们：等做出实际成果，再提交补丁即可。
Beware "We should", extend a hand to "How do I"...
对满口 "我们应该做什么" 的人保持警惕，向询问 "我该怎么做" 的人伸出援手。
Alan
艾伦
1\] As an example of this claim the original author of the Linux IPv6 code used to sit on irc from Portugal playing with a few basic ideas and asking questions. After we helped him figure some of the kernel internals he wrote probably 75 % 75\\% 75% of the Linux IPv6 stack and was last seen working in the USA for cisco. \[1\] 关于这一点，有一个典型案例：Linux IPv6 协议栈的初代开发者最初在葡萄牙通过互联网中继聊天工具，摸索一些基础思路，同时提出各种问题。在我们帮助他理解了部分内核底层原理后，他编写了 Linux IPv6 协议栈中约 75 % 75\\% 75% 的代码，据悉他后来任职于美国思科公司。 *** ** * ** *** ## Alan Cox：大教堂、市集与市议会 2013 年 07 月 08 日 Leo （感谢网友 [@我的上铺叫路遥](http://weibo.com/fullofbull) 投稿） 在网上搜到的 Cox 大叔于 1998 年在开源社区写的一篇文章，当时很轰动，明眼人一看就知道是针对 ESR 那篇《大教堂与市集》，从中可见 Alan 在项目管理风格上乃至个人性格上都与 ESR、Linus 等人不同之处。顺便说一句，Alan 现在出于 "家庭原因" 已经离开了 Linux 项目，他曾经评价 Linus 是 [a good developer but a terrible engineer](http://apolyton.net/showthread.php/130212-Linus-Torvalds-is-a-terrible-engineer-Alan-Cox)，甚至在 Google + 上直接说 Linus 就是一 a\*sh\*\*e。不管如何，两位曾经十余年里并肩战斗惺惺相惜的大牛就此分道扬镳还是惹人唏嘘。 言归正传，以下为 slashdot 收录的英文原文：[Cathedrals, Bazaars and the Town Council](http://news.slashdot.org/story/98/10/13/1423253/featurecathedrals-bazaars-and-the-town-council)。 以下是一些我对市集模式的想法，我认为这值得分享，这种模式会教你如何完全毁掉一个自由软件项目。我还举了一个我称之为 "市议会"(Town Council) 效应的实例（虽然那些市议员们可不这么认为，注：此处指 Linux 项目开发者）。 关于软件开发人员，你必须去了解一些情况。首先要了解的是真正优秀的程序员相对来说并不普遍，不仅如此，在很多其它专业领域里 "真正的程序员" 和一些捣乱的家伙之间的区别要比 "伟大" 和 "普通" 之间的区别要大得多，研究表明生产效率上最好的同其余的比重是 30:1。 其次，你需要了解的是一大堆妄想型码农 (wannabe programmer) 总是善于发表意见。其中很多人患上了一种叫做 "流行性热词"(buzzword) 疾病，或者对他们 "非黑即白"(one true path) 的思考方式有着特殊的偏执，网上很多讨论都是廉价的。 第三个关于软件项目的事情就是我们所谓的 "闲杂人员"(the masses)。他们不是编程人员，而在其它方面有着大量贡献 ------ 文档编辑、用户支持，以及对那类经常争论你应该获得许可证才能上网的人的说服工作。 我想以 Linux 8086（注，Intel 设计的 16 位处理器架构）为例来说明如何将整个工程全部搞砸。将 Linux 的一个子集移植到 8086 上大体是这世上最无聊的活动之一。整件事的发起就像个笑话并走向失控。 只有极少数真正的程序员会将时间及其良好的精神状态（或许那是假的）花费在那些唯一价值在于 "黑客精神"(Hack Value) 的项目上，故而在任何时候那种项目也就两三个核心贡献人员而已。 不幸的是大批人认为将 Linux 运行在 8086 上是干净的，为此义不容辞地想要 "入伙"。这类人大多属于妄想型码农之流，以至于连闲杂人员在一个安全距离之外都会沾染上这个项目的 "愚蠢" 因子。 问题的导火索在于一大批充满（大多善意的）危险的一知半解的人们的意识观念 ------ 不是代码，而是意识观念。他们似乎很懂得如何去编程，但很多人连 "Hello World" 这样的 C 程序都不会。他们花了几星期时间去争论并投票该使用什么编译器，甚至在项目开展一年后还在争论是否去写个充分完美的编译器。他们热衷于辩论如何生成大量二进制文件，却又对内核 swapper（注，即 idle task）设计一无所知。 Linux 8086 项目仍然进行着，真正的开发人员将邮件列表里许多其他成员加入到清除文件 (kill files) 中，以便他们之间可以顺畅地通过邮件列表沟通，只因半吊子打酱油的家伙实在太多了。这一切不再是市集模式，而是形成了一个核心小组，对圈子里许多人而言这是一种礼貌用语。在这种情形下人们不可避免地处于被动位置。 像 Linux 这种基于用户 / 程序员的项目成长缓慢，虽然它是靠着一群贡献代码的人得以成长起来，但这些人的背景要么是从原始的 Minix（注，一种微内核操作系统）黑客社区起家，要么通过艰难的方式不断从头学起。随着项目增长，人们本应该形成一个 "Linux 内核结构规划管理委员会"，而不是掉入将人们招来唤去，不将失败视为问题的怪圈，用 Linus 的话来说就是 "给我看源码"。 如果有人陷入困境，他可以发帖询问，在这之前包括现在很大程度上都基于人们正常地拥有时间并具备知识来回复他。在 Linux 8086 的案例中，开发人员很长一段时间身陷囹圄。假使主动活跃的程序员对只有潜在用处的妄想型码农的比例更高一点的话，我们就可以将一些杂音转化成生产力。项目也就获得更多有用的程序员，他们可以轮流向他人传授经验，任何学习活动都会让你变得更好，哪怕只有一些少量实习生。 一些人会认为你无法将那些 "次要程序员"(lesser programmer) 训练成真正的程序员。就 Linux 项目的个人经验而言，很多人员只要获得一丁点儿的帮助和自信鼓励都将成为世界上最好的开发人员之一。只要帮助和鼓励足够多，很多人就能成功。 Linux 8086 总算大部分从 "侵扰" 中恢复过来，可至今仍是个不起眼的小项目。你可以从 CVS 目录树上下载这个由 Alistair Riddich 领导的项目，他做了很多优秀的工作。随着市议员的撤出，人们可以询问、参与并改善这个项目。 我们从这个项目，还有其它相同命运的早期 Linux 16 位处理器项目（有的已死）中很清楚地学到以下几点教训。 * 从项目一开始就发布源代码。哪怕不是很有用也无关紧要，将市议会排序分类的最好方式就是发布源代码并告知人们。Linux、KDE 以及 GNOME 都遵循这种方式并获益良多。你可以花一辈子时间去争论怎样写代码才是正确的。只要代码公布，人们（不管水平怎样）都会把玩它。 * 要欣赏那些给一点帮助就会对项目做出巨大贡献的人。如果他们最初的补丁有错误，不要盛气凌人，向其解释问题出在哪里并给出解决方案的建议，或者可以查询解决方法的地方。解答真正的问题，帮助别人，你所花费的一分一秒都会成十倍地回报在项目上，对社会也会带来无法估量的好处。\[注
-
不要忘记那些非开发人员。我难过地发现许多人问起 "前 5 名最重要的内核成员" 时却极少涉及在所有人中最重要的一些 ------ 他们负责维护网站，更新日志和邮件列表，还有编辑文档，这些都是同等重要。
Linus 那句 "给我看源代码" 对真正的项目来说是个狭隘的视角。当你听到人们说 "我很想帮忙，可我不会编程"，那么他可以从事文档编写。当人们说 "但英语不是我的第一语言"，这时你需要的是一位文档编辑或另一门语言翻译者。
-
尝试将有用的人从杂音中分离出来，将有意愿帮忙的人从一大堆无聊评论中分离出来是很难的。在 Linux 8086 项目中我的确错误地放弃了这一目标，如何将那些只会空谈而又无所事事的人弄走是一门学问。
下次碰到人们在项目上投票，或者问题讨论了一个月才实现这类情况，给予他们警告。这样才能使人正确地解决问题。在你看来如果一些稀奇古怪的事务不顾一切地运行着，要求他们给你发个补丁，只要能够生效的话。
小心地说 "我们应该怎样" 之类的话，对 "我该如何做" 这样的人伸出援手。
Alan
注\] 这段话举个例子说明一下。Linux IPv6 源码作者以前在葡萄牙上网聊天，只会简单讨论和问一些基本问题。我们助其弄明白一些内核原理之后，他写了大约 75% 的 IPv6 协议栈代码，他最近受聘于美国思科公司。
附录一：一篇针对本文的 [吐槽贴](http://tech.groups.yahoo.com/group/java-os-project/message/2358?var=1&p=1)
附录二：2009 年 Cox 回复 Torvalds 的 [邮件](https://lkml.org/lkml/2009/7/28/375)，事情起因是 Cox 的一个 tty patch 导致 [kdesu (KDE project's su utility)](https://lkml.org/lkml/2009/7/11/125) 程序无法工作，该问题争论长达两个星期，此后 Alan 离开了 Linux 项目投奔 Intel。
*** ** * ** ***
## **开源开发模式：ESR 的理论奠基与 Alan Cox 的实践修正**
### 人物与贡献
| Eric S. Raymond（ESR） | 发起、理论构建 | 1997 年首创"教堂/市集"二分框架，定义开源开发模式的关键讨论维度；1999 年修订完善 19 条实践原则；通过持续传播奠定该主题的理论基础。 |
|:---------------------|:----------|:---------------------------------------------------------------------------|
| Alan Cox | 回应者、实践补充者 | 1998 年针对 ESR 理论提出"市议会"效应，警示非技术贡献者过度参与导致的决策内耗，以 Linux 8086 项目为例补充市集模式的实践边界。 |
**ESR 著作**
* 《The Cathedral and the Bazaar》英文版：Satoshi Nakamoto Institute 收录（1997 年初稿，1999 年修订），Monoskop 收录 PDF 修订版
* 中译本：台湾 Linux 网站《教堂與市集》
**Alan Cox 文章**
* 英文原文：《Cathedrals, Bazaars and the Town Council》，Slashdot 1998 年 10 月 13 日发布
* 中文解读：CoolShell《大教堂、市集与市议会》（含背景注解）
| 时间 | 事件 | 性质 |
|:------------|:--------------------------------------------|:-----|
| 1997 年 5 月 | ESR 于 OSCON 演讲，首次公开"教堂模式""市集模式"及林纳斯定律 | 理论诞生 |
| 1998 年 10 月 | Alan Cox 在 Slashdot 发文回应，提出"市议会"效应 | 实践修正 |
| 1999 年 | ESR 修订论文，补充网景开源案例，完善 19 条原则 | 理论完善 |
| 2000 年 | O'Reilly 正式出版《The Cathedral and the Bazaar》 | 书籍出版 |
### 总结
1. ESR 框架早在 1997 年已通过演讲和网络论文公开，2000 年修订后的商业出版。
2. Alan Cox 1998 年的文章是对已传播 1 年多的 ESR 理论的实践反馈。
3. ESR 原文"First written 1997, revised 1999"；Cox 文章多次引用 ESR 关于市集模式的观点。
*** ** * ** ***
* Eric S. Raymond \| the Cathedral And The Bazaar-CSDN博客