上周稍微一懒就没有写文章，鄙视一下自己。自律是个很有意思的锻炼。看到自己的惰性也是正确认识自己的一部分（这个理由找的真是清新脱俗 Lol）
这周介绍开源运动享誉盛名的一本书《大教堂与集市》，作者是Eric Raymond，著名的开源运动旗手。这本书是他在1997年到2003年的几篇长文的汇编。虽然是不同时期的文章汇编而成，但是这本书前后的逻辑线还是很连贯，比起一些专栏作家的“文集型”出版物要良心得多。
本书的一个核心议题是，Linux社区的“开放到几乎是混乱”的合作模式，竟然可以构建出这样一个世界级安全性、稳定性、扩展性的操作系统，这背后的原因是什么。正如作者所说，对于一般人
既稳定又一致的一个操作系统就这么诞生了，这真是奇迹中的奇迹。
从这个议题出发，作者对比了两种不同的开发模式：“大教堂”模式：大多数闭源商业软件的模式。软件的开发过程由一个专属团队掌控；“集市”模式：Linux为代表的模式。源代码在开发过程中即在互联网上公开，任何人都可以参与开发、构建和检查。
作者深信，Linux的成功，和其采用的“集市”模式紧密相关，并使用自己的一个开源项目fetchmail作为实验，分析这一模式下软件项目的开发、演化和维护过程。
我打乱文章的顺序总结一下“集市”模式的成功的原因，主要有两个方面。
第一是开发层面。书中提到作者和一位资深的软件开发管理者的交流，指出“大教堂”模式中对资源消耗巨大的“软件开发管理”的五个功能：
1. 明确目标让大家朝同一个方向努力；
2. 监督并确保细节不被遗漏；
3. 激励人们去做那些乏味但必要的“体力活”；
4. 组织人员部署并获得最佳生产力；
5. 调配项目所需的资源；
然后做着提出：
显然所有这些目标都是有价值的，但是在开源模式及其所在的社会语境中，人们会惊奇的发现这些目标毫无意义
这个观点的主要原因是，由于在开源世界中的项目参与大都是技术能力较强并且对所参与的项目有着很强的自主工作意愿。这些人是因为问题自身的魅力而却解决它的。因此在强烈的主观能动性的驱使下，加上自身的工作能力，成功的开源项目聚集到的往往是任何的商业软件无法组建的战斗力极强的明星开发团队。这样的团队内部的相互合作与碰撞，产生的成果完全可能是一群为了保住饭碗而工作的程序员的上百倍。
正如Linus Torvalds的传记标题《Just for fun》叙述的，“乐趣”是激发伟大的成功的原动力。
第二是测试和质量层面。Brooks在软件工程著作《人月神话》一书中曾经提到过一个现象：“用户越多，bug越多”。这是因为增加用户就会增加程序被检验的方式。在“集市”模式中，由于用户同时可以看到源码，这种效应会被放大，他们不仅可以找到bug，而且会提供极高质量的直接关联到源码的分析型bug报告。如此一来，当参与者足够多时，“集市”模式会行程一个极其有效的QA系统。
当然，“集市”模式的成功也是有条件的。理想状态下，这个项目必须有一个同时也是核心用户的开发社区，从一个可运行的原型系统而不能从0开始，项目的领导人需要极强的协调和够沟通能力，并且有快速识别设计、实现的好坏的嗅觉等等。这些也解释了为什么成功的开源项目大多是内核、类库、框架、编辑器，而不是办公软件、绘图软件等等的专业软件。
在后续的篇章里，一个比较重要的部分在“魔法锅”一节中。作者通过对软件的销售和增值方式进行分析，进一步给“集市”模式照亮了无比光明的未来。简单说来，作者认为有数据表明，超过75%的程序员报酬都被支付给了维护工作而不是初始的开发工作。而开放源代码的“集市”模式，虽然会减少软件的一次性销售价值，却可以极大的减少软件的维护成本，保证软件的质量始终维持在一个很高的水准上。企业，则可以通过提供用户界面、系统集成等增值服务来获得利润。
看完这本书，我不由得把书里的内容和自己工作的企业和软件开发项目作了对比。不得不说这本书的观点是技术人员的心声、也是愿景。技术人员从自己的经历和认识角度出发，往往会同意好的程序员是平庸程序员生产力的几十上百倍；快乐的程序员比生活所迫的程序员能做出更好的产品，这一类的观点。相反很多产品或者商业出身的管理者，由于终身没有写过一行代码，很难从这样的角度出发考虑问题。他们往往会觉得，任何的程序员都是可以替代的，如果你不高兴，我也没必要哄着你高兴，你可以继续不高兴，或者离职。这两种观点造成了很多企业一线程序员和管理者的矛盾。坦白说我相信这只是又一出现代版的“盲人摸象”。管理者站在资本的角度，一线技术人员则从技术的角度。两者的观点是矛盾的，但是确能合在一起更好的描述软件开发的全貌。这就好像系统工程里对复杂系统的建模，讲究使用不同维度不同角度的多个模型，来描述系统的行为。
最近工作中正好参与到一个6000+ star的开源项目中，在这个时候翻阅了这本书，开启了很多不同的视角。希望自己日后能对开源方式和软件工程的这种种矛盾与困难有更深刻的理解。
