大教堂与市集
在软件工程历史上，Eric S. Raymond 于 1997 年发表的文章《The Cathedral and the Bazaar》（大教堂与市集）是一篇具有里程碑意义的重要文献。文章用“大教堂”和“市集”类比了“自上而下”和“自下而上”两种软件开发方法，深入探讨了软件开发过程中的不同方法论及其影响。这篇文章不仅对开源社区产生了深远影响，还为现代软件开发人员提供了宝贵的经验教训。
大教堂与市集
大教堂模式的特点是源代码在软件发行后公开，在软件的每个版本开发过程中由一个专属的团队控管。作者以GNU Emacs及GCC这两软件为例。大教堂模式的开发过程类似于中世纪的大教堂建造——由少数精英开发者在相对封闭的环境中进行开发和设计，直到软件接近完成时才对外发布。开发周期长，版本发布频率低，强调计划和控制，追求高质量和稳定性。在当时这是一种更为传统的开发模式，代码只有在达到一定成熟度后才会发布给用户。GNU 项目就是这种开发模式的代表之一，它强调高质量、可维护性和稳定性，但开发周期往往较长，创新速度相对较慢。
市集模式的特点是源代码在开发过程中即在互联网上公开，供人查看及协作开发。作者以Linux内核的开发为例，并引用自己负责的Fetchmail的开发为例。市集模式更像一个热闹的集市——任何人都可以参与开发，代码在开发的早期阶段就向公众开放，并且频繁发布版本。通过社区的集体智慧和贡献，快速迭代，快速修复问题和添加新功能。这种模式主张所有开发过程公开透明，任何人都可以参与进来贡献代码或提出建议。Linux 操作系统就是市集模式的成功典范。Linus Torvalds 创建 Linux 内核时，将其代码开放给大众，鼓励全球范围内的程序员共同参与开发。这种模式使得问题能够迅速被发现并解决，创新和改进的速度也快得多。
从我们今天的视角来看，Linux 不仅在服务器市场占有重要地位，而且在桌面电脑、嵌入式系统和移动设备等多个领域都得到了广泛应用。其高稳定性和灵活性使得 Linux 成为了企业级应用和开发者社区的首选。市集模式造就了今天的 Linux，也直接影响了其后的一系列开源软件。
Linux的成功秘诀
Linux 操作系统其实并不先进。Linus Torvalds 的老师 Andrew S. Tanenbaum 在 1992 年发表了一篇题为 “Linux is obsolete”（Linux 已经过时）的帖子，引发了著名的 Tanenbaum–Torvalds debate。Tanenbaum 认为 Linux 采用的是单内核（宏内核）架构，是过时的技术，是“回到1970年代的巨大退步”（a giant step back into the 1970s），现代的操作系统应该像 GNU Hurd 一样采用微核心架构。而 Linus 更强调简单实用的重要性，Linux内核采用宏内核架构，是因为它能够简化核心设计。如果 GNU Hurd 能被开发出来，他就没有必要开发 Linux 了。事实上，尽管有大量开发者在 GNU Hurd 上花费了比 Linus 多得多的时间，但由于微内核架构的复杂性以及资源有限，GNU Hurd 的开发进展缓慢，至今也没有得到大量的应用。反而 Linux 凭着其简单有效的架构，快速吸引了大量开发者贡献代码，并且很快形成了一个庞大且活跃的社区，使得 Linux 内核迅速成熟并广泛应用。今天，当我们提到 GNU/Linux 时，实际上指的是使用 GNU 工具链结合 Linux 内核的操作系统。
Raymond 在《The Cathedral and the Bazaar》一文中，对 Linus Torvalds 的评价非常高，特别是对他在项目管理和开发方法上的创新给予了高度赞扬。相对于 Linux 作者这个技术成就，Raymond 认为 Linus Torvalds 的成功更在于他对一个大型开源项目的高效组织和管理。开放的开发模式促进了广泛的协作和快速的创新。任何人都可以贡献代码，这使得问题能够更快地被发现和解决。这种模式下的开发者社区能够更快地适应变化和进步。Linux 的成功大概可以归纳为以下几点：
- 广泛参与：市集模式鼓励大量开发者参与，不论是核心代码贡献者还是一般用户，都能对项目的发展产生影响。由于开源项目的代码是公开的，任何人都可以查看、修改和分发，这大大增加了参与度。大量的开发者不仅带来了多样化的技术和视角，也有助于更快地发现和解决问题。
- 快速迭代：在市集模式中，软件频繁发布和更新，每个版本都是对前一版本的优化和提升。这种快速迭代的方式使得项目能够迅速适应用户的需求和市场的变化，及时修复bug并添加新功能。
- 透明度和开放性：所有的开发过程都是透明的，代码库、开发日志、问题跟踪系统等都是公开的。这种透明度不仅增加了用户和开发者之间的信任感，还促进了知识共享和协作创新。因为每个人都可以看到他人的工作，学习和借鉴变得更加容易。
- 灵活性和多样性：不同背景和技能的开发者参与到同一个项目中，他们会提出各种各样的意见和建议，使得软件能够涵盖更多的使用场景和功能需求。比如，某些开发者可能专注于安全性，而另一些则关注性能优化，这种多样性使得软件更加全面和健壮。
- 社区力量：开源项目通常伴随着一个活跃的社区，这个社区不仅是开发者的聚集地，也是用户交流和反馈的平台。社区成员之间的互动和合作，使得项目在发展的过程中获得持续的支持和动力。 无疑，我们今天所认可的那些 Linux 系统优秀特质——开放、安全、可靠、高度灵活——与这种开放的开发模式是密不可分的。
大教堂还是市集
凡事都有两面性，虽然 Linux 采用市集模式取得了成功，但是我们也不能彻底地否定大教堂模式。子曰：“择其善者而从之”，我们需要根据实际场景，去选择合适的方法。作为一个普通的软件从业人员，我们可能没有机会，也没有能力去创造 Linux 这样级别的软件。但是不管多大的软件都离不开软件工程的方法论。在开发过程中，加入更多的控制和规范化，更有助于维护高质量的代码和一致的架构标准；如果过于追求灵活，就要求团队能够自组织，需要有效的工具和流程来管理需求和代码质量，如自动化测试、持续集成等，这无疑对团队能力要求更高。有些项目需求明确并且变化少，使用按部就班的瀑布方式或者迭代方式可能更合适。有些项目不确定性大，需要经常变化，那么就必须采取更敏捷的方式，加大与用户之间的互动，快速迭代。
我在工作中经常需要去审核一些项目的工时，这其中经常需要和项目经理或者产品经理就一个项目到底需要多少工时去“扯皮”。我认识的一位产品经理是这样评价他们项目组的工时的：开发人员计划是20天，但是你放心，等提测的时候，肯定一堆 Bug，要再改个七八天，然后业务人员验收测试，再提一堆优化意见，再改个七八天，正式上线后，更多的业务人员又有更多的优化意见，又要再改。最终项目真正能稳定运行差不多要两个月。这种模式下，不仅业务人员的体验非常不好，开发人员也怨声载道，最终代码质量也无法保证。更可怕的是开发团队对此习以为常，认为这就是开发常态。
现在，不管是互联网产品还是企业用户，都在提倡去拥抱变化，并且适应变化。市场环境，客户政策始终在不断变化，谁的系统能更快速地响应变化，谁就能在竞争中取得先机。怎样通过架构去识别系统中的“变”和“不变”，这是一个很有深度的话题，我们可能需要一篇更长的文章才能说明白，但是只要团队能够有意识地，主动地去采取方法应对需求的不确定性，这就是一个良好的开始。