大教堂与集市The Cathedral and the Bazaar，一本不像计算机方面的计算机书籍
命令式管理，适合和奴隶共事
目标共识型管理，适合和自由人共事
心性气层
只要眼多，bug好找
黑客开源：产品相关富足，赢得尊重不是因为占有什么，而是贡献了什么
如果你把它当成资源，它就会成为你的珍贵资源
如果不想做，找一个合适的接手人，知道什么时候收手，是一个不错的主意
“我是一个很懒的人，别人干活，我得荣誉”linus
如果认真的态度对待，机会自然会来。做有价值的事，一直做，早晚会有收获的。虽然劳动的价值来自稀缺性
开发软件不一定要从头开始，有个基础，虽然这些代码早晚要被替换掉，但却会是一个好的脚手架
早发布，多发布。鼓励用户的反馈，以合作开发者的态度和用户交流，会有一个稀缺的bug查找资源
没有用户愿意为一个bug等半年的时间
python,perl,c,c++,java
perl代码可以不用，但要能看懂代码
要以脱离具体语言的思维来考虑问题
学习编程语言，不只是学工具，还有思考方式
几年前还在做程序员的时候读过一次这篇文章，当时并没有太多的感受，只是激发了我想做一个自己在开源世界中做些什么的冲动。因为是做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的成功之道。为什么一个本科生的业余作品，最后竟变成了全世界最流行的操作系统之一？一个简陋的集市究竟是怎样变成壮丽的大教堂的？这个过程是否是可复制和推广的？
他认为，这就是开放的威力。一个开放式的项目，如果加以良好的管理和运作，能取得比同等的封闭式项目大得多的成功。
他这样看待大教堂和集市之间的竞争：
我认为，未来会更多地属于那些告别大教堂、拥抱集市的人们。
这不是说个人的远见和才华不再重要；而是在我看来，未来的成功者只是从自己的远见和才华开始工作，然后通过有效的社区合作，将其不断地放大。
开放式的文化会最终胜利，这或许不是因为"开放"在道德上正确，或者"封闭"在道德上错误，而只是因为开放式合作可以在一个问题上投入多几个数量级的技术工时，封闭的世界无法赢得这样的竞争。