本文基于《大教堂与市集》一书的观点，探讨了开源软件开发的两种模式：大教堂模式与市集模式。作者通过对比两种模式的优劣，提出了市集模式的适用场景，并分析了其背后的逻辑与影响。同时，通过引用POUL-HENNING Kamp的文章，揭示了市集模式存在的问题。最后，结合当前项目的实际，提出市集模式与大教堂模式各有优势，关键在于找到合适的应用场景。
《大教堂与市集》（The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary）一书中提到了软工工程的两种开发模式，即大教堂模式和市集模式。作者认为“Given enough eyeballs, all bugs are shallow”，也就是支持市集模式。
我没有读过这篇文章，只是从维基百科上了稍稍了解了这本书的内容。从其观点来看，我认为，作者写这篇文章，是鉴于当时的自由软件开发的现状。他不满于当时开发软件的低效率，而且，他认为，低效率的原因在于除错阶段花费了大量的时间。由此，他把开源软件的开发模式分为两种，一种是大教堂模式，源码公开，但是开发过程有一个团体控制；一种是市集模式，同源源码公开，且源码放在互联网上供人阅览，并可以贡献代码，进行开发。并且提倡市集模式，认为在足够的人的检视之下，BUG将无处藏身。
这篇文章的影响是巨大的。目前，从开源软件的繁荣课件一斑。不过，这并不意味着市集模式是完美的。POUL-HENNING KAMP的文章Generation Lost in the Bazaar（中文版《有人负责，才有质量：写给在集市中迷失的一代》），就是对于市集模式的批判。这篇文章从目前FreeBSD的杂乱无章的现状入手，认为正式集市模式造成了这一切。Kamp认为，作为软件，所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。而目前的市集模式，没有一个人对某个东西负责，或者说所有人都对其负责，就意味着没有人负责。这就造成了现如今的FreeBSD系统中众多的软件没有规则的相互依赖，且众多的软件功能相似，没有完成软件工程一贯追求的代码复用。
在我来看，市集模式既然能为全世界所接受，必有其优点所在。所谓“众人拾柴火焰高”，当然软工工程不能类比于“拾柴”，不过道理确实是这个道理。而后来Kamp的文章，则点明了其缺点所在——人多反而碍事。
其实，以我目前的观点，不论是市集模式还是大教堂模式，都有其优缺点所在（这在上文中已经可以看出），关键是找到其适用的场景。这个观点虽然中庸，不过确实是实话。我以为，大教堂模式，适用于小的项目，或者是团队中有一个技术大牛带领，不需要过多的人来指点。而市集模式，则是那种涉及的方面比较广泛的项目，且不论如何，应该有一个几个人的团体对于项目的整体走向、代码有绝对的控制力，否则，会造成Kamp所说的那种混乱局面。
我们当前的项目（学霸系统的UI之用户管理部分），可以说是类似于大教堂模式。之所以说，类似，是我们的源码并非在互联网上公开的，只是相像而已。一来因为项目比较小，如果非要应用市集模式，可能会有意见无法统一，浪费资源的问题。此外，除了本组的人外，也并没有人其他的一些人关注这个项目，不具备市集模式的要求，No enough ebyballs，bugs will not shallow。
题外：在读这些文章的时候，总是会有想睡觉的冲动。我觉得原因主要是两个，一是阅读英文吃力，往往读了半天都读不进脑子；二是关于软工工程的文章并不是那么的吸引人，既无小说的引人入胜，亦无技术书籍的技术提升快感。如何解？
扫一扫
296
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
