查看原文
其他

瞰见|谁说大教堂就真落伍了?

狄安 OpenTEKr 开源星系 2022-04-06

经验永远不会对你做错误的引导;

把你引导错的只是你自己的判断,

而你的判断之所以对你产生误导作用,

乃是由于它根据那种并非借着实验而产生的经验来预料的结果。

—— 达芬奇 


作者 | 狄安

Jan. 10, 2022

3487 字 | 大约需要 6 min


前些天,我们的朋友 tisonkun 写了一篇《大教堂与集市》的读后感,将当下的开源与当时的观点交叉后全面生动地解读了这本开源运动的经典之作,引起了我再读此书的兴趣。个好的作者总能回答很多话题,一个卓越的作者却更能引出一些有趣的话题。每读每新,对于作者 Eric S. Raymond (下文简称 ESR) 在书中提出的关于开源的很多有趣话题,比如“大教堂”,我在重读中也有了一些更新的认识。


1

  大教堂 vs 集市

《大教堂与集市/ The Cathedral and the Bazaar》本是属于他文集中的一篇论文,而 ESR 以该文来命名全书,可见其重要性。事实上《大教堂与集市》作为开源圈经典流传,是基于 ESR 对于开源现象的深刻洞见和独特的观点。同时,作为一个很会讲故事的作者,其中最有特色的就是:他以“大教堂”来寓意软件工程中的集中开发模式,以“集市”来寓意开源的分布式开发模式,然后通过对这两者的比较,推导出了开源的“集市”模式是对传统软件工程的一种颠覆,而“大教堂”所代表的集中式开发则已经是一种相对落伍的模式
作为一个开源运动的倡导者和布道者,在这点上,他的确是高明的,尤其是他以“大教堂”和“集市”这两个鲜明的比喻来说明传统软件开发和开源模式间的差异,也让很多人一下认识到了开源模式的创新性和独特性。

但,有很多人可能不了解,用“大教堂”作比,并不是由 ESR 最先想到的。大教堂实际是来自软件工程界的传奇经典《人月神话/ The Mythical Man-Month》一书。而且,《人月神话》里的“大教堂”和 ESR 说的“大教堂”,竟然还有些不是那么一回事


左/《人月神话》 

右/《大教堂与集市》


“大教堂”一词最早是出自于《人月神话》的第四章。此书的作者是被业界称为IBM360系统之父弗雷德里克.布鲁克斯博士(下文简称 Brooks),他以自己在IBM公司承担 360 系统的项目开发管理经验以及其他大量软件工程实践,为每个复杂软件项目的管理者给出了自己的真知灼见,并探索了软件设计中概念完整性和一致性的重要性和解决方法等,是任何时代下的软件工程师完全值得的必读之作。 
仔细读过《人月神话》的读者一眼可以看出,ESR 在他文章中对于大型软件工程复杂度的阐述显然是受到了 Brooks 的启发和影响。无论从他书里引述的内容,还是协作风格,都无处不在地体现着 Brooks 的影子。一方面他基于 Brooks 的观点提出了开源集市模式的新观点,另一方面也显示了他对老一代软件人的致敬和尊重。甚至于对书封面的选择,ESR 也是选用了俄罗斯画家柳博芙.波波娃的以立体主义和未来主义相结合的著名画作《以图构图 /composition with figures》,我猜这是他向老一代软件人致敬的一个彩蛋。要知道 Brooks 在《人月神话》中的写作特色,就是喜欢在每个章节前引用一句他所钟意的名言、名画或名建筑来开场的


左/ Brooks   右/ ESR


不过,话说回来。再回头看《人月神话》中 Brooks 说的大教堂其实并不是在说软件工程集中式开发管理的复杂,准确一点说,Brooks 其实是在讲软件工程另外一件非常重要的事情:软件设计的概念完整性和计的一致性。而这点却是无论集中模式还是开源模式,只要涉及软件开发,都无法忽略和忽视的。

如果我们只是简单地按照 ESR 给我们灌输的观念,去理解大教堂模式的落伍、集市模式的先进,那么无疑是具有片面性和局限性的,这也会阻碍我们更好地去理解开源的本质。 


2

大教堂

首先,Brooks 说的“大教堂”不只是一个比喻,而是有个真实的大教堂故事。他在讲述关于「贵族专制、民主制和系统设计」的第四章中开始就描述了那个他心中真正的大教堂-法国兰斯大教堂 (Cathédrale Notre-Dame de Reims)。



百度百科里是这样记载的:

兰斯位于法国东北部香槟-阿登大区的马恩省,是法国的历史文化名城,素有“加冕之城”的美誉。历任法国国王加冕之处的兰斯圣母大教堂(Cathedral Notre-Dame de Reims),在法国的作用相当于英国的威斯敏斯特教堂,巴黎圣母院亦是仿照其建造,是哥特式建筑的杰作之一。1991年,兰斯的圣母大教堂被联合国教科文组织世界遗产委员会批准作为文化遗产列入《世界遗产名录》。


兰斯大教堂的神奇之处是在历经八代设计师和建筑的过程中,整座教堂令人出乎意料的在建筑风格上保持了完美的一致性。这个和欧洲其他的一些大教堂形成了鲜明的对比,因为一般的欧洲教堂会由不同时代不同建筑师分不同的时期来建造。由于每个建筑师出于自己的想法和创作意图,后面的建筑师往往为了出于提高和反映自己的风格及体现个人品味,导致教堂在设计和结构风格上存在许多差异


左/日照时    右/ 夜幕下


所以,经常会出现哥特式的教堂里依附诺曼底风格的十字架等,在显示了上帝荣耀的同时也彰显了建筑师的独特。虽然它们的独特性也为人称道,但,兰斯教堂却以出奇的概念完整性和设计的一致性让人们赞叹。而这个背后就是参与设计和建造的八代建筑师对于自我的要求和牺牲,以严格地约束自己放弃掉那些可能拥有的独特创意,来最终保持了教堂设计的纯粹性。想来 Brooks 可能是实地去参观过后,被兰斯大教堂的建筑风格所震撼,并由此联想到了软件设计中相关问题。


一个软件的设计开发虽然现在无需经历几代人,但同一个软件任务经常会由不同的软件工程师来完成。Brooks 坚持认为对于软件开发设计中,概念的完整性和设计的连贯性是极其重要的因素。因为它的裨益非常明显,对于开发人员来说是让软件更加容易开发,对于用户来说是更加容易使用。所以,软件应当像兰斯大教堂那样的被开发建造出来


在对于如何「保证概念完整性和一致性」的解决方法上,Brooks 在当时就大胆而有见地的提出:概念的完整性要求设计必须由「一个人或者非常少数互有默契的人员」来实现一个成功的软件系统,如果是一个人主导的,那么会很大程度上依赖最初设计者的全局观和天才,后续的建设者则需要放弃部分自己的想法和个性,来延续设计的完整性。‍


这在《人月神话》20年周年以后的纪念版补充章节中,Brooks 又再次确信和重申了他对于软件设计的概念完整性的几个重要观点的坚持:

1.概念完整性是软件系统设计中最重要的考虑因素

2.为了获得概念的完整性,设计必须由一个人或者具有共识的小团队完成

3. 纪律和规则是有意的,外部的规定实际上是加强而非限制创造性的实现


4.体系结构、设计实现、物理实现的许多工作可以并行


所谓的经典就是能够经受住时间的考验。Brooks 关于「软件设计概念完整性和一致性」的观点在20世纪70年代中期被提出,历经技术的变迁和市场的变化,直到纪念《人月神话》四十周年的中文版发行时,依然在被行业的实践证明其有效性。这就是经典。 诚然,传统的集中式软件的开发管理是复杂的,但进一步讲,开源软件的开发管理难道就没有复杂度了吗?一个优秀的开源软件,能从一个或者几个爱好者的级别开始再上升到社区里不同人员参与贡献的程度,实际上也必将经历从不需要管理再到管理复杂的程度。否则,林纳斯也不会在开发了Linux之后,再去专门开发了一个管理 Linux 开发的开源软件Git。而也正由Git开源社区的发展,产生了如Github、GitLab 和中国的 Gitee等开源代码托管和开发协作平台才撑起了开源开发管理的江山。


左/ 大教堂    右/ 集市


所以,从软件项目的管理而言,只不过是原来集中式管理变成了开源社区集市模式,治理的难度系数实际上是不会比传统集中式开发小多少的我们不能因为 ESR 将集市模式比作对于大教堂的替代而想像成两者之间的对立关系。集市模式里大教堂,依然具有存在的必要性和重要性。关于这个观点,《大教堂与集市》的中文版译者卫剑钒也在其文《开源的7大理念》《每个人都是一座教堂》都有提及,并客观地指出网络组织下的并发无序开发未必就能够成为一种有效的开发方法

这很像是一大群能工巧匠(包括一些建筑公司的团队),不管出自何种利益考虑,为了一个共同的目标,从世界各地自发参加一个大教堂群的设计和建设,Linux内核就是这样一个大教堂群,每个子系统都是一个大教堂,每个大教堂都有着负责设计和建造的领导人,其下有有着数百名建造高手,他们在共识和规则之下,使用着像git、gcc、邮件列表这样的设计、建造和协同工具,利用集体的力量(他们会讨论,也会投票),把这些美轮美奂的大教堂建造出来。Linus 作为最高领导人,不会强制他们,更不会发薪水,一切都是这些高手自发自愿自带干粮,不管是个人还是公司。集市模式和大教堂模式的本质区别只是在于:前者是自发的,也是自治的。

ESR 在《大教堂与集市》中将“大教堂”比作了一个落后于开源的集市开发模式的代表性词汇,让全世界的程序员知道了大教堂与集市的差别,当然也没有什么错,但却忽略了“大教堂”般的软件工程模式代表着软件开发中本质的一些观点和概念,实际上并不会因为开源的集市模式出现而落伍。恰好相反,如软件概念的完整性和设计的一致性等,“大教堂”模式依然是一个优秀的开源软件所应具备的特性和本质



拥抱开源,认清内核

开源是一种新型的软件开发模式,在资源组织和开发协作上的确有其先进性和创新性。但无论是开源软件还是商业专有软件的开发,只要是软件,就有软件本身内在的一些本质特性需要遵循,我们需要明确的是,这些特性未必会因为开源模式而改变

同样,随着开源热潮和社区的不断兴起,各种开源力量的参与社区贡献和社区治理,我们与其争论开源社区在何种模式下更为合理,不如
去专注于那些属于开源真正应有的内在特性,可能更会让开源发扬光大




注:封面图和文中引用图片均来源于网络,侵删。本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。



/// 关于作者 ///


狄 安

OpenTEKr 创始人 & 开源布道者

企业级软件领域的连续创业者,开源领域的独立研究者。现从事开源和数字化领域的文化研究和理念布道,及开源和商业结合的探索与实践。



/// 关于 OpenTEKr ///


OpenTEKr 是一家以推广开源软件开放硬件技术为核心的开放式非营利组织,致力于构建一个可持续发展的开放科技生态圈。基于“众有、众享、众治”的信念,我们依循「自由与规则同在,免费与商业共生」的原则,憧憬科技普惠的美好未来,帮助个人和组织通过变革性技术创新来成就非凡自我



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存