T
tqz
Unregistered / Unconfirmed
GUEST, unregistred user!
提交者
新闻组
hansb@263.net
在 09-14 在 08:37 PM
Magazine
大教堂和集市
**** 大教堂和集市 ****
一. 大教堂和市集Linux的影响是非常巨大的。甚至在５年以前，有谁能够想象一个世界级的操作系统能够仅仅用细细的
Internet连接起来的散布在全球的几千个开发人员有以业余时间来创造呢？
我当然不会这么想。在１９９３年早期我开始注意Linux时，我已经参与Unix和自由软件开发达十年之久了。
我是八十年代中期GNU最早的几个参与者之一。我已经在网上发布了大量的自由软件，开发和协助开发了几个
至今仍在广泛使用的程序（Nethack,Emacs VC和GND模式，xlife等等）。我想我知道该怎样做。
Linux推翻了许多我认为自己明白的事情。我已经宣扬小工具、快速原型和演进式开发的Unix福音多年了。但
是我也相信某些重要的复杂的事情需要更集中化的，严密的方法。我相信多数重要的软件（操作系统和象
Emacs一样的真正大型的工具）需要向建造大教堂一样来开发，需要一群于世隔绝的奇才的细心工作，在成功
之前没有beta版的发布。
Linus Torvalds的开发风格（尽早尽多的发布，委托所有可以委托的事，对所有的改动和融合开放）令人惊
奇的降临了。这里没有安静的、虔诚的大教堂的建造工作——相反，Linux团体看起来像一个巨大的有各种不
同议程和方法的乱哄哄的集市（Linux归档站点接受任何人的建议和作品，并聪明的加以管理），一个一致而
稳定的系统就象奇迹一般从这个集市中产生了。
这种设计风格确实能工作，并且工作得很好，这个事实确实是一个冲击。在我的研究过程中，我不仅在单个
工程中努力工作，而且试图理解为什么Linux世界不仅没有在一片混乱中分崩离析，反而以大教堂建造者们不
可想象的速度变得越来越强大。
到了１９９６年中，我想我开始理解了。我有一个极好的测试我的理论的机会，以一个自由软件计划的形
式，我有意识的是用了市集风格。我这样做了，并取得了很大的成功。
在本文的余下部分，我将讲述这个计划的故事，我用它来明确一些自由软件高效开发的格言。并不是所有这
些都是从Linux世界中学到的，但我们将看到Linux世界给予了它们一个什么样的位置。如果我是正确的，它
们将使你理解是什么使Linux团体成为好软件的源泉，帮助你变得更加高效。
二. 邮件必须得通过
１９９３年以前我在一个小的免费访问的名为Chester County InterLink的ISP的做技术工作，它位于
Pennsylvania的West Chester。（我协助建立了CCIL，并写了我们独特的多用户BBS系统——你可以telnet到
locke.ccil.org来检测一下。今天它在十九条线上支持三千的用户）。这个工作使我可以一天二十四小时通
过CCIL的56K专线连在网上，实际上，它要求我怎么做！
所以，我对Internet email很熟悉。因为复杂的原因，很难在我家里的机器（snark.thyrsus.com）和CCIL之
间用SLIP工作。最后我终于成功了，但我发现不得不时常telnet到locke来检查我的邮件，这真是太烦了。我
所需要的是我的邮件发送到snark,这样biff(1)会在它到达时通知我。
简单地sendmail的转送功能是不够的，因为snark并不是总在网上而且没有一个静态地址。我需要一个程序通
过我的SLIP连接把我的本地发送的邮件拉过来。我知道这种东西是存在的，它们大多使用一个简单的协议POP
（Post Office Protocol）。而且，locke的BSD/OS操作系统已经自带了一个POP3服务器。
我需要一个POP3客户。所以我到网上去找到了一个。实际上，我发现了三、四个。我用了一会pop-perl，但
它却少一个明显的特征：抽取收到的邮件的地址以便正确回复。
问题是这样的：假设locke上一个叫“joe”的人向我发了一封邮件。如果我把它取到snark上准备回复时,我
的邮件程序会很高兴地把它发送给一个不存在的snark上的“joe”。手工的在地址上加上“@ccil.org”变成
了一个严酷的痛苦。
这显然应是计算机替我做的事。（实际上，依据RFC1123的5.2.18节，sendmail应该做这件事）。但是没有一
个现存的POP客户知道怎样做！于是这就给我们上了第一课：
1.每个好的软件工作都开始于搔到了开发者本人的痒处。
也许这应该是显而易见的（“需要是发明之母”长久以来就被证明是正确的），但是软件开发人员常常把他
们的精力放在它们既不需要也不喜欢的程序，但在Linux世界中却不是这样——这解释了为什么从Linux团体
中产生的软件质量都如此之高。
那么，我是否立即投入疯狂的工作中，要编出一个新的POP3客户与现存的那些竞争呢？才不是哪！我仔细考
察了手头上的POP工具，问自己“那一个最接近我的需要？”因为：
2.好程序员知道该写什么，伟大的程序员知道该重写（和重用）什么。
我并没有声称自己是一个伟大的程序员，可是我试着效仿他们。伟大程序员的一个重要特点是建设性的懒
惰。他们知道你是因为成绩而不是努力得到奖赏，而且从一个好的实际的解决方案开始总是要比从头干起容
易。
例如，Linux并不是从头开始写Linux的。相反的它从重用Minix（一个386机型上的类似Unix的微型操作系
统）的代码和思想入手。最后所有的Minix代码都消失或被彻底的重写了，但是当它们在的时候它为最终成为
Linux的雏形做了铺垫。
秉承同样的精神，我去寻找良好编码的现成的POP工具，用来作为基础。
Unix世界中的代码共享传统一直对代码重用很友好（这正是为什么GNU计划不管Unix本身有多么保守而选取它
作为基础操作系统的原因）。Linux世界把这个传统推向技术极限：它有几个T字节的源代码可以用。所以在
Linux世界中花时间寻找其他几乎足够好的东西，会比在别处带来更好的结果。
这也适合我。加上我先前发现的，第二次寻找找到了9个候选者——fetchPOP，PopTart，get-mail，gwpop，
pimp，pop-perl，popc，popmail 和 upop）。我首先选定的是“fetchpop”。我加入了头标重写功能，并且
做了一些被作者加入他的1.9版中的改进。
但是几个星期之后，我偶然发现了Carl Harris写的“popclient”的代码，然后发现有个问题，虽然
fetchpop有一些好的原始思想(比如它的守护进程模式)，它只能处理pop3，而且编码的水平相当业余
(Seung-Hong是个很聪明但是经验不足的程序员)，Carl的代码更好一些，相当专业和稳固，但他的程序缺少
几个重要的相当容易实现的fetchpop的特征(包括我自己写的那些)。
继续呢还是换一个? 如果换一个的话，作为得到一个更好开发基础的代价，我就要扔掉我已经有的那些代
码。
换一个的一个实际的动机是支持多协议，pop3是用的最广的邮局协议，但并非唯一一个，Fetchpop和其余几
个没有实现POP2.RPOP，或者APOP，而且我还有一个为了兴趣加入IMAP(Internet Message Access
Protocol，最近设计的最强大的邮局协议)的模糊想法。
但是我有一个更加理论化的原因认为换一下会是一个好主意，这是我在Linux很久以前学到的：
3.“计划好抛弃，无论如何，你会的”(Fred Brooks,《神秘的人月》第11章)
或者换句话说，你常常在第一次实现一个解决方案之后才能理解问题所在，第二次你也许才足够清楚怎样做
好它，因此如果你想做好，准备好推翻重来至少一次。
好吧(我告诉自己)，对fetchpop的尝试是我第一次的尝试，因此我换了一下。
当我在1996年6月25日把我第一套popclient的补丁程序寄给Carl Harris之后，我发现一段时间以前他已经对
popclient基本上失去了兴趣，这些代码有些陈旧，有一些次要的错误，我有许多修改要做，我们很快达成一
致，我来接手这个程序。不知不觉的，这个计划扩大了，再也不是我原先打算的在已有的pop客户上加几个次
要的补丁而已了，我得维护整个的工程，而且我脑袋里涌动着一些念头要引起一个大的变化。
在一个鼓励代码共享的软件文化里，这是一个工程进化的自然道路，我要指出：
4. 如果你有正确的态度，有趣的问题会找上你的，但是Carl Harris的态度甚至更加重要，他理解：
5.当你对一个程序失去兴趣时，你最后的责任就是把它传给一个能干的后继者。
甚至没有商量，Carl和我知道我们有一个共同目标就是找到最好的解决方案，对我们来说唯一的问题是我能
否证明我有一双坚强的手，他优雅而快速的写出了程序，我希望轮到我时我也能做到。
新闻组
hansb@263.net
在 09-14 在 08:37 PM
Magazine
大教堂和集市
**** 大教堂和集市 ****
一. 大教堂和市集Linux的影响是非常巨大的。甚至在５年以前，有谁能够想象一个世界级的操作系统能够仅仅用细细的
Internet连接起来的散布在全球的几千个开发人员有以业余时间来创造呢？
我当然不会这么想。在１９９３年早期我开始注意Linux时，我已经参与Unix和自由软件开发达十年之久了。
我是八十年代中期GNU最早的几个参与者之一。我已经在网上发布了大量的自由软件，开发和协助开发了几个
至今仍在广泛使用的程序（Nethack,Emacs VC和GND模式，xlife等等）。我想我知道该怎样做。
Linux推翻了许多我认为自己明白的事情。我已经宣扬小工具、快速原型和演进式开发的Unix福音多年了。但
是我也相信某些重要的复杂的事情需要更集中化的，严密的方法。我相信多数重要的软件（操作系统和象
Emacs一样的真正大型的工具）需要向建造大教堂一样来开发，需要一群于世隔绝的奇才的细心工作，在成功
之前没有beta版的发布。
Linus Torvalds的开发风格（尽早尽多的发布，委托所有可以委托的事，对所有的改动和融合开放）令人惊
奇的降临了。这里没有安静的、虔诚的大教堂的建造工作——相反，Linux团体看起来像一个巨大的有各种不
同议程和方法的乱哄哄的集市（Linux归档站点接受任何人的建议和作品，并聪明的加以管理），一个一致而
稳定的系统就象奇迹一般从这个集市中产生了。
这种设计风格确实能工作，并且工作得很好，这个事实确实是一个冲击。在我的研究过程中，我不仅在单个
工程中努力工作，而且试图理解为什么Linux世界不仅没有在一片混乱中分崩离析，反而以大教堂建造者们不
可想象的速度变得越来越强大。
到了１９９６年中，我想我开始理解了。我有一个极好的测试我的理论的机会，以一个自由软件计划的形
式，我有意识的是用了市集风格。我这样做了，并取得了很大的成功。
在本文的余下部分，我将讲述这个计划的故事，我用它来明确一些自由软件高效开发的格言。并不是所有这
些都是从Linux世界中学到的，但我们将看到Linux世界给予了它们一个什么样的位置。如果我是正确的，它
们将使你理解是什么使Linux团体成为好软件的源泉，帮助你变得更加高效。
二. 邮件必须得通过
１９９３年以前我在一个小的免费访问的名为Chester County InterLink的ISP的做技术工作，它位于
Pennsylvania的West Chester。（我协助建立了CCIL，并写了我们独特的多用户BBS系统——你可以telnet到
locke.ccil.org来检测一下。今天它在十九条线上支持三千的用户）。这个工作使我可以一天二十四小时通
过CCIL的56K专线连在网上，实际上，它要求我怎么做！
所以，我对Internet email很熟悉。因为复杂的原因，很难在我家里的机器（snark.thyrsus.com）和CCIL之
间用SLIP工作。最后我终于成功了，但我发现不得不时常telnet到locke来检查我的邮件，这真是太烦了。我
所需要的是我的邮件发送到snark,这样biff(1)会在它到达时通知我。
简单地sendmail的转送功能是不够的，因为snark并不是总在网上而且没有一个静态地址。我需要一个程序通
过我的SLIP连接把我的本地发送的邮件拉过来。我知道这种东西是存在的，它们大多使用一个简单的协议POP
（Post Office Protocol）。而且，locke的BSD/OS操作系统已经自带了一个POP3服务器。
我需要一个POP3客户。所以我到网上去找到了一个。实际上，我发现了三、四个。我用了一会pop-perl，但
它却少一个明显的特征：抽取收到的邮件的地址以便正确回复。
问题是这样的：假设locke上一个叫“joe”的人向我发了一封邮件。如果我把它取到snark上准备回复时,我
的邮件程序会很高兴地把它发送给一个不存在的snark上的“joe”。手工的在地址上加上“@ccil.org”变成
了一个严酷的痛苦。
这显然应是计算机替我做的事。（实际上，依据RFC1123的5.2.18节，sendmail应该做这件事）。但是没有一
个现存的POP客户知道怎样做！于是这就给我们上了第一课：
1.每个好的软件工作都开始于搔到了开发者本人的痒处。
也许这应该是显而易见的（“需要是发明之母”长久以来就被证明是正确的），但是软件开发人员常常把他
们的精力放在它们既不需要也不喜欢的程序，但在Linux世界中却不是这样——这解释了为什么从Linux团体
中产生的软件质量都如此之高。
那么，我是否立即投入疯狂的工作中，要编出一个新的POP3客户与现存的那些竞争呢？才不是哪！我仔细考
察了手头上的POP工具，问自己“那一个最接近我的需要？”因为：
2.好程序员知道该写什么，伟大的程序员知道该重写（和重用）什么。
我并没有声称自己是一个伟大的程序员，可是我试着效仿他们。伟大程序员的一个重要特点是建设性的懒
惰。他们知道你是因为成绩而不是努力得到奖赏，而且从一个好的实际的解决方案开始总是要比从头干起容
易。
例如，Linux并不是从头开始写Linux的。相反的它从重用Minix（一个386机型上的类似Unix的微型操作系
统）的代码和思想入手。最后所有的Minix代码都消失或被彻底的重写了，但是当它们在的时候它为最终成为
Linux的雏形做了铺垫。
秉承同样的精神，我去寻找良好编码的现成的POP工具，用来作为基础。
Unix世界中的代码共享传统一直对代码重用很友好（这正是为什么GNU计划不管Unix本身有多么保守而选取它
作为基础操作系统的原因）。Linux世界把这个传统推向技术极限：它有几个T字节的源代码可以用。所以在
Linux世界中花时间寻找其他几乎足够好的东西，会比在别处带来更好的结果。
这也适合我。加上我先前发现的，第二次寻找找到了9个候选者——fetchPOP，PopTart，get-mail，gwpop，
pimp，pop-perl，popc，popmail 和 upop）。我首先选定的是“fetchpop”。我加入了头标重写功能，并且
做了一些被作者加入他的1.9版中的改进。
但是几个星期之后，我偶然发现了Carl Harris写的“popclient”的代码，然后发现有个问题，虽然
fetchpop有一些好的原始思想(比如它的守护进程模式)，它只能处理pop3，而且编码的水平相当业余
(Seung-Hong是个很聪明但是经验不足的程序员)，Carl的代码更好一些，相当专业和稳固，但他的程序缺少
几个重要的相当容易实现的fetchpop的特征(包括我自己写的那些)。
继续呢还是换一个? 如果换一个的话，作为得到一个更好开发基础的代价，我就要扔掉我已经有的那些代
码。
换一个的一个实际的动机是支持多协议，pop3是用的最广的邮局协议，但并非唯一一个，Fetchpop和其余几
个没有实现POP2.RPOP，或者APOP，而且我还有一个为了兴趣加入IMAP(Internet Message Access
Protocol，最近设计的最强大的邮局协议)的模糊想法。
但是我有一个更加理论化的原因认为换一下会是一个好主意，这是我在Linux很久以前学到的：
3.“计划好抛弃，无论如何，你会的”(Fred Brooks,《神秘的人月》第11章)
或者换句话说，你常常在第一次实现一个解决方案之后才能理解问题所在，第二次你也许才足够清楚怎样做
好它，因此如果你想做好，准备好推翻重来至少一次。
好吧(我告诉自己)，对fetchpop的尝试是我第一次的尝试，因此我换了一下。
当我在1996年6月25日把我第一套popclient的补丁程序寄给Carl Harris之后，我发现一段时间以前他已经对
popclient基本上失去了兴趣，这些代码有些陈旧，有一些次要的错误，我有许多修改要做，我们很快达成一
致，我来接手这个程序。不知不觉的，这个计划扩大了，再也不是我原先打算的在已有的pop客户上加几个次
要的补丁而已了，我得维护整个的工程，而且我脑袋里涌动着一些念头要引起一个大的变化。
在一个鼓励代码共享的软件文化里，这是一个工程进化的自然道路，我要指出：
4. 如果你有正确的态度，有趣的问题会找上你的，但是Carl Harris的态度甚至更加重要，他理解：
5.当你对一个程序失去兴趣时，你最后的责任就是把它传给一个能干的后继者。
甚至没有商量，Carl和我知道我们有一个共同目标就是找到最好的解决方案，对我们来说唯一的问题是我能
否证明我有一双坚强的手，他优雅而快速的写出了程序，我希望轮到我时我也能做到。
