# 《大教堂与集市》书摘 - Link: https://www.ixiqin.com/2023/08/26/excerpt-from-cathedral-and-market/ - Published: 2023-08-26T06:00:00+08:00 - Author: 白宦成 * 他教导我：要尊重能力，要珍视和捍卫自由，特别是：昆虫才讲究技能专一。 * 要想对世界做出实质性的改变，开源需要做到这两点：一是要让人们广泛使用开源软件； 二是要让用户知道并理解这种软件开发模式能给他们带来的益处。 * 现在第一版已经停印了，其修订版和增补版是《新黑客字典》（The New Hacker’s Dictionary）， 由MIT出版社于1996年出版（3rd edition，ISBN 0-262-68092-0）。 * 1.好的软件作品，往往源自于开发者的个人需要。 * 优秀的程序员知道写什么，卓越的程序员知道改写（和重用）什么。 * 卓越程序员们有个很重要的特征是“建设性懒惰”，他们知道人们要的是结果而不是勤奋， 而从一个部分可行的方案开始，明显要比从零开始容易得多。 * 3.“计划好扔掉一个吧，迟早你会这么做的。”（Fred Brooks，《人月神话》第11章） * 或者可以这么说：在你第一次把问题解决的时候，你往往并不了解这个问题，第二次你才 可能知道怎么把事情做好。所以，如果你想做对事情，至少要再做一次。 1 * 4.如果你有正确的态度，有趣的事情自然会找到你。 * 当你对一个程序不再感兴趣时，你最后的责任就是把它交给一个可以胜任的接棒者。 * 6.把你的用户当成开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心 的途径。 * 不只是Emacs，还有其他一些软件产品也使用了两层架构和两级用户群，内核使用大教堂 模式开发，工具箱(toolbox)使用集市模式开发，比如数据分析和可视化展现的商业化工具 MATLAB就是这样，MATLAB和其他类似产品的用户们发现，创新、酝酿和行动最频繁发生的 地方总是在产品的开放部分，而这部分的改进也总是由庞大而多样化的用户群完成。 * 尽早和尽量频繁发布是Linux开发模式中至关重要的一部分，绝大多数开发者（包括我） 都习惯性地认为：除非是很小的项目，这么做有害无益，因为软件的早期版本几乎都是问题 版本（buggy version），如果早早发布，恐怕会耗尽用户们的耐心。 * Linus的直接目标就是将投入排错和开发的“人时”（person-hour）最大化，即便这样做可能 导致代码不稳定，或者可能因为一些难以消除的严重bug导致用户群流失，Linus也在所不惜， 他相信： * 大教堂建筑者看来，bug是棘手的、难以发现的、隐藏在深处的，要经过几个人数月的全心投入 和仔细检查，才能有点信心说已经剔除了所有错误。而发布间隔越长，倘若等待已久的发布 版本并不完美，人们的失望就越发不可避免。 * 这里隐含的问题是开发者和测试者对程序有着不匹配的思维模式，测试者是从外往内看， 程序员是从内往外看。对于不开放源码的软件开发，开发者与测试者往往局限于自己的角色， 各说各话，都对对方倍感沮丧。 * 传统软件开发在组织结构上的根本问题由Brooks定律一语道破：“在一个已经延期的项目 上增加人手，只会让项目更加延期。” * Brooks定律指出，随着开发人员数目的增长，项目复杂度和沟通成本按照人数的平方增加， 而工作成果只会呈线性增长。 * 聪明的数据结构配上愚笨的代码，远比反过来要好得多。 * Brooks在《人月神话》的第9章里说：“让我看你的流程图但不让我看表，我会仍然搞不明白。 给我看你的表，一般我就不再需要你的流程图了，表能让人一目了然。”历经30年的术语/ 文化变迁，这个道理依旧没变。 * 先说说前面我提到的用这个项目验证我所发现的关于Linus成功的理论，（你可能会问） 我是如何做的呢？有这么几个办法： ·我尽早发布并频繁发布（几乎从来没有低于10天一次 的频率，在高强度开发阶段会一天一次）。 ·我把每一个因fetchmail联系我的人都加到 beta列表（是指beta测试人员邮件列表——译者注）中。 ·每次发布新版本时，我都向beta 列表发送朋友对话般的通知，鼓励他们参与。 ·我听取beta测试者们的意见，征求他们关于 设计决策的看法，当他们发来补丁和反馈时给他们以热情回应。 这些简单措施立刻收到 了回报。 * 如果你把beta测试者当做最珍贵的资源对待，他们就会成为你最珍贵的资源。 * 11.仅次于拥有好主意的是，识别来自用户的好主意，有时后者会更好。 * 很有趣的是，如果你发自内心地谦逊，并承认你欠别人很多，你将很快发现世界会这样对待 你：他们认为是你发明了整个软件，而且你对自己的天赋有着得体的谦虚。我们可以看到 这一点在Linus身上体现得有多好！ * 通常，那些最有突破性和最有创新力的解决方案来自于你认识到你对问题的基本观念是错 的。 * 设计上的完美不是没有东西可以再加，而是没有东西可以再减。” * 当你的代码变得既好又简单，你就知道你做对了， * 如果你采用快速迭代开发模式，开发和改进过程就可能成为排错过程的一个特例——修复软件 原先在功能或概念上的“疏漏型bug”（bug of omission）。 * 15.写网关类软件时，尽可能不要干扰数据流，而且绝不要扔掉信息，除非接收方强迫你 这么做。 * 我并不是因此而不喜欢英语语法，相反，提及它正是为了打破传统观念。有了更便宜的计算 资源，简洁就不该成为最终目标。对现如今的计算机语言来说，是否便于人类使用要比是否 节省计算资源更重要。 * 当你的语言还远不是图灵完备（Turing-complete）的时候，语法糖[4]会让你受益良多。 * 17.系统的安全性只取决于它所拥有的秘密。谨防虚假的秘密。 * 当开始建设社区的时候，你需要拿出一个像样的承诺。程序此时并不需要特别好，它可以 简陋、有错、不完整，文档可以少得可怜。但它至少要做到：(a)能运行，(b)让潜在的合作 开发者相信，这个软件在可预见的未来，能演变成一个非常棒的东西。 * 在软件设计上表现得聪明而有原创性，容易养成一个习惯——在应该保持软件健壮性和简单 性的时候，你往往下意识把它弄得既华丽又复杂。 * 此言不虚：最好的程序一开始只是作者对自己每天遭遇问题的个人解决方案，程序流传开来 则是因为作者遇到的问题成了一大类用户的典型问题。 * 想要解决一个有趣的问题，先去找一个让你感兴趣的问题。 * 一个在封闭项目中只靠自己的开发者，将远远落后于这种开发者：他们知道如何创建一个 开放的、有改进能力的环境，在这个环境中，上百人（甚至上千人）反馈并提供设计空间 拓展、代码贡献、bug定位以及软件的其他改进。 * “齐心协力”正是Linux这种项目所需要的——对Internet上（可以看成是无政府主义者的天堂） 的志愿者们使用“命令原则”是根本行不通的。 * Linux黑客们致力于最大化的“效用函数”，其目的并不是经典意义上的经济价值，而是自我 满足和黑客声望这些无形的东西。（有人把这种动机称为“利他”，但他们忽视了一个事实， 即“利他”本身是“利他者”自我满足的外在表现。） * fetchmail和Linux核心项目都表明，如果对参与者的“自我”做适当奖赏，一个优秀的开发 者或协调者可以利用Internet获取多开发者的好处，而不会让项目陷入混乱不堪。 * 19.如果开发协调者有一个至少像Internet这样好的沟通媒介，并且知道如何不靠强制来 领导，那么多人合作必然强于单兵作战。 * 未来软件产业的经济关键是服务价值。 * 一些人认为购买传统模式产品会带来这样的保障：如果项目出错，有人会负责，并为可能 的损失买单。 * 即便很常见，也不要因为可以起诉某人就觉得心安，你想要的不是官司，而是能用的软件。 * 为弄明白这点，我们需要了解软件开发管理者是如何看待自己工作的，我有位朋友看上去 在这方面做得很好，她说软件管理有五个功能： ·明确目标并让大家朝同一个方向努力。· 监督并确保关键细节不被遗漏。 ·激励人们去做那些乏味但必要的“体力活”。 ·组织人员 部署并获得最佳生产力。 ·调配项目所需的资源。 显然所有这些目标都是有价值的，但在 开源模式及其所在的社会语境中，人们会惊奇地发现这些目标毫无意义，我们按颠倒过来 的顺序分析。 * 如果传统、闭源、严格管理模式的软件开发真的想靠这种由“无聊”部分组成的马其诺防线 来防御，那么它之所以在某个应用领域能继续生存下去，只是因为还没人发现这些问题是 真正有趣的，并且还没人发现迂回包抄的路径。一旦有开源力量介入这些领域，用户就会 发现终于有人是因为问题自身的魅力而去解决它的，就像其他所有需要创造力的工作，若 论激励效果，问题自身的魅力比单纯的金钱要有效得多。 * 软件工程中最广为人知的一条大众定理是：传统软件项目中的60%到70%，要么是从未被完成， 要么被他们的用户拒绝。如果这个比例还算靠谱的话（我还没见过任何一个有经验的项目 管理者对此提出过异议），那么大多数项目把目标设定得要么太不现实，要么完全错误。 * 如果你在工作过程中感到恐惧和厌恶（即便你以自嘲的形式来表达——比如悬挂呆伯特玩偶）， 就应该意识到过程已经出了问题。快乐、幽默和玩兴是真正的资产，前面我之所以写“快乐 部落”（happy horde）并不是为了首字母押韵，而用一只憨态可掬的企鹅作为Linux吉祥 物也绝不仅仅是为了搞笑。 * 极度热忱的人可能会说：“自由软件是我的生命！我活着就是为了创造有用的、优美的程序 和信息资源，并把它们贡献给社会。”中热忱度的人可能会说：“开源是件好事，我愿意花 大量时间帮助它成功。”低热忱度的人则可能说：“开源有时候还不错，我也玩这个，我尊敬 那些创造它的人。” 差异还体现在敌对性上：反对商业软件，以及反对那些试图支配商业 软件市场的公司。 * 他们有效定义了“自由软件”概念，并有意赋予其对抗意味（后来出现的“开放源码”叫法则 有意避免这点）。 * Linux快速成长的额外好处是吸引了一大批新黑客，他们对Linux忠心耿耿，而把FSF计划 视为过气的兴趣，尽管这一波黑客将Linux系统称为“GNU一代的选择”，他们中的大多数更愿意 效仿Torvalds而不是Stallman。 * 1997年，“Debian自由软件准则”提炼了这些共同要素，并形成了开放源码定义（OSD，参见 http://www.opensource.org）。 定义指出，开源许可证必须保护任何个人或团体无条件 修改开源软件（以及发布修改后软件版本）的权利。 * 所以，OSD（以及与OSD一致的版权声明，如GPL、BSD许可证、Perl的艺术许可证（Artistic License））隐含的规则是“任何人能干任何事”（anyone can hack anything），没有任何 事情可以阻止人们获取任意开源产品（如自由软件基金会的gcc编译器）、复制其源码、 推进其向不同方向演进，并都可声称是该产品。 * 这种演进上的分化称为“分支”(fork)，分支最重要的特点是它派生出一个随后不能交换代码 的竞争项目，并导致开发社区潜在的分裂。（ * ·分化一个项目会遇到强大的社会压力，只有在极为必要的情况下才使用，而且要重新命名 和做出大量的公开解释。 * ·在没有项目主持人认可的情况下发布更新是令人不悦的，除非是特殊情况（如本质上不 重要的移植bug修复）。 ·在项目历史、致谢表或维护列表中移除某个人的名字是绝对不 可以的，除非当事人明确表示同意。 * 一个软件项目的“所有者”就是在社区中众所周知的对软件版本改动有唯一发布权的那个人。 * 开源活动确实存在一种帮助人们变得更有钱的可能，但也只是对这种可能提供有价值的线索 而已。有时，某人在黑客文化中获得的声誉会在真实世界中产生经济意义：比如带来一个 更好的工作机会、一份咨询合同或一纸出版协议。 * 在分析“声誉竞争”前顺便提一下，我并不是要贬低或忽视这种纯粹美学上的满足：设计优美 的软件并让它运行。黑客们都经历过这种满足并乐在其中。如果某人没有这种意义上的动力， 他根本就不可能成为一名黑客，正如不喜欢音乐的人永远不会成为作曲家一样。 * 本文第一版在互联网上发布后，一位匿名读者评论道：“别为名声工作，如果你做得好， 名声将伴随结果而来”。 * 我们已经了解心智层开垦的产出，就是黑客礼物文化中的同侪声望以及所有它带来的二次 收益和额外作用。 * 从这个理解出发，我们可以把黑客所沿袭的Lockean财产权习惯看做是一种将声誉激励最大 化的手段——确保同侪将名誉赋给应得之人，而不会赋给不该得到的人。 * ·项目产生分支是不好的，因为分化前的项目贡献者会面临声誉风险，若要控制该风险， 他们只能在分化后的两个子项目上同时保持活跃。（通常这是不现实的，因为它让人困惑 或难以实施）。 * ·发布“流氓”补丁（或者更糟糕的“流氓”二进制文件）会让项目所有者陷入声誉风险，即便 官方代码是完美的，所有者仍然会因补丁中的bug而被抨击（见书后注释4）。 ·偷偷将某人 的名字从项目中移除，是黑客文化中最极端的恶行。这相当窃贼偷盗了受害者赠予的礼物， 并说是他自己的。 * 一位读者曾指出，分支很少能有一个以上的后代存活下来（活下来是指能长期拥有一定的“ 市场份额”），这促使项目所有参与方合作并避免分化，因为如果产生分化，很难预先知道 谁会落败，一旦落败，就只能看着他们曾经大量的工作完全消失或者默默凋零。 他还指出 一个不争的事实，即分支很容易产生争论和对抗，这足以引发对项目团队的社会压力。争论 和对抗都会妨碍团队合作，而团队合作正是每个贡献者要达到自己目标所必须的。 * 这揭示了黑客文化一个有趣的方面，它有意识地不信任或者看不起“自我主义”或者基于自我 的动机。“自我推销”往往会遭到批判，即便整个社区可能从中获得好处。 * 相比之下，在黑客社区中，一个人的作品就是他的宣言。这里有着严格的精英意识（技术 最好的人胜出），这里的信条是让质量说话，让黑客最自豪的是代码“好使”（just works）， 是让任何称职程序员都能看到的好东西，所以，黑客文化的知识库增长迅猛。 * 出于非常类似的原因，抨击作者而非代码是不合常规的，这一点微妙而有趣，黑客们会没有 顾忌地在意识形态或个人差异上互相攻击，但从未听说有哪个黑客曾公开攻击另一个人的 技术能力（ * 攻击他人能力的禁忌（学术圈没有这个禁忌）比起自我表现禁忌（这一点学术圈也有）更有 揭示意义，因为我们可以将其关联到学术圈与黑客圈在沟通和支撑结构的差异上。 * 谈吐柔和也是有用的，如果某人希望成为一个成功项目的维护者，他必须让社区信服他良好 的判断力，因为维护者的主要工作是判断他人的代码，谁愿意将代码贡献给一个明显不能 正确判断他们自己代码质量的人？或者一个试图从项目中沽名钓誉的人？潜在的贡献者希望 项目领导人在客观采用他人代码时，能够谦逊而有风度地说：“是的，这个的确比我的代码 好，就用这个了”——然后将荣誉给予应得之人。 * 从全球看来，这两个倾向（“填补空白”和“类别杀手”）是开源项目发展的总体趋势。 * 在第三个千年的开始，我们大可预言开源会转向最后一块处女地——写给非技术人员的程序。 * 声誉竞争模型解释了一个常被引用的格言，即“自称是黑客不代表你就是黑客，只有其他 黑客认为你是黑客，你才是黑客” * 如果它不能像我所预期的那样工作，那就不是好的——不管它多么聪明和有原创性。 * 这条规则使得开源软件倾向于长期停留在beta版，开发者只有在确信软件不会有很多问题 时，才会发布1.0版。开源世界的1.0版意味“开发者愿意拿自己的名誉赌它好使”，而闭源 世界的1.0版则意味着“如果你很谨慎，不要用这版”。 * 在心智层的拓展性工作要比在某功能域内（对现有作品）的重复性工作好。 * 能进入主要发行版的作品比不能进入的好。在所有主要发行版中都包含的作品最令人尊敬。 * 使用”是最真实的赞美，类别杀手比同类竞争者好。 * 如果作品好到没人再想使用其他备选，作者将会获得巨大的威望。那些被最广泛使用的原创 型类别杀手，会被纳入所有的主要发行版中，并获得最大可能的同侪尊重。成功做到这点 超过一次的人，将会被人们半开玩笑、半认真地称为“大神”（demigods）。 * 相比那些只挑有趣和简单工作的人，长期致力于艰苦和乏味工作（如调试、写文档）的人 更令人钦佩。 * 重要的功能扩展比低层次的修补好。 这条规则似乎是针对一次性工作的评价。相对于修补 bug而言，给软件增加功能特性有可能得到更多回报——除非这个bug异常令人厌恶或者难以 寻找，因为将这种bug找出来本身就证明了非凡的技术和才能。但当这些工作是长期行为 的话，一个长期关注和排除bug（甚至是普通bug）的人，其地位要高于那些花费相近工作 量在增加简单功能上的人。 * 财产权不仅仅是社会约定或游戏，而是至关重要的防范暴力冲突的进化机制。（ * 所有权声明（就像领土标记）是一种述行式（performative）行为，一种宣布防御边界的 方法。 * 黑客们常说“责任背后是权力”，一个合作开发者在承担起维护某个子系统的责任后，通常 有机会掌控子系统及其对外接口的实现，其决策仅受项目领导人（同时也是架构师）的修正。 * 这个领域的其他研究者把目光投向了黑客们非常在意的自主性和创意自由度问题，“如果 一个人越是感受到自主性受限”，罗切斯特大学心理学副教授Richard Ryan说，“其创造力 就会越少。” 对任何一个任务，如果它更像是手段而不是它本身的话，往往会降低人们的 积极性。即便是赢取比赛或获得同侪尊敬，如果觉得获取胜利只是为了求得回报，也一样 会觉得没意思（这也许可以解释为什么黑客文化禁止那些毫不隐瞒的对尊重的追求和索取）。 * 最终，当自由市场经济开始创造出足够的财富盈余时，大量程序员可以生活在后稀缺的礼物 文化中，而软件产品的工业\工厂模式注定走向衰亡。 * 事实上，获取最高软件生产力的药方看上去自相矛盾而又颇具禅意：如果你想获得最有效率 的产品，你必须放弃促进程序员生产力。做好他们的后勤，让他们自己做主，并忘掉最后 期限。 * 指出技术会变得越来越便宜和有效，早期设计中需要投入的物理资源被越来越多地替换成 信息内容。 * 在尝试使用经济学分析软件产品时，大多数人会想当然地运用“工厂模型”，它建立在如下 基本假设之上： ·大多数开发者的薪金由软件销售价值支付。 ·软件销售价值和它的开发 投入成比例。 换句话说，人们十分倾向于假设软件具备典型批量商品的价值特点，但这些 假设都可以被证伪。 * 相比之下，当一个软件产品供应商退出市场（或仅仅是产品不再延续）后，消费者愿意为 其产品支付的价格很快会降低到零，而不管其理论上的使用价值或该类产品的开发成本如何。（ 要想检验一下这个论断，可以看看你附近软件商店里的打折专柜）。 * 换句话说，软件很大程度上是一个服务行业，虽然长期以来都毫无根据地被错认为是制造 行业。 * 这个问题很像是F.A.Hayek所提“计算问题”的翻版——它需要一个超能力（superbeing）存在： 既能评估补丁的实用价值，又能可信地设定其价格以促成交易。 * 开源项目的复杂性和沟通成本基本上完全是参与开发人数的函数，大多数从来不看源码的 终端用户实际上并不会带来什么成本，但会增加项目邮件列表上愚蠢问题的比例，好在可以 通过维护FAQ（常见问题）列表较为轻松地解决这个问题，而且通常大可不必理会那些明显 没有读过FAQ的提问者（这些已经是通行做法）。 * 也许是，也许不是。真正应该考虑的问题是：你从分散开发负担中获取的益处是否超过了 因（“搭便车”行为导致的）竞争加剧而带来的损失，一些人往往在这个权衡中失算：(a) 忽略了社区开发带来的功能改进。(b)不把已经支出的开发成本当做沉没成本。根据假设， 不管怎样，你都是要付出开发成本的，所以把它归入开放源码（如果你这样认为）的成本 是不对的。 * 另一个经常被提及的担心是，将某些特别的财会功能开源，会不会导致商业机密方案的泄露？ 其实这不关开源闭源的事，这是糟糕设计带来的问题。财会软件如果编写得当，商业知识 是不会在代码中体现的，它应该由一个模型（schema）或描述语言表达，然后由财会引擎 执行实现（作为很相近的一个例子，考虑数据模型将业务知识和数据库引擎相分离的做法）， 这种功能上的分离使你不但可以保护住王冠上的宝石（即你的商业模型），还能从开放引擎 中获得最大收益。 * 使用价值和销售价值之间的差别，让我们注意到这样一个关键事实：在从闭源转向开源的 过程中，受到威胁的仅仅是销售价值，而非使用价值。 * 困难存在于开源开发社会契约的内在特点。有三个相辅相成的原因，使得主流的开源许可 证不允许对对开源软件使用、再发布和修改施加限制，从而影响直接销售收入的获取。要 理解这些原因，我们必须研究许可证演变所处的社会语境，也即互联网黑客文化（http:// www.tuxedo.org/~esr/faqs/hacker-howto.html）。 * 第一个原因与“对等性”有关，大多数开源开发者并不反对别人利用他们的礼物获利，只是 要求不能有任何人（代码创始人可能会例外）站在一个特权地位上牟利。 * 第二个原因则与“非有意后果”有关。黑客已经观察到，那些对商业使用或销售进行限制并 收费（这是最常见的征费方式，乍看上去并无不妥）的许可证有着令人扫兴的效果。特别 是这条规定给某些活动（如将开源软件系列发布在便宜的CD-ROM上）笼上了一层法律阴影， 而这些活动正是我们非常愿意鼓励的事。更普遍地讲，如果对软件的使用/销售/修改/发布( 以及其他在许可证中描述的复杂情况)加以限制，会使人们总是小心翼翼防范那些不确定 的和潜在的法律风险（当人们接触的软件包越多，这个问题就越严重）。这个结果是有害 的，因此，在强大的社会压力下，许可证将会变得越来越简单和无限制。 * 与保持同侪评价这种礼物文化动力（“开垦心智层”一文中所描述的）相关。 * 根据“大教堂与集市”一文的分析，开源获取高收益的条件大约有如下几种：(a)当可靠性/ 稳定性/可扩展性至关重要时，(b)没有其他方法比独立同行评审能更便捷易行地验证设计 和实现正确性时（多数稍具规模的程序都适用这条）。 当软件对消费者越来越重要时， 消费者会在理性上希望避开垄断供应者，这导致他们对开源的兴趣变大（开源供应商的市场 竞争力会因此增强），所以，另一个判断标准是：(c)当软件成为对业务起关键作用的资产（ 比如存在于很多企业的MIS部门中）时。 * 我们注意到，提供独特或高度差异化服务的供应商更担心其他竞争者拷贝他们的方法，而 关键算法和知识库已经公开化时就不会这样。所以，(e)当关键方法（或能实现同等功能 的方法）属于公共知识时，开源更可能胜出。 * 这样的公司是最没有必要开源的：它拥有自己独特的能创造价值的软件技术（完全不满足( e)），它对故障不是很敏感(a)，它有其他办法（不通过独立的同行评审）验证软件的正确 性(b)，它不是关键业务(c)，也不会因为网络效应或人们普遍使用而获得价值上的实质增长( * 这个问题之所以严重，是因为对任意给定种类的软件产品，开源合作能够吸引的用户群和 专家群都是有限的，而社区往往有黏性，如果两个在功能上大致等同的产品先后开源，先开 源的往往会吸引最多的用户和最有激情的合作开发者，后开源的只能吃剩饭。社区之所以 有黏性，是因为用户对软件已经熟悉，而开发者已经在代码上投入了太多时间。 * 概括来说，基础架构的开放和共享，使每个参与者都得到了竞争上的好处，一是参与者能 以较低成本生产出可扩展的产品和服务，二是参与者的市场定位可以让客户放心，他们很少 会面临这样的尴尬境遇：由于供应商更改了战略或战术，导致产品被抛弃而无人照管。 * 有时候，要想成为一只更大的青蛙，最佳办法就是让水池更快变大，这就是技术公司参与 公开标准（完全可以将开源软件看成是可执行标准）的经济原因。 * 开源似乎注定要成为一种普遍的做法，究其原因，更多是源自于客户需要和市场压力，而 非供应端的效率。 * 传统软件产业的战略家们是无法理解这种行为的（不顾其市场增长效应），因为他们成长 在将（通过专利和商业秘密保护起来的）知识产权看成企业王冠上宝石的文化之中。为什么 资助一项研究，却让每个竞争对手都可以无偿享用其结果呢？ * 做正确的事”会给公司带来什么好处？答案本身既不令人惊讶也不难以验证，其他产业里 也有这种看上去大公无私的行为，这些公司相信他们换来的是名声。 * 为分析软件市场自身，有必要将软件服务按技术标准化程度进行分类，而这和软件服务的 市场化（commoditize）程度存在密切关系。 这种分类与人们通常所说的“应用”（完全没有 市场化、已开放的技术标准太弱或不存在）、“基础架构”（市场化服务、强标准）和“中间 件”（部分市场化、有效但不完全的技术标准）有着很好的对应。在今天，典型的例子是 字处理软件（应用）、TCP/IP协议栈（基础架构）和数据库引擎（中间件）。 * 我们早先所做的收益回报分析表明：基础架构、应用和中间件将会以不同的方式变革，并 展现出不同的开、闭源并存及平衡现象。在特定软件领域，开源能否流行，将取决于软件 是否有实质性的网络效应、软件失效的代价如何以及软件作为资本货物的业务关键性程度。 如果将这个启发式分析方法运用到软件市场的各个部分（而不是单个产品），我们可以做出 如下的大胆预言： * 基础架构（互联网、Web、操作系统、跨越竞争者界限的低层通信软件）将会几乎全部开 源，并由用户联盟和盈利性发布/服务机构（如Redhat所扮演的角色）共同维护。 * 应用，则非常倾向于继续封闭。当一个未公开算法或技术的使用价值足够高（且软件不稳定 带来的相关成本足够低、供应商垄断带来的相关风险足可容忍）时，用户会继续为此类闭 源软件付费。这种情况最有可能发生在自成一体的垂直市场应用中（其网络效应也较弱）。 前面提到的锯木软件就是一例，1999年最热门和最有前景的生物识别软件则是另一例。 * 中间件（像数据库、开发工具或可定制的应用协议栈顶端）将处于开闭源混杂的状态，这类 软件走向闭源还是开源，似乎更取决于软件失效的代价，代价越高，其走向开放的市场压力 就越大。 * 他认为技术进步的趋势是更小、更轻和更有效，能够让人们“费力越来越少，收获越来越 多，以至于最终可以毫不费力地获得所有东西”。 * 虽然还处于早期阶段，但对我来说，推进战略所需的详细战术已经非常清楚了（我们在首次 会议中明确讨论了这些战术），关键点如下。 1.忘掉自底向上，开始自顶向下 * 网景的这次突破行动采用了相反的做法：战略决策者（Jim Barksdale）拿定主意，然后 向下属强制推行这个愿景。 * 2.Linux是我们最好的例证 我们必须大力宣扬Linux。是的，开源世界里还有其他一些不错 的东西，这场运动也会向它们致敬，但Linux有着最好的知名度，有着最广泛的软件库， 以及最大的开发社区。如果Linux都不能帮助突破，说实话，其他的就更指望不上了。 * 抓住财富500强 除了财富500强，市场中另有一部分也很能花钱（最明显的例子是小企业 和自由职业者），但这部分市场过于分散而且很难抓住。财富500强不只是有钱，而且有 集中的和相对容易获取的钱，因此软件产业在很大程度上会按照财富500强的意愿行事。 所以，我们首先应该说服财富500强。 4.赢得那些效劳财富500强的有威望媒体 把目标选定 为财富500强，意味着我们需要赢得那些给上层决策者和投资人营造舆论环境的媒体。特别 是《纽约时报》、《华尔街日报》、《经济学人》、《福布斯》以及《巴伦周刊》等等。 从这点看来，争取技术行业刊物是必要的，但远远不够，若要席卷华尔街，一个重要和基本 的条件是先鼓动起精英主流媒体。 * 5.说服黑客，游击市场 很明显，说服黑客社区自身与说服主流一样重要。如果只是一个 或几个代表言之凿凿而大多数草根黑客并不买账，那可就差点意思了。 6.使用“Open Source” 认证标识，保持纯净度 我们面临的一个威胁是：微软或其他大供应商可能会采取“拥抱并 拓展”（embrace and extend）策略破坏“Open Source”一词，使它失去我们要传达的理念。 所以Bruce Perens和我一开始就决定把这一术语注册成认证标识并把它和“开源定义”（Open Source Definition，也即Debian Free Software Guidelines的拷贝）绑定。这样我们可以 利用法律诉讼的威慑力吓跑那些可能的滥用者。 * 行业刊物很明显对开源也有了更正确的认识，正如Zawinski那句名言所说的：“开源（很 伟大，但它）并不能点石成金。” * 两者最根本的区别是：黑客搞建设，骇客搞破坏。 * 做一名黑客有很多乐趣，但这是一种需要努力才能获得的乐趣。而努力需要动力，成功运动 员的动力来自于控制自己身体和超越自己过往生理极限的愉悦。 * 在黑客文化中，假名是失败者的标识。 * Peter Seebach维护着一个优秀的黑客FAQ（http://www.plethora.net/~seebs/faqs/hacker. html），用来帮助那些不懂得如何与黑客相处的管理者。我写的“黑客圈简史”（http:// www.tuxedo.org/~esr/writings/hacker-history/hacker-history.html）和“大教堂与集 市”(http://www.tuxedo.org/~esr/writings/cathedral-bazaar/index.html)，对Linux 开发和开源文化如何运转做了阐述，在“开垦心智层”（http://www.tuxedo.org/~esr/writings/ homesteading/）中则对此话题做了更直接的探讨。