大教堂与集市

• sggggy

  2014-06-30
  1.好的软件作品，往往源于开发者的个人需要2.优秀的程序员知道写什么，卓越的程序员知道改写(和重用)什么3.“计划好扔掉一个吧，迟早你会这么做的。”(Fred Brooks，《人月神话》第11章)4.如果你有正确的态度，有趣的事情自然会找到你5.当你对一个程序不再感兴趣时，你最后的责任就是把它交给一个可以胜任的接棒者6.把你的用户当成开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心的途径7.早发布、常发布，倾听用户的反馈8.如果有足够多的β测试者和合作开发者，几乎所有的问题都会很快显现，然后自然有人会把它解决9.聪明的数据结构配上蠢笨的代码，远比反过来要好得多10.如果你把beta测试者当作最珍贵的资源对待，他们就会成为你最珍贵的资源11.仅次于拥有好注意的是，识别来自用户的好主意，有时候后者会更好12.通常，那些最具有突破性和创新力的解决方案来自于你认识到你对问题的基本概念是错误的13.“设计上的完美不是没有东西可以再加，而是没有东西可以再减。”14.任何工具都应具备预期内的功能，但一个伟大的工具能给你带来预期外的功能15.写网关软件时，尽可能不要干扰数据流，而且绝对不要扔掉信息，除非接收方强迫你这么做16.当你的语言还远不是图灵完备(Turing-complete)的时候，语法糖会让你受益良多17.系统的安全性只取决于它所拥有的秘密。谨防虚假的秘密18.想要解决一个有趣的问题，先去找一个让你感兴趣的问题19.如果开发者协调者有至少一个像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战
• bambreeze

  2012-09-01
  结果很可能是，开源的成功带来的一个最重要的影响会是教育我们乐趣是创造性工作的经济上最有效的模式。
• bambreeze

  2012-09-01
  我认为主持的人能否想出杰出灿烂的设计不是很关键，但绝对关键的是，主持的人能够慧眼识别出他人的优秀设计想法。当然一定的设计和编码技能的基本水准还是必要的，但是我预期几乎每个认真考虑发起一个市集型项目的人已经超出了这个基本要求。开源社区内部的声望机制给人们一种微妙的压力：［如果你没有几把刷子，］不要发起自己不能胜任的开发项目。我认为对于市集型—— 项目来讲，和设计才能一样的重要 甚至可能更重要。一个市集项目的主持人或领导者必须有良好的人际、交流技能。
• bambreeze

  2012-09-01
  当你开始社区建设的时候，你需要能够呈现一个可行的前景。你的程序不一定要工作的非常好。它可以是粗糙的、问题多多的、不完整的、缺少文档记录的。它一定不能失败的是（1）能运行，（2）说服潜在的合作者它可以在可预见的将来进化成真正漂亮的东西。
• bambreeze

  2012-09-01
  托瓦兹的成功之处的理论。（您也会问）我是怎样做的呢？在以下方面：●我早发布和常发布（几乎从未低于十天一次；高强度开发的时候，一天一次）。●我把每个和我联系 fetchmail 的人加进了我的beta 测试名单。●每当我发布一个版本，我给 beta 名单发送一个家常式的通告，鼓励大家参与。●我听取 beta 测试者的意见，在设计上征求他们的看法，当他们送交补丁和反馈的时候给予鼓励。
• bambreeze

  2012-09-01
  如果快速发布和淋漓尽致的利用互联网媒介不是偶然的，而是林纳斯对最快通道的工程天才洞察力的有机部分，那么他的资本是什么呢？他在这个机制中依靠的是什么呢？这样一问，答案一目了然。林纳斯在不断地激励和奖掖—— 他的黑客／用户们 激励来自于在参与中得到的自我实现，奖掖来自于看到他们自己的工作的持续（甚至每天）进步。
• harryhare

  2022-04-23
  这本书并不是详尽展开这套理论的地方，想象一下“最高水平的挑逗”，聪明的读者就可以推测出很多。事实上，我会在采访中兴致盎然地谈论起我对枪支、无政府主义以及巫术的兴趣，同时尽可能让我看起来体体面面、充满童心并且拥有典型美国式的阳光心态。诀窍在于，语出惊人但却传达出让人放心的诚实和单纯。（注意：若想成功使用本诀窍，你必须真的是那样，如果其中任何一点做不到，推荐你不要使用，否则极有可能让你原形毕露。）
• harryhare

  2022-04-23
  我沉浸在黑客文化中已经20多年并且历经了它的各个时期，20年来我看到闪光的想法、充满希望的开端和高超的技术一次又一次被圆滑的市场打败；20年来我见证了黑客的梦想、汗水和努力，但往往只能看着像IBM这种又老又坏或者像微软这种又新又坏的家伙们拿走了现实世界的奖励；20年来我们生活在隔离区——它还算舒服，充满着有趣的朋友，但却仍然被一个巨大的不可触摸的由主流偏见组成的屏障包围，上面写着几个大字：“里面都是怪人”（“ONLY FLAKES LIVE HERE”）。
• 豆友152905485

  2019-07-22
  如果报告bug的用户对源码不关心，则其报告通常不会很有用。对源码不关心的用户，往往报告的都是表面症状，他们把自己的运行环境当成是理所当然的，他们不仅省略了重要的背景数据，而且很少给出重现bug的可靠方法。
• 豆友152905485

  2019-07-21
  最初我的表达是「每个问题都会有人弄明白」。Linus提出异议，他认为那个弄明白并修复问题的人往往不是也没有必要是那个首先发现问题的人，「有人发现问题，」他说，「另有人搞定问题，我可以公开地说，发现问题更具挑战性。」
• 豆友152905485

  2019-07-21
  优秀的程序员知道写什么，卓越的程序员知道改写（和重用）什么。
• 赵亮亮亮亮亮亮

  2014-12-07
  “自我表现”禁忌会促进生产力，但是这只是一个次生效果；该禁忌直接保护的是社区同侪评价系统的信息质量，之所以要抑制自我吹捧或妄自尊大，是因为它像噪声一样，往往会破坏在创造性合作性行为实验中得出的重要信号。
• 赵亮亮亮亮亮亮

  2014-12-07
  fetchmail项目之所以能成功，相信部分原因是我限制了表现自己聪明的倾向。
• 豆友152905485

  2019-11-09
  你什么时候见过一个软件开发团队的活不够干？在这个快速变化的世界里，经济社会日益复杂并以信息为中心，懂计算机的人可要有个好身体，因为总有很多活等着他们做——无论他们花了多长时间，传授了多少诀窍。
• 豆友152905485

  2019-11-09
  总而言之，如果满足下面这些条件，就该考虑把源码开放：1. 可靠性/稳定性/可扩展性非常重要。2. 除了独立的同行评审，没有其他便捷易行的方法验证设计和实现的正确性。3. 该软件对客户的业务非常关键。4. 该软件创建或运转一个公共计算或通信基础架构。5. 关键方法（或能实现同等功能的方法）属于公共知识。
• Azure

  2020-02-16
  换句话说，软件很大程度上是一个服务行业，虽然长期以来都毫无根据被错认为是制造行业。
• 豆友152905485

  2019-07-21
  好的软件作品，往往源自于开发者的个人需要。
• 豆友152905485

  2019-11-09
  如果你是硬件供应商，你可能害怕开源会泄露产品如何工作的重要细节，会使竞争者趁机复制并获得不公平的竞争利益。在产品周期长达3年到5年的那些年代里，这个观点还算说得过去，但现如今，竞争者花在复制和理解上的时间，将会占据产品周期的很大一部分，他们本该把时间花在创新和考虑如何让产品差异化的。这个观点并不新鲜，前克格勃首脑 Oleg Kalugin 说得很好：「比如说，我们计划窃取IBM这类公司或其他电子领域的先进技术，由于西方在这方面远超我们，我们需要花费数年让这些情报成果得到实现。而那时，大概五年或七年，西方又往前走了，我们只能跟着一偷再偷，而且会落得越来越远。」Rudyard Kipling在几乎一个世纪前更好地阐明了这点，在诗作 "The Mary Gloster"(http://www.everypoet.com/archive/poetry/Rudyard_Kipling/kipling_the_mary_gloster.htm)中，他写道：他们问我如何做到的，我把圣经给他们看，「让你的光继续闪耀，照亮在跟随者的前方！」他们会设法复制一切，却无法复制我的思想，我让他们辛苦偷窃，却永远落后我一年半载。
• 云风

  2014-07-10
  只有当程序员非常积极以至于没有奖励他(她)也愿意工作时，才是唯一给予绩效奖励的时候。