《大教堂与集市》的原文摘录(共 7 条)

  • 如果你是硬件供应商,你可能害怕开源会泄露产品如何工作的重要细节,会使竞争者趁机复制并获得不公平的竞争利益。在产品周期长达3年到5年的那些年代里,这个观点还算说得过去,但现如今,竞争者花在复制和理解上的时间,将会占据产品周期的很大一部分,他们本该把时间花在创新和考虑如何让产品差异化的。 这个观点并不新鲜,前克格勃首脑 Oleg Kalugin 说得很好:「比如说,我们计划窃取IBM这类公司或其他电子领域的先进技术,由于西方在这方面远超我们,我们需要花费数年让这些情报成果得到实现。而那时,大概五年或七年,西方又往前走了,我们只能跟着一偷再偷,而且会落得越来越远。」 Rudyard Kipling在几乎一个世纪前更好地阐明了这点,在诗作 "The Mary Gloster"(http://www.everypoet.com/archive/poetry/Rudyard_Kipling/kipling_the_mary_gloster.htm)中,他写道: 他们问我如何做到的, 我把圣经给他们看, 「让你的光继续闪耀, 照亮在跟随者的前方!」 他们会设法复制一切, 却无法复制我的思想, 我让他们辛苦偷窃, 却永远落后我一年半载。 (查看原文)
    在逃的貓 2019-11-09 19:17:36
    —— 引自章节:4. 魔法锅 95
  • 总而言之,如果满足下面这些条件,就该考虑把源码开放: 1. 可靠性/稳定性/可扩展性非常重要。 2. 除了独立的同行评审,没有其他便捷易行的方法验证设计和实现的正确性。 3. 该软件对客户的业务非常关键。 4. 该软件创建或运转一个公共计算或通信基础架构。 5. 关键方法(或能实现同等功能的方法)属于公共知识。 (查看原文)
    在逃的貓 2019-11-09 19:06:30
    —— 引自章节:4. 魔法锅 95
  • 你什么时候见过一个软件开发团队的活不够干?在这个快速变化的世界里,经济社会日益复杂并以信息为中心,懂计算机的人可要有个好身体,因为总有很多活等着他们做——无论他们花了多长时间,传授了多少诀窍。 (查看原文)
    在逃的貓 2019-11-09 19:14:31
    —— 引自章节:4. 魔法锅 95
  • 如果快速发布和淋漓尽致的利用互联网媒介不是偶然 的,而是林纳斯对最快通道的工程天才洞察力的有机部分, 那么他的资本是什么呢?他在这个机制中依靠的是什么呢? 这样一问,答案一目了然。林纳斯在不断地激励和奖掖 —— 他的黑客/用户们 激励来自于在参与中得到的自我实 现,奖掖来自于看到他们自己的工作的持续(甚至每天)进 步。 (查看原文)
    bambreeze 2012-09-01 19:34:51
    —— 引自第14页
  • 托瓦兹的 成功之处的理论。(您也会问)我是怎样做的呢?在以下方 面: ● 我早发布和常发布(几乎从未低于十天一次;高 强度开发的时候,一天一次)。 ● 我把每个和我联系 fetchmail 的人加进了我的 beta 测试名单。 ● 每当我发布一个版本,我给 beta 名单发送一个 家常式的通告,鼓励大家参与。 ● 我听取 beta 测试者的意见,在设计上征求他们 的看法,当他们送交补丁和反馈的时候给予鼓励。 (查看原文)
    bambreeze 2012-09-01 20:12:29
    —— 引自第23页
  • 当你开始社区建设的时候,你需要能够呈现一个可行的 前景。你的程序不一定要工作的非常好。它可以是粗糙的、 问题多多的、不完整的、缺少文档记录的。它一定不能失败 的是(1)能运行,(2)说服潜在的合作者它可以在可预 见的将来进化成真正漂亮的东西。 (查看原文)
    bambreeze 2012-09-01 21:09:08
    —— 引自章节:市集风格的必要前提
  • 我认为主持的人能否想出杰出灿烂的设计不是很关键, 但绝对关键的是,主持的人能够慧眼识别出他人的优秀设计 想法。 当然一定的设计和编码技能的基本水准还是必要的,但 是我预期几乎每个认真考虑发起一个市集型项目的人已经超出了这个基本要求。开源社区内部的声望机制给人们一种微 妙的压力:[如果你没有几把刷子,]不要发起自己不能胜 任的开发项目。 我认为对于市集型 —— 项目来讲,和设计才能一样的重要 甚至可能更重要。一 个市集项目的主持人或领导者必须有良好的人际、交流技 能。 (查看原文)
    bambreeze 2012-09-01 21:15:49
    —— 引自章节:市集风格的必要前提
  • 结果很可能是,开源的成功带来的一个最重要的影响会 是教育我们乐趣是创造性工作的经济上最有效的模式。 (查看原文)
    bambreeze 2012-09-01 22:19:45
    —— 引自第999页
  • 如果可以不损失效率,就要毫不犹豫抛弃陈旧的特性,Antonine de Saint-Exupery(在他成为经典儿童书籍作家之前是一个飞行员和飞机设计师)曾说过: (查看原文)
    Belle Epoque 2017-07-27 16:54:10
    —— 引自第1页
  •   13. “最好的设计不是再也没有什么东西可以添加了,而是再也没有什么东西可以去掉。” (查看原文)
    Belle Epoque 2017-07-27 16:54:10
    —— 引自第1页
  • 任何工具都应该能以预想的方式使用,但是一个伟大的工具提供你没料到的功能。 (查看原文)
    Belle Epoque 2017-07-27 16:56:38
    —— 引自第1页
  • One thing many people think the traditional mode buys you is somebody to hold legally liable and potentially recover compensation from if the project goes wrong. But this is an illusion; most software licenses are written to disclaim even warranty of merchantability, let alone performance—and cases of successful recovery for software nonperformance are vanishingly rare. Even if they were common, feeling comforted by having somebody to sue would be missing the point. You didn't want to be in a lawsuit; you wanted working software. (查看原文)
    isaachan 2018-02-02 08:44:11
    —— 引自章节:大教堂与集市
  • 1. Every good work of software starts by scratching a developer's personal itch. 1)每一个好的软件的起因都是挠到了开发者本人的痒处。 2. Good programmers know what to write. Great ones know what to rewrite (and reuse). 2)好的程序员知道写什么。伟大的程序员知道改写(和重复使用)什么。 While I don't claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it's almost always easier to start from a good partial solution than from nothing at all. 虽然我不自封为伟大的程序员,但我努力模仿伟大的程序员。伟大者的一个重要特点是建设性的懒惰。他们知道你需要的是结果不是过程,而且从一个好的部分方案开始总比从零开始要容易得多。 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. 6)把用户像合作者来对待是通往快速改进代码和有效调试的最佳通道。 In fact, I think Linus's cleverest and m... (查看原文)
    發酵罐の守望猴 2012-01-05 20:28:50
    —— 引自章节:大教堂与市集 1.2.6