说起软件工程这档事，我总有种不知从何说起的感觉。作为计算机专业的学生，早年都学过一门叫做软件工程的课，背下来一些流水线式的项目开发阶段，首先是在项目定义阶段要做可行性分析、需求分析这些事，再来进入到开发阶段要做概要设计、详细设计、设计实现等步骤，最后是维护阶段的运行与维护。仿佛软件开发就像《摩登时代》里的工厂流水线，分工明确。井然有序。目的是让程序员成为流水线上的工人，使他们成为生产机器中的一个螺丝钉，无需创意，无需个性，只要够熟练就行。很多大型企业的开发项目也确实是按照这个路数走的，很多程序员被戏称【码农】也正是这个原因。
但是，等我工作了若干年之后再来看这套工程管理模型，感觉这基本上就是个【计划经济】。首先，绝大部分软件在开发初期根本不会有那么多人参与，通常是两三个人要做所有的事情。分那么多阶段，那么多工序是没有意义的。再来，就算是有了一定规模的公司，他们会让很多人参与一个项目，往往都是为了维护已有的软件，程序员的主要任务是维护该软件的版本，并在此基础上开发新的版本，在这种情况下，他们其实已经有了现成的开发框架，这些人只需要根据特定的需求将该框架填充成具体的专用软件即可。对于原框架来说，这更像是增加了一个特性分支。例如说，jetbrain是一个通用的IDE框架，而android studio是专用于android开发的IDE，它就是基于jetbrain开发出来的。我们可以将它视为jetbrain的一个分支。这更像是某种意义上的维护工作，它的可行性，需求是一目了然的，也不需要概要设计，只需要按照其原有的插件体系把功能实现即可。然后，bug修复是这个项目的主要工作。所以，如何让那么多人一块有效地，有序地发现bug，报告bug，解决bug成为了主要问题。
上世纪的七十年代和八十年代爆发了两次所谓的软件危机。那时候的许多软件项目都出现了预算超支、发布时间严重拖延、质量管理缺失等问题。大量的项目因此而失败，问题很严重，以致于北约这样的组织都要开会来讨论这个问题。但这些高高在上的人物讨论出来的东西就是我们上面所说的软件工程理论。按照《人月神话》作者布鲁克斯的说法，这需要大量的银弹，人员来支撑。这只有大型企业，科研机构才能做到。当然对于这些机构来说，这套理论确实能解决一些问题。尤其在互联网时代来临之前，这似乎也是我们唯一的选择。
但大型机构都存在官僚主义的问题，效率低下，随着时间的推移它们往往都会离人们的实际需求越来越远，就像是基督教的大教堂，高高在上，定期发布信息，内容庞杂而臃肿。对于以创意为主导的中小软件开发是毫无帮助。于是Linux之父林纳斯在独自开发Linux内核的过程中走出了一条新的道路：开源社区。简单来说，就是由软件项目的创始人开发出一个不成熟的初始版本，然后将其丢到一个开发者社区中，让其在开发者自发性的修改和分享中自然生长。最后，项目创始人会根据其生长情况将自己认可的部分纳入到项目的主分支中。这种乱中有序的组织形式让Linux项目获得了巨大的成功。给软件开发的工程实践提供了另一种选择。
上世纪九十年代末期，网景公司在与微软公司的浏览器大战中败下阵来，面临着公司的生存危机。他们决定试试开源的方式。《大教堂与集市》这本书就是在这样的时空环境下写就的。它的作者埃里克雷蒙就是网景公司践行开源运动时所聘请的顾问。这本书为开源运动奠定了理论基础。他系统阐述了互联网条件下的协作模式，同行审评的优势，回答了《人月神话》中提出的银弹问题，人员管理成本问题。如今，微软、苹果这些曾经的大教堂都纷纷进入了开源领域。开源软件作为软件工程的另一种组织形式已经毋庸置疑。
最后需要提醒的是，开源运动和理查德斯托曼领导的自由软件运动不是一回事。开源运动更多的是一种软件的开发方式，虽然也强调开放源码、免费分享的黑客精神。但并不排斥世俗、商业。而自由软件运动则更像是一种意识形态的运动，非常的理想主义。非常激烈地反对商业化，有点乌托邦化。这客观上其实给源代码的分享带来了不少的阻力。
