王怀民
摘 要：在“软件定义一切”的时代，软件成为新型基础设施。软件开发经历了“自上而下，逐步求精”的工程范式，“自下而上，关联涌现” 的开源范式，到今天已转变为“宏观演化，微观求精”的群智范式，经历了从个体创作上升为群体化大规模生产、再到大规模群体创作这几个发展阶段。面对越来越复杂的软件需求，在更加不确定的人机物三元融合、万物智联时代，本文结合软件开发的长期实践，详细阐释了群智范式的理念和方法，以期为未来软件开发提供新思路。
关键词：软件开发；范式变革；工程范式；开源范式；群智范式
现在是“软件定义一切”的时代，软件已经成为新型基础设施。过去我们在计算机上开发软件，在计算机上运行软件，后来发展到互联网时代，通过网络开发软件，通过网络运行和提供软件服务。而到了今天，当数字产业化、产业数字化渗透到更多领域时，“软件定义一切”。
在20世纪60年代的科学研究方法领域，《科学革命的结构》一书曾提到所谓的范式或者范例变革。科学研究有一定的范式之规，往往一个范式确定下来后，大量的科学家就会在约定的范式中开展科学研究，直到这种范式不能适应科学的发展，才会迎来科学研究范式的变革。比如，业界经常谈到的第一范式、第二范式、第三范式、第四范式，还有现在谈得很多的AI范式，即用人工智能进行科学研究等，就是这种变革的体现。事实上，在软件领域同样有程序范式、数据范式等类似说法，这是从20世纪60—70年代后开始出现的说法。
今天，又到了范式变革的时代。有必要从软件开发的视角，对科学研究进程中的一些重要范式进行比较，以此探究我们应该以怎样的范式应对开源带给业界的机遇与挑战。
一、工程范式：自上而下，逐步求精
工程范式带来的变化，是将软件或者程序从个体创作上升为群体化大规模生产的软件开发模式。在此之前，软件开发如同在作坊中进行个体创作，像绘画、雕刻、木工等一样，是个体创作的产品，是人文成果。直到20世纪40—50年代，甚至20世纪60—70年代，业内开发软件时往往是先在脑海中设想软件跑通的情景，然后再调试部署到计算机上。那时的软硬件规模很小，从第一步到最后一步如何执行都可以在脑海中预演。但是随着数字计算机的出现，软件开发的效率和质量成为突出问题。例如，20世纪60年代，为了推动IBM360系列计算机在商业领域应用时可以适应各种外部硬件的需求，IBM开发出可移植、适应不同设备的操作系统。计算机操作系统的研发和应用在软件史上具有里程碑意义，给软件界留下了影响至今的操作系统关键技术；同时，也给软件开发变革带来一个重要启示，即软件开发所消耗的人力资源远远超出预期，软件质量的可靠性、可控性远远超出软件架构师和程序员的预期。人们发现，原来软件也是如此复杂和不可控的。所以在那个时代，处于工业化生产浪潮中的人们普遍认为西方成熟的工业化流程能够保证工业品的质量，于是顺势形成用保证工业品批量化大规模生产的方法来组织新软件开发的发展思路，这就是所谓的工程范式。
1968年，北大西洋公约组织在一次工作会议上提出“软件工程”的概念。北约是军事组织，冷战时期为应对军事挑战、争取在军事领域的领先地位而积极寻求新型信息技术的支持，因而对软件的复杂性以及保证软件开发的效率和质量有着最迫切的需求。在此背景下，北约投资并组织了一批计算机专家，研究如何解决或提高软件开发的质量问题，于是就有了工程范式基本理念的产生和实践。
（一）工程范式的理念和方法
我们将软件工程所遵循的软件开发理念和方法，称为软件开发的工程范式。理解这个范式理念，要从工业化大生产出发，首先是从工程技术中借鉴有效的产品开发组织模式，把人组织好，按照可控制、可预期的流程来设计和生产软件；其次是参照工业化带来自动化的经验，尽可能地研发软件开发工具，使软件开发的质量和效率得以保证。由此，软件开发有了各类V模型，从需求分析开始，然后进行系统设计、程序设计、模块测试、单元测试、集成测试、确认测试，最后再交付给用户一个满足需求的软件。与此同时，一个机构能不能有效地开发软件，对机构的软件开发能力成熟度该如何评估，软件能力成熟度模型（CMM）就出现了，这是一种用于评价软件承包能力并帮助其改善软件质量的方法。
再以自动化为例。20世纪60年代，高级语言逐步成熟，业内人员可以用更接近于人类学习或者训练成本较低的高级语言写程序，然后通过编译器将其自动转变为机器可执行的代码。在那一时间段，产生了源代码和目标代码，源代码和目标代码的变换过程就是由计算机工具，即我们所熟悉的编译器完成的。这些如今司空见惯的技术工具，在20世纪60年代，是巨大的技术突破。更进一步的是，软件质量行不行的问题，直接拉升了软件测试的工作量，通过自动测试，可以评估软件是不是能够确保某一个特定的功能性和非功能性的实现，这就促进了用自动验证方法进行软件验证等一系列技术的发展。
可以从以下三方面理解工程范式的理念。一是要把一个软件的需求说清楚，以确保软件开发的过程和质量。IBM360计算机就是为解决工程师头脑中的技术没有被精准描述，因而无法保证软件开发质量的问题。所以，给出明确的用户需求描述，是保证软件开发过程和质量的前提。二是软件质量，就是开发出来的软件能够满足需求规格说明的程度，满足的程度越高质量越好。三是软件开发效率，就是在需求确定的情况下，用更少的投资、更少的人力、更少的时间，更快地开发软件。那么，实现上述理念的方法是什么？就是组织工程师按照一个规范流程开发一套软件技术，并用支持工具保证软件开发所有阶段的自动化。更进一步，当时提高软件开发效率的一个重要手段，是用计算机来帮助开发软件。
（二）工程范式的瓶颈
随着IBM360计算机的广泛使用，软件开发效率大幅提升，改进能力逐渐提高，激发了计算机应用在更多领域的推广。但当人们对开发软件的复杂程度和质量有了更高要求时，突然发现按照这种方法开发软件，与制造一辆汽车等其他有形工业产品并不一样，工程范式软件开发方法在开发效率和质量上面临一系列问题。1995年，国际权威IT研究咨询公司Standish Group对美国境内8000个软件项目进行调查分析发现，83%的项目无法在既定时间内开发完成，开发周期平均超222%，52.7% 的项目预算超出原计划的189%，31.1%的项目在执行过程中因无法控制质量和成本而被取消。随着软件复杂程度变得更高，互联网时代到来了，软件开发面临着更大的挑战。
出现上述情况，业界有以下四点分析。一是工程范式遇到理论瓶颈。软件开发需要我们明确需求，但当软件需要应对越来越多的问题、互联网时代迅猛到来的时候，我们突然发现自身把一个问题说清楚的能力十分有限，过去把一个问题说清楚要以数学形式来表达，但实现这个能力在理论上存在界限；还有将需求用工具自动转化为可执行代码，同样有计算性和可判定性的瓶颈问题；此外，还存在变换的复杂性问题。大家发现，这一系列问题在理论上是不可逾越的。二是工程范式的效率问题。实践证明，软件开发效率怎么也赶不上“摩尔定律”带来的计算基础设施硬件发展的速度（处理器的性能大约每两年翻一倍，同时价格下降为之前的一半）。三是协同瓶颈。面对越来越复杂的软件，使用更多人力并不能提高效率，可能还会降低效率，甚至可能导致软件开发失败。四是网络时代到来后，业内在开发系统软件时发现，过去开发软件需要先确认需求，但在互联网时代，开发软件并不知道面对的用户是谁。只有当软件开发完成面世后被用户所接受，才可以验证出软件适合的用户群体。这些新情况，都给原有的软件开发方式带来巨大挑战。
二、开源范式：自下而上，关联涌现
互联网时代的到来，给软件开发也带来了重要变化。20世纪90年代，乃至过去的20年，促进软件迅速发展的方法不是我们所期待且瞩目的工程化方法，而是一个不被学术界甚至产业界关注的“下里巴人”状态。它带来了从群体化生产到大规模群体创作的变化，我们称之为开源范式。这种范式的起因是1974年贝尔实验室向大学免费开放Unix源代码系统。美国政府为保护在新兴计算机市场和软件市场的竞争优势，于是支持Unix操作系统免费授权给大学或研究机构做研究使用。随着Unix的自由发展、版本变多，AT&T开始重视Unix的商业利益，因此就出现版权回收问题，比如IBM等被授权的Unix商业版本代码不再能被自由传播，就出现了所谓的开源状态，出现了开放软件基金会。
20世纪90年代的软件系统格局由两部分组成，一是个人计算机占统治地位后，商业闭源软件成为主流，而另一个支流是在学术界传播和发展的Linux开源软件。开源范式支持在不确定的网络世界通过众多的开发者带来丰富变化和竞争，并自然演化出得到用户欢迎的软件制品。Linux正是通过开源范式带来的易变性和多样性，才更能应对未来操作系统发展的不确定性，当智能手机、云计算、物联网等新的需求涌现时，Linux的众多衍生系统就具有更强大的生存能力和市场竞争力。
开源时代的到来，主要是因为开源在互联网时代成为科技领域创新的主要驱动力。开源领域代码生长迅速，到1993年，Linux已经从当初只有一个代码，增长到大概10万行代码；再到现阶段，仅华为开放参与的代码规模就已经超过3300万行，涉及的工程师超过3万人，仅去年一年提交的代码就有120多万个。这种聚集起如此广泛的开发者和贡献者的开源状态，支撑起至少500个版本的开源操作系统被商业化使用。全球超级计算机TOP500强几乎均采用Linux作为其操作系统，而云计算操作系统也无一例外都使用开源系统。如今的智能手机、机器学习、大模型同样是开源系统状态。大模型领域中开源软件的应用非常活跃，由此带动了中国大模型不断涌现。开源之所以取得成功，是因为它通过多样性来应对不确定性。
20世纪80年代，在个人计算机时代，计算机发展的确定性使得微软以给企业操作系统发放闭源许可证的方式，获得对操作系统和软件的绝对定义权。作为当时先进生产力的代表，微软以其确定性视野定义了当时的互联网时代，也正因如此，无论操作系统版本如何演化，都完全由这家公司来控制。考虑控制成本，市场主导者就不会开发更多的版本分支，最好一个操作系统版本就能解决所有问题。当软件、操作系统的每个分支均由微软一家开发时，那么这家公司以企业化的方式组织数千个工程师，耗时几年全力开发一个新版本即可控制市场。还好，这种情况在互联网时代发生了变化。按照GPR模型，每个人都可以基于软件内核进行修改，修改后再反馈回来，这是一种双性范式。GPR下的内核可由软件下载方按照自己的理解书写新的版本，如此就可以产生相当多的分支，在不确定性的互联网时代，开源给软件、操作系统等在各个领域的探索提供了巨大的可能。也就是说，适应互联网不确定性的软件可能版本数量变多了，可成本却降低了，这或许就是开源成功背后的逻辑。
（一）开源范式的基本理念
相较于工程范式，开源范式有很多理念上和方法上的革命性变化。一是从需求看，开源软件没有明确的用户。在互联网时代，互联网软件并不知道自己的用户在哪里，用户就是开发者自己，开发者基于他所理解的世界进行创作，而不以明确需求为开发前提，这不像过去工程范式要求的那样，开发软件之前一定要明确它的用户群体。二是从质量看，什么是好的软件，开源社区中反响热烈的软件就是好的软件。三是从效率看，什么是效率，开源社区中有人提出问题后，响应快就是效率高。
（二）开源范式的瓶颈
不过，开源模式同样有其问题。开源时代的组织模式是自组织模式，工具主要是版本控制。实践中，软件开发的版本控制很复杂，而如此多的版本控制更是灾难性问题。另一个问题就是软件发布。现在开源技术发展如火如荼，当互联网在全世界广泛部署，开源就“遍地开花”了，由少数人、学术界走向全社会，成为一种通过互联网传播的开发模式。这个模式是适应变异和竞争的软件开发范式，可以称之为自下而上的开发方式，和自上而下的开发方式形成了鲜明对照。开源对中国软件发展产生了巨大的影响，也就是在开源大发展的阶段，中国软件终于获得了触达基础软件核心技术实现的机会。工程范式和开源范式都存在各自的问题。工程范式强调确定性，需要有确定的需求和确定的用户，按照给定的时间和预算，最终提交给软件使用者。工程范式强调的是要聚焦交付给用户的软件产品，而开源范式是一个自组织甚至是无组织的群体，最终实现的是程序员或者程序设计者的个人作品，软件发布不对最终结果做确定性承诺。
工程范式更加强调围绕质量和需求这样一个汇聚开发者智力的生产控制过程，而开源范式则是一个鼓励自由创作的过程。当然，确定性和不确定性没有好坏之分，当我们能够看到确定性的时候应该用工程化的方法来达成，当我们的目标不那么明晰时可以鼓励更多的可能性探索。那么，实践中如何平衡软件需求的确定性和不确定性之间的矛盾，进而更有效地、可预期地组织软件开发群体的智力？这就需要探索一个更加平衡的方式——群智范式。
三、群智范式：宏观演化，微观求精
实践中开源和闭源存在对立情形，那么开源和闭源是不是软件开发过程中最根本的问题呢？笔者认为，当需求明确、开发团队明确的情况下，通常针对确定的需求来完成工作，这就是工程范式；当软件需求不明确且开发团队也不确定的情况下，开源范式就是恰当选择。所谓的群智范式则寄希望于解决开源的两个不确定性，或者如何使软件开发的不确定性变为确定性，因为在开源社区，很多项目成果无人问津。数据显示，GitHub上有60%以上的软件从来没有被下载过，而真正称得上“成功”的软件不超过25%。通过对GitHub上发布的软件分析后可以发现，被关注且点赞多的软件和点赞很少的软件呈现长尾分布，被持续关注的软件很少，显然，这样一种智力汇聚在开源生态中却产生了不确定的长尾效应，就是开源软件可改进之处。
群智范式的关注重点就在于推动开源从大规模群体创作向群智软件开发的转变，同时平衡好软件开发确定性和不确定性的关系。实践中，所谓工程范式和开源范式或者开源和闭源之间的竞争，相同之处主要体现在群体智能使用的节奏和时机上。
（一）群智范式的理念
群智范式是集开源范式和工程范式的优点，在一个不确定性的世界，根据每一个核心团队对世界的认知选择推进工作的基本方法。群智范式开发的软件，其用户是潜在的，软件则通过原型版本的快速迭代来吸引开发者和用户。因此，理解群智范式中的软件质量问题，要看核心团队围绕开源软件构建的社区，看开发效率，还要看如何吸引更多的参与者进入社区并作出贡献。群智激发和汇聚的手段，如汇聚同样感兴趣的群体的感知，支持长效性的工作，支持保证质量和效率的开发流程机制，就是在工具上给予更好的支持。希望在更加不确定的人机物三元融合、万物智联的未来时代，群智范式软件开发方法能够有更好的实践沉淀，并逐渐发展成熟。
（二）群智范式软件开发方法
群智范式软件开发方法可以简单概括为“两个联接，一个转化”，即联接核心团队与外围群体，联接自由创作与规范生产，实现原型作品与原型版本之间的转化。今天我们可以从开源范式中借鉴的方法是，通过里程碑这个需求表述的集合明确需求。在此基础上，鼓励协同开发和快速迭代，尽快把原型版本释放出去，让更多外围群体参与到软件开发创作中来，贡献个体或群体的新需求、新代码。例如，在GitHub协同创作中，参与者可以自由地根据其需求修改某一软件原型版本后再提交回来，核心开发团队进行评估后，再将其集成合并到原型版本中。在这个过程中，核心开发团队可以按工程化方法或敏捷开发方法控制产品开发进程，同时开放出来的代码也允许外围开发者在此基础上自由创作，再提交反馈。如果提交的反馈版本不被核心开发团队接受，那么外围开发提交者还可以自由地让这个产品分叉，并按照其自主意愿开发新的分支版本，这是被允许的。
（三）群智范式软件开发需要关注的问题
开源的群智范式是宏观演化、微观求精，在阶段性的里程碑内，核心开发团队可以按照工程范式软件开发方法，也可以按照快速迭代或敏捷开发的工程化方法组织任务的实施。在宏观层面，软件是可以长期自由演变的，在这个过程中，最重要的是如何保持不确定性下的多样性，让更多外围群体能够参与到软件开发创作中，产出更多不同的分支版本。这其中需要关注三方面的问题：一是产出效率。尤其是不同的外围群体需要处理同一个问题时，最重要的是要形成群体感知，让对同一个话题感兴趣的团队之间能够相互感知，从而提高群智汇聚效率。二是长效性。群智范式下，虽然通过外围群体不断的迭代演化，可以使软件开发长期推进，但会出现很多提交的反馈无疾而终或只有一个反馈就不再继续修改的情形。如何让更多的人愿意长期持续参与，是群智范式需要思考的问题。有鉴于此，未来的群智社区应该设计一个平台或运用技术手段，给予群智激发持续有效的动力支持，以确保参与者相互学习、共同提高。三是可靠性，让有价值的软件越做越好。例如，持续集成（CI）/持续交付（CD）测试以及开发运维一体化等开源软件，就为云原生技术更好地成长提供了强大的技术支持。
从2006年开始，在国家“863计划”、科技部重点研发计划等政策的支持下，业内逐步形成了“Trusite”(中文品牌为“确实”)的核心技术体系与工具平台。Trusite首先把开源范式引入企业计算环境中，进而提出软件生产线构造方法，将软件创作活动与软件生产活动结合起来，重点解决了企业内、企业间的大规模软件协同问题。从2014年开始，Trusite探索如何把开源社区中涉及开发、应用、服务等不同功能版块的社区连接起来，以获得更广泛的信息共享。2020年后，以群智激发汇聚为核心，Trusite开始关注如何让一个核心开发团队——无论是企业的开发团队还是开源社区的开发团队——与外围群体实现更高效的协作。
当下，中国计算机学会发布的Gitlink平台是一个支持开源创新服务的平台，AtomGit测试版是一个支持开源创作的代码协作平台，开源中国推出的Gitee是国内的开源平台。中国需要有世界级影响力的开源平台，也因此我们要把这些平台的力量汇聚起来，构建一个开源的群智范式开发社区，推动群智范式进一步精化和丰富，以支持中国在未来更好的群智开发模式下，关键软件的开发能力和产出优势能够有新的提高，更好地服务于中国高质量发展，服务全世界。
参考文献
[1]王怀民、余跃、王涛、丁博.群智范式: 软件开发范式的新变革[J].中国科学: 信息科学, 2023, 53(8): 1439-1440.
（作者系中国科学院院士、分布计算领域专家）