大教堂与集市(The Cathedral and the Bazaar)读书笔记

大教堂与集市The Cathedral and the Bazaar，一本不像计算机方面的计算机书籍

命令式管理，适合和奴隶共事
目标共识型管理，适合和自由人共事

心性气层

只要眼多，bug好找

黑客开源：产品相关富足，赢得尊重不是因为占有什么，而是贡献了什么
如果你把它当成资源，它就会成为你的珍贵资源

如果不想做，找一个合适的接手人，知道什么时候收手，是一个不错的主意
“我是一个很懒的人，别人干活，我得荣誉”linus

如果认真的态度对待，机会自然会来。做有价值的事，一直做，早晚会有收获的。虽然劳动的价值来自稀缺性

开发软件不一定要从头开始，有个基础，虽然这些代码早晚要被替换掉，但却会是一个好的脚手架

早发布，多发布。鼓励用户的反馈，以合作开发者的态度和用户交流，会有一个稀缺的bug查找资源

没有用户愿意为一个bug等半年的时间

python,perl,c,c++,java
perl代码可以不用，但要能看懂代码

要以脱离具体语言的思维来考虑问题

学习编程语言，不只是学工具，还有思考方式

原文关键总结：

1、Every good work of software starts by scratching a developer's personal itch.

每一个好的软件起因都是挠到了开发者本人的痒处。

2、Good Programmers know what to write.Great ones know what to rewrite(and reuse).

好的程序员知道写什么。伟大的程序员知道改写（和重复使用）什么。

3、"Plan to throw one away;you will,anyhow"(Fred Brooks,The Mythical Man-Month,Chapter 11)

“计划扔掉一个；无论如何你都会扔掉一个的。”（弗里德.布洛克《人月神话》第11章）

4、If you have the right attitude,interesting problems will find you.

如果你有正确的态度，有意思的问题会找到你。

5、When you lose interest in a program,your last duty to it is to hand it off to a competent successor.

当你对一个项目失去兴趣时，你的最后的职责是把它交给一个称职的继承者。

6、Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

把用户像合作者来对待是通往快速改进代码和有效调试的最佳通道

7、Release early.Release often.And listen to your customers.

早发布。常发布。听取用户的意见。

8、Given a large enough beta-tester and co-developer base,almost every problem will be characterized quickly and the fix obvious to someone.

如果beta测试者和合作开发者的群体足够大的话，几乎每个问题都会快速显形，会有人轻而易举地把它解决。

9、Smart data structures and dumb code works a lot better than the other way around.

聪明的数据结构和愚蠢的代码要比反过来好得多。

10、If you treat your beat-testers as if they're your most valuable resource,they will respond by becoming your most valuable resource.

如果你以“最有价值资源”来对待你的beta测试者，他们会以成为“最有价值资源”来回应。

11、The next best thing to having good ideas is recongizing good ideas from your users.Sometimes the latter is better.

仅次于拥有好的主意的是认识到来自于用户的好主意。有时候后者更好一些。

12、Often,the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

最有突破和创新的方案常常来自于意识到你把问题的模型弄错了。

13、"Perfection(in design) is achieved not when there is nothing more to add,but rather when there is nothing more to take away."

“设计达到完美的时候，不是增加得不能再增加了，而是减少得不能再减少了”。

14、Any tool should be useful in the expected way,but a truly great tool lends itself to uses you never expected.

任何一个工具都应该达到预期的作用，但是一个真正棒的工具会带来你从来预期不到的用处。

15、When writing gateway software of any kind,take pains to disturb the data stream as little as possible - and never throw away information unless the recipient forces you to!

在写任何关口软件的时候，花点功夫尽可能不要干扰数据流-除非用户强迫你，永远不要扔掉任何信息！

16、When your language is nowhere near Turing-complete,syntactic sugar can be your friend.

当你的语言离图灵穷尽还差得远的时候，给语法加点风味可以有帮助。

17、A security system is only as secure as its secret.Beware of pseudo-secrets.

一个安全系统的安全性取决于它保守的秘密的安全性。小心伪秘密。

18、To solve an interesting problem,start by finding a problem that is interesting to you.

要解决一个有意思的问题，首先找到一个你觉得有意思的问题。

19、Provided the development coordinator has a communications medium at least as good as the Internet,and knows how to lead without coercion,many heads are inevitably better than one.

如果开发的协调者有一个至少和互联网一样好的通讯媒介，而且懂得如何不通过强迫来领导，多个头脑不可避免地优于单个头脑。

几年前还在做程序员的时候读过一次这篇文章，当时并没有太多的感受，只是激发了我想做一个自己在开源世界中做些什么的冲动。因为是做c#的原因，当时找了大量的c#开源软件，想找一个契机参与进去，最后选定了DNN。06年做了DNNFamily网站进行DNN的技术推广工作，并提供DNN主机服务，后来因为工作原因这个事情也就不了了之了。这次重读，少了当年的冲动，多了些实际的思考。我目前的工作是企业IT部门管理，涉及软件开发管理工作，去年开发团队进行了敏捷开发的转型。所以，我想结合企业内部项目软件开发管理和敏捷开发两方面谈谈我对本文的读后感。

一、畅想“企业内部系统开源”
企业内部的软件项目往往涉及企业业务流程，不适于对外公开，而且因为各企业业务的差异，开源后对其他用户的价值也不大。如何能让企业内部软件项目享受到“集市”带来的好处呢？我有几点想法：
1、将中间件、公共组件开源，这类代码不涉及具体业务，而且复用性强，能为更多人带来价值。
2、企业内部共享代码，所有人可以接触到所有代码，记录每个人的贡献作为激励手段。
3、尽量应用开源系统、中间件，为员工创造接触开源项目的机会。
4、借鉴优秀实践，比如“早发布。常发布。听取用户的意见。”等。

二、“开源”和“敏捷”，以工程师为本的软件开发模式
近两年敏捷在国内异常火爆，我们也有幸在11年引入了敏捷开发（袁斌老师是我们的启蒙老师）。工程师是一类特殊的人群，他们兴趣广泛，但是他们可以专注于自己喜欢的事情上；他们喜欢隐藏自己的喜怒，但是他们渴望得到认可；“给我一个支点，我可以撬动地球”，他们笃信通过自己的双手他们可以实现任何奇迹；他们有自己的信仰，他们渴望完美。
为什么会有无数素未谋面的人为了开源项目无私地贡献自己的时间和代码，这是工程师的本性使然。他们无法忍受不完美，他们希望自己创造奇迹，他们希望得到认可。“开源”和“敏捷”之所以成功与流行是因为他们创造了“工程师的天堂”。

Eric Raymond有一篇著名文章《大教堂和集市》（The Cathedral and the Bazaar）。

他说，世界上的建筑可以分两种：一种是集市，天天开放在那里，从无到有，从小到大；还有一种是大教堂，几代人呕心沥血，几十年才能建成，投入使用。

当你新建一座建筑时，你可以采用集市的模式，也可以采用大教堂的模式。一般来说，集市的特点是开放式建设、成本低、周期短、品质平庸；大教堂的特点是封闭式建设、成本高、周期长、品质优异。

Eric Raymond就问了一个问题，有没有可能用修建集市的方式，造出一所大教堂？

我多年前读过这篇文章，上个星期与朋友在Email里讨论问题时，突然想到了它。

我们的问题是，有一个项目，方案A是精心准备后再投入使用，方案B是将半成品先公开，然后再逐步完善。这让我情不自禁地就想到了"大教堂和集市"这个比喻。

我们想造出一个大教堂，可是眼下只有一个集市，怎么办？

我找出Eric Raymond的这篇文章，重读了一遍，很多模糊的印象一下子清晰起来。到底是经典文章啊，虽然写在10年前，但是很多问题他都考虑到了。

他说，集市要变成大教堂，有几个前提条件：

1）你不能从零开始建设集市，你必须先有一个原始项目。（It's fairly clear that one cannot code from the ground up in bazaar style.）

2）你的原始项目可以有缺陷，但是它必须能运行。（It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is run.）

3）你必须向用户展示一个可行的前景，且让潜在的合作者相信在可预见的将来它会变成一个真正漂亮的东西。（When you start community-building, what you need to be able to present is a plausible promise, and convince potential co-developers that it can be evolved into something really neat in the foreseeable future.）

4）项目的主持者本身不一定是天才，但他一定要能够慧眼识别出他人的优秀想法。（it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others.）

5）项目的主持者必须要有良好的人际关系、交流技能和人格魅力。这样才能吸引他人，使别人对你所做的事感兴趣，愿意帮助你。（A bazaar project coordinator or leader must have good people and communications skills.）

4.

以上是一些必要条件，Eric Raymond也总结了一些成功的充分条件。

1）项目首先必须是你自己感兴趣的，但是最终能对其他人有用。

2）将用户当作合作者。

3）尽快地和经常地做出改进，多听取用户的意见。

4）健壮的结构远比精巧的设计来得重要。换句话说，结构是第一位的，功能是第二位的。

5）保持项目的简单性。设计达到完美的时候，不是无法再增加东西了，而是无法再减少东西了。

5.

Eric Raymond这篇文章，原始目的是要分析Linux的成功之道。为什么一个本科生的业余作品，最后竟变成了全世界最流行的操作系统之一？一个简陋的集市究竟是怎样变成壮丽的大教堂的？这个过程是否是可复制和推广的？

他认为，这就是开放的威力。一个开放式的项目，如果加以良好的管理和运作，能取得比同等的封闭式项目大得多的成功。

他这样看待大教堂和集市之间的竞争：

我认为，未来会更多地属于那些告别大教堂、拥抱集市的人们。

这不是说个人的远见和才华不再重要；而是在我看来，未来的成功者只是从自己的远见和才华开始工作，然后通过有效的社区合作，将其不断地放大。

开放式的文化会最终胜利，这或许不是因为"开放"在道德上正确，或者"封闭"在道德上错误，而只是因为开放式合作可以在一个问题上投入多几个数量级的技术工时，封闭的世界无法赢得这样的竞争。