first commit
This commit is contained in:
commit
080f32a7dd
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 439 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 152 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 115 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 203 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 87 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 166 KiB |
|
|
@ -0,0 +1,404 @@
|
|||
<font size=6>**群智范式白皮书 —— 软件开发范式的变革与实践**</font>
|
||||
|
||||
<font size=5>目 录</font>
|
||||
- [1 引 言](#1-引-言)
|
||||
- [2 群智范式是什么](#2-群智范式是什么)
|
||||
- [2.1 群智范式的核心理念](#21-群智范式的核心理念)
|
||||
- [2.2 群智范式的软件生命周期](#22-群智范式的软件生命周期)
|
||||
- [2.3 群智范式的软件开发方法](#23-群智范式的软件开发方法)
|
||||
- [2.4 群智范式的软件开发模型](#24-群智范式的软件开发模型)
|
||||
- [3 为什么提出群智范式](#3-为什么提出群智范式)
|
||||
- [3.1 工程范式：从个体创作到规模化生产](#31-工程范式从个体创作到规模化生产)
|
||||
- [3.2 开源范式：从规模化生产到大规模创作](#32-开源范式从规模化生产到大规模创作)
|
||||
- [3.3 群智范式的提出与三类范式的对比](#33-群智范式的提出与三类范式的对比)
|
||||
- [4 群智范式怎么做](#4-群智范式怎么做)
|
||||
- [4.1 群智范式的软件开发平台](#41-群智范式的软件开发平台)
|
||||
- [4.2 群智范式的平台项目](#42-群智范式的平台项目)
|
||||
- [5 结束语](#5-结束语)
|
||||
- [参考文献](#参考文献)
|
||||
|
||||
# 1 引 言
|
||||
|
||||
  在“软件定义一切”的时代，如何定义软件[1]？这是一个大问题！软件开发作为人类当代独特的智力活动，经历了从作坊式的个体创作到工业化群体大生产、再由工业化群体大生产回归大规模群体创作的历史转变，经历了工程范式与开源范式两次变革。在人机物三元融合智能互联泛在计算时代[2]，计算平台的泛在化必然驱使软件应用的泛在化，应用场景的多样化必然带来软件演化的不确定性，孕育了软件开发的新范式 — 群智范式[3,4]。
|
||||
|
||||
  群智范式是我们对软件开发本质的再认识以及对泛在计算时代软件开发理念和方法的再思考。软件开发是一个大规模群体通过群智激发和汇聚来解决复杂任务的活动，其本质在于“群体智能”。不论是工程范式还是开源范式，都是面向特定问题实现群智激发和汇聚的一种方式，差别在于：工程范式聚焦线性确定性问题的软件开发，通过强组织模式实现高效群智“汇聚”，几乎放弃对不确定性问题的关注；开源范式则全面拥抱不确定性，通过开放共享实现高效的群智“激发”，但对结果不做确定性承诺。群智范式则重点关注在群智激发和汇聚之间、在确定性和不确定性之间寻求平衡和融合，其基本理念可以概括为“宏观演化、微观求精”，其开发方法可以凝练为“两个联接、一个转化”。
|
||||
|
||||
  工程范式、开源范式与群智范式这三种范式的产生和发展虽有时间先后顺序，但在实践中三者不是完全替代关系，工程范式与开源范式在很多场景下行之有效并被广泛实践。群智范式不是对前面两个开发范式的否定，而是希望在工程范式与开源范式之间找到平衡，结合时代特点与应用场景指导我们的软件开发实践。
|
||||
|
||||
  2023年6月，中国计算机学会联合开放原子开源基金会、开源中国等学术界、开源组织及产业界的力量共同发起“群智范式”平台项目，希望将群智范式的核心理念、开发方法等物化为基础平台的机制和能力，共同建设面向群智软件开发的新型基础设施，力图为我国群智生态构建与发展提供支撑。
|
||||
|
||||
# 2 群智范式是什么
|
||||
|
||||
  在计算技术发展的历史进程中观察软件开发技术的发展，我们可以看到，软件开发面对的危机一个接着一个，这些危机不仅推动了软件开发技术的发展，而且带来了软件开发理念和方法的深刻变革，我们称其为软件开发范式的变革。群智范式是我们站在计算技术发展历史时间轴上，回顾和比较个人计算时代和网络计算时代软件开发工程范式与开源范式的发展，思考泛在计算时代的软件开发而提出了一种新的软件开发范式。
|
||||
|
||||
## 2.1 群智范式的核心理念
|
||||
|
||||
  软件开发活动是一个智力密集型活动。随着计算技术的发展，作为软件开发关键要素的“人”发生了显著变化：参与者规模由过去的公司/组织内部封闭环境下的数百至数万人，演变为开放环境下通过互联网联接的数万数十万人；参与者类型由过去的主要是开发者，演变为软件生态系统中开发者、用户、管理者、投资人等多种不同类型的群体深度参与；参与者个体角色从单纯的软件开发者或使用者等单一角色，演变为软件生态系统的参与者和推动者等多重角色，每个参与个体都成为软件生态中的组成部分与软件生态共同成长演化。软件开发活动也演变成一种通过互联网联接大规模群体，并通过群智激发和汇聚推动软件持续迭代演化的过程。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-1.png' width=80% alt='图1 软件开发中的群智激发与汇聚'>
|
||||
|
||||
<center>图1 软件开发中的群智激发与汇聚</center>
|
||||
</div>
|
||||
|
||||
  群智范式强调群智的激发与汇聚，其核心理念可以简单概括为：**宏观演化、微观求精**。在宏观（长期）尺度上接受世界的不确定性，以演化论为指导，自觉将软件核心开发者、外围软件涉众以及软件所处的社区生态视为有机整体，持续激发各类群体围绕软件项目进行自由创作；在微观（短期）尺度上，即在软件长期演化进程的具体阶段，坚持机械论原则，明确阶段性里程碑任务的需求规范（简称里程碑），以软件开发小规模核心团队为主力军，采用逐步求精的思路组织任务规划实施。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-2.png' width=80% alt='图2群智范式的核心理念：宏观演化、微观求精'>
|
||||
|
||||
<center>图2 群智范式的核心理念：宏观演化、微观求精</center>
|
||||
</div>
|
||||
|
||||
  在软件开发中涉及三个经典概念：需求、质量和效率，我们围绕软件开发的这三个经典概念来阐述群智范式：
|
||||
|
||||
  **（1）关于需求问题：** 群智范式强调，需求是一个持续获取和凝练的过程。通过持续发布原型版本吸引和发现潜在用户，通过引导用户使用体验原型版本激发用户以疑修（issue） 的形式持续产生、表达和丰富需求，通过不断满足用户当下需求激发新的需求，形成下一个里程碑，驱动软件系统的持续迭代演化。在群智范式中，需求通常以两种形式呈现：一种是以自然语言表达的疑修集合，或称为里程碑，是需求的非精确表达；另一种是以源代码呈现的实现里程碑的阶段性可部署执行版本，或称为原型版本，是现阶段需求的精确表达。
|
||||
|
||||
  **（2）关于质量问题：** 群智范式中的软件质量不再只是单纯度量软件源代码本身，而应该综合考虑软件源代码、围绕软件源代码形成的社区以及软件社区所在的生态环境。因此，群智范式中的质量问题应该包含传统意义上的软件代码质量、软件社区的规模与口碑，以及该软件社区在其生态环境中的地位和对生态环境发展的促进作用等。具体而言，群智范式中的软件质量可以从宏观（长期）和微观（短期）两个方面理解：在宏观上，软件质量主要体现在应对复杂生态演化过程中各类不确定性因素的能力；在微观上，软件质量主要体现在持续迭代版本满足里程碑任务规格的程度，这反映了软件对经过筛选的阶段确定性需求的满足程度。
|
||||
|
||||
  **（3）关于效率问题：** 群智范式中的开发效率同样需要考虑软件本身的开发效率、软件社区形成的效率，以及软件社区所在生态环境演进的效率。从群智激发和汇聚两个视角来看，激发效率是指吸引更多参与者进入社区并做出贡献的效率，汇聚效率是指吸纳广大参与者贡献的效率。在宏观上，软件开发效率主要体现在其软件社区与所在生态环境在应对不确定性因素而发生变异与演化所花费的时间与成本；在微观上，软件开发效率主要体现在对于确定的里程碑开发任务与阶段性可部署执行版本的迭代时间与成本。
|
||||
|
||||
## 2.2 群智范式的软件生命周期
|
||||
|
||||
  在软件工程领域通常采用软件生命周期刻画软件从产生直到废弃的过程，经典软件工程将软件生命周期分为需求定义、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，那么在群智范式下的软件生命周期如何认识？群智范式下的软件除了其自身外，还应考虑围绕软件形成的社区、软件社区所在的平台，以及软件社区所处的生态。我们从生态系统角度重新认识和定义软件的各个阶段及其演化周期，其整体过程如图所示。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-3.png' width=80% alt='图3 群智范式下的软件生命周期'>
|
||||
|
||||
<center>图3 群智范式下的软件生命周期</center>
|
||||
</div>
|
||||
|
||||
  群智软件生命周期总体可分为成长演化期和冻结休眠期。其中，成长演化期包括孕育态、长出态、长成态、长优态，冻结休眠期包括冻结态和激活态。这里定义的生命周期状态与传统软件开发阶段的本质区别在于：
|
||||
|
||||
  （1）群智软件项目不是静态的，即不是在工程化视角下通过设计、编码、测试、交付等阶段就算软件开发完成的，而是在生态观视角下随软件及其社区生态不断成长演化的；
|
||||
|
||||
  （2）群智软件项目在生态中不存在终点，即没有传统意义上的软件项目废弃或终结，而是在当前状态进行不下去的时刻转入冻结休眠期留存在数字空间中，未来随着技术与需求的发展保留被激活重新成长演化的可能。
|
||||
|
||||
  下面对群智软件生命周期的状态、特征及其转化过程进行详细阐述。
|
||||
|
||||
  **（1）孕育态：** 产生了一个软件项目的原始创作想法，且围绕这个想法形成了一个相对稳定的核心团队，制定了初步的项目目标与开发计划。在这一阶段，核心团队在开源社区开发平台上创建了协同开发项目，围绕初始创意在平台上进行原型设计与代码开发。
|
||||
|
||||
  **（2）长出态：** 项目的核心团队在开源平台上开源发布了第一个可执行的版本及其源代码。该版本是原始需求的完整表达，但可能并不成熟且存在较多的缺陷。核心团队将基于此版本吸引软件的使用者与潜在的外围贡献者形成社区雏形，并结合开源社区发展状况规划项目任务与里程碑，持续迭代完善。
|
||||
|
||||
  **（3）长成态：** 该项目形成比较稳定的外围群体社区，包括一定数量的开发者、使用者和关注者（如>100个开发者、>1000个使用者或关注者）且数量持续增长。该社区就软件的核心需求形成了比较一致的共识，项目开始吸纳外围开发者进入核心团队，社区各类群体创意被持续激发，不断挖掘应用场景、提出新的软件需求、发现代码缺陷，软件开发进入高速增长期。
|
||||
|
||||
  **（4）长优态：** 项目的核心团队与大规模外围参与者形成了良性循环的协同模式（如核心团队制定了项目贡献指南与规范，外围参与者围绕软件形成了固定的使用和研讨社群），软件代码更新在经历高速增长后逐渐趋于稳定，形成了规律性的代码提交频率与版本发布周期，该项目代码的质量或可信性在开源社区内得到若干关键应用支持（如基于该软件构建了>100个应用、或派生了>100个开发分支），软件项目出现上下游依赖协同演化的生态圈。
|
||||
|
||||
  需要注意的是，处于长成态和长优态的群智项目经历过持续的迭代演化，可能会随着技术的发展与环境的变化，衍生出与原始项目差异较大的变革性创意或支持相对独立场景下的特殊应用，进而基于项目的当前版本派生出新的孕育态群智项目。
|
||||
|
||||
  **（5）冻结态：** 在成长演化期的任何一个状态下，群智项目可能会遭遇技术瓶颈、资源不足、核心人员变更等各类障碍导致无法继续进行，原始核心团队放弃对项目的持续维护，因此软件主版本代码冻结，外围贡献无法被合入，用户新产生的需求和问题无法得到稳定的解决与答复。软件项目所有的历史数据（包括代码、说明文档、开发运维数据、应用案例教程等）仍然存在于开源平台，但暂时没有承担责任主体的稳定人员为该项目的用户提供承诺性的服务。
|
||||
|
||||
  **（6）激活态：** 有核心团体声明激活冻结态的项目，在激活时刻起持续维护项目代码，并对社区用户承诺提供稳定服务。该团队经过熟悉历史数据、更新代码与文档等初始操作，重新制定项目目标与发展规划，项目根据冻结时的项目状态以及前期准备情况转入相应的状态。
|
||||
|
||||
## 2.3 群智范式的软件开发方法
|
||||
|
||||
  群智软件的开发方法可以概括为 **“两个联接，一个转化”**，即联接核心团队与外围群体，联接自由创作与规范生产，实现原型作品与原型版本之间的转化。
|
||||
|
||||
  **（1）联接核心团队与外围群体：“核心团队”和“外围群体”代表了软件开发活动中“软件涉众”这一关键要素。** 从群智范式视角看，“核心团队”和“外围群体”代表了软件开发生态中两类典型软件参与群体。“核心团队”通常是软件项目的创始团队、管理团队和核心参与者，主要是初始创新作品的发起者，是里程碑和原型版本的发布者。随着软件的迭代演化，核心团队负责软件演化过程中的里程碑规划决策、核心功能开发、吸纳汇聚“外围群体”贡献的疑修或代码、发布新的原型版本；“外围群体”则是参与软件项目的其他大规模利益相关者群体或涉众，在软件迭代演化过程中贡献需求（以疑修的形式）和代码等，“外围群体”部分成员通过在项目中的长期参与和持续贡献，其参与深度和贡献价值会逐步提升，最终转化为“核心团队”成员。
|
||||
|
||||
  **（2）联接自由创作与规范生产：“自由创作”与“规范生产”代表了软件开发活动中“过程组织”这一关键要素。** 从群智范式视角看，软件开发是创作与生产相互交织快速迭代的过程。在需求不清晰、任务不明确时，核心团队通过发布原型版本吸引并激发“外围群体”的灵感，收获并评估外围群体的贡献，参与软件集体创意；在阶段性里程碑明确后，“核心团队”采用规范化的组织模式快速推进研发任务，基于集成部署和自动化测试等机制生成高质量的软件原型版本。群智范式通过内外交汇的协调机制“联接”这两类活动，充分发挥“外围群体”自下而上的创新活力和“核心团队”自上而下的组织能力，协同驱动软件项目的快速迭代演化。
|
||||
|
||||
  **（3）原型作品与原型版本之间的转化：“原型作品”与“原型版本”重点关注软件开发活动中的“软件制品”这一关键要素。** 从群智范式视角看，原型作品通常是灵感驱动下的创意捕获和表达，具有不可预期性和多样性；原型版本则通常是在阶段性里程碑驱动下，按照工程范式开发产生的软件原型版本，具有确定性和明确的评判标准。群智范式关注在联接“外围群体”创作活动与“核心团队”生产活动的基础上实现这两类软件制品的“转化”，即对原型作品进行筛选、改进并集成到软件原型版本中，并持续发布阶段性原型版本，吸引用户体验，从而激发产生新的原型作品，形成迭代演化。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-4.png' alt='图4 群智软件开发过程中的“两个联接、一个转化”'>
|
||||
|
||||
<center>图4 群智软件开发过程中的“两个联接、一个转化”</center>
|
||||
</div>
|
||||
|
||||
## 2.4 群智范式的软件开发模型
|
||||
|
||||
  群智范式下的软件项目及其社区生态是不断成长演化的，其软件开发是大规模软件涉众通过“两个联接、一个转化”的群智协作不断形成满足阶段性里程碑的原型版本，然后在大范围应用中获取新需求进而迭代演进形成持续循环。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-5.png' width=50% alt='图5 持续迭代演进的群智软件开发模型'>
|
||||
|
||||
<center>图5 持续迭代演进的群智软件开发模型</center>
|
||||
</div>
|
||||
|
||||
  在群智软件持续迭代演化过程中，每一轮迭代都涉及到核心团队与外围群体间的“持续需求获取”、“持续协同开发”、“持续在线演化”的基本循环。
|
||||
|
||||
**（1）持续需求获取**
|
||||
|
||||
  在此环节，外围群体的活动是使用新发布的软件服务版本，并将发现的软件问题、新的特征需求等诉求通过“疑修”的形式报告给软件的核心团队。核心团队的活动是首先对外围群体所提交的疑修的有效性进行确认，对于无效的疑修核心团队会将其关闭放弃，而对于有效的疑修核心团队会对其展开讨论。为统一规划项目的开发进度，核心团队会制定里程碑，并将相关的疑修加入到对应的里程碑中。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-6.png' width=80% alt='图6 核心团队与外围群体间的持续需求获取过程'>
|
||||
|
||||
<center>图6 核心团队与外围群体间的持续需求获取过程</center>
|
||||
</div>
|
||||
|
||||
  此环节是群智软件需求迭代的直接来源，所需要的支撑技术和工具包括疑修识别、疑修推荐、疑修感知、疑修关联等。
|
||||
+ 疑修识别：外围群体所提交的疑修的目的多种多样，常见的有报告软件缺陷、请求新特性、报告文档问题等。核心团队对不同类型的疑修通常赋有不同的处理优先级，平台通过自动识别疑修的类型，有利于提高核心团队对疑修的调度效率。
|
||||
+ 疑修推荐：对于大型软件项目，核心团队成员可能具有不同的知识背景，不同成员对于不同的软件模块可能具有不同的熟悉程度，平台将外围群体所提交的疑修自动推荐给合适的核心团队成员有利于提高疑修的审查质量。
|
||||
+ 疑修感知：外围群体贡献者往往以自组织的形式参与贡献，因此对于同一个软件问题，可能会有多个开发者进行重复报告。平台通过感知增强的技术，一方面能够避免产生无意识的重复疑修，另一方面能够及时检测已经提交的重复疑修，有利于提高群体协同效率。
|
||||
+ 疑修关联：不同的疑修之间可能会存在各种各样的关联，例如组合、依赖等，因此一个疑修的处理进度和处理结果，可能会影响与其存在关联关系的其它疑修的处理，平台自动检测疑修间的关联关系，能够为核心团队规划里程碑提供有效的决策支持。
|
||||
|
||||
**（2）持续协同开发**
|
||||
|
||||
  在此环节，外围群体首先通过复刻（fork）操作获得派生仓库，并在派生仓库中进行代码创作。在完成创作后，开发者首先在本地仓库执行代码提交操作，并通过合并请求（pull request）的形式将代码变更提交给核心团队进行审查。核心团队通过评论的方式对合并请求发表审查意见，最终在对审查意见的综合考虑下做出决策，并将符合项目标准的代码合并进项目的主版本库。除了评估、接受外围群体提出的合并请求，核心团队还会直接组织开展基于里程碑的开发工作。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-7.png' width=80% alt='图7 核心团队与外围群体间的持续协同开发过程'>
|
||||
|
||||
<center>图7 核心团队与外围群体间的持续协同开发过程</center>
|
||||
</div>
|
||||
|
||||
  此环节是软件代码持续迭代演进的直接来源，所需要的支撑技术包括疑修声明、兴趣发现、质量评估、进度跟踪等。
|
||||
+ 疑修声明：当外围群体开发者产生贡献意图时，平台通过公开声明的方式进行意图表达，同时描述开发计划，描述结果应该具备全局可见性和可追溯性。通过开发计划的提前报告和开放讨论，促进相关开发者之间的及时协同，提高合并请求的提交质量。
|
||||
+ 兴趣发现：当外围群体开发者在开发过程中，平台通过动态识别开发者潜在的贡献意图并自动关联具有共同开发兴趣的群体，进而在一定程度上规避由于无意识的离线并行工作等原因造成的重复劳动，提高开发者群体之间有意识的竞合协作几率。
|
||||
+ 质量评估：外围群体开发者提交的合并请求质量参差不齐，平台可以集成各种外部工具（如代码静态扫描、自动化测试等）对合并请求进行自动化质量检查，以提高合并请求的审查效率。另一方面，平台可通过对审查评论进行质量评估提升其有效性。
|
||||
+ 进度跟踪：平台可以通过个性化审查清单实时标识合并请求的审查进度，与此同时，对于已经产生的修订请求，平台可以通过突出标记修订请求的完成状态和进度，帮助开发者快速定位未完成的修订请求、管理者及时掌握修订进度，提高合并请求的修订效率。
|
||||
|
||||
**（3）持续在线演化**
|
||||
|
||||
  在此环节，核心团队的活动是将软件的最新代码进行持续部署，形成阶段性版本，并适时发布具有里程碑意义的原型版本。外围群体的活动则是自由下载特定版本的软件并运行使用，根据实际体验对软件进行反馈评价。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-8.png' width=80% alt='图8 核心团队与外围群体间的持续在线演化'>
|
||||
|
||||
<center>图8 核心团队与外围群体间的持续在线演化</center>
|
||||
</div>
|
||||
|
||||
  此环节将软件阶段性作品转化为某个原型版本并部署上线，进而向社区生态发起新一轮的需求获取，所需要的支撑技术包括持续交付、在线反馈等。
|
||||
+ 持续交付：平台可基于Web 2.0、虚拟化、微服务等技术灵活集成DevOps工具，例如持续集成与持续部署工具，打通软件开发态、测试态以及应用部署态，进而形成自动化、标准化的软件作品与产品转化流水线，缩短群智创新的迭代。
|
||||
+ 在线反馈：平台提供多样化的软件反馈途径，支持外围群体对软件的多维评价，并支持对全体评价的自动汇聚，核心团队可直观地获取社区对当前发布版本的评价概况，进而高效规划下一轮演化周期。
|
||||
|
||||
# 3 为什么提出群智范式
|
||||
|
||||
  计算技术的发展驱动软件形态的变化，也带来软件开发理念和方法的深刻变革。在人机物三元融合智能互联泛在计算时代，计算平台的泛在化驱使软件应用的泛在化，应用场景的多样化带来软件演化的不确定性，软件从相对独立的产品演变为多种元素相互依赖、持续演化的生态，“人在回路”的持续成长演化成为软件系统的一个基本特征。软件开发不再仅仅是一个生产性活动，而是一个典型的大规模群体通过群体智能激发和汇聚解决复杂任务的、涉及多种要素紧密关联的社会性活动，软件开发呼唤新的范式。
|
||||
|
||||
  从2007年起，我们立足工程范式、总结开源范式，追本溯源开始研究软件开发的新范式——群智范式，试图化解软件需求的确定性与不确定性之间的矛盾，在群智激发和汇聚之间寻找到平衡点，形成适应泛在计算时代的新型软件开发理念、方法和环境[5]。
|
||||
|
||||
## 3.1 工程范式：从个体创作到规模化生产
|
||||
|
||||
  软件开发的基本活动是程序设计。早期的程序开发就像民间作坊中手艺人的个人创作行为，程序（乃至软件）被视为一个天才在其私人作坊中创作的精妙作品。随着大型计算机系统技术成熟，社会对于软件的需求量以及软件自身的复杂程度开始增长，上规模的软件系统往往需求复杂、代码量大、涉及的利益相关方广泛，程序代码的复杂性以及开发过程的复杂性已远超出程序员个体大脑能直接理解与控制的程度。因此，作坊式的个体创作模式，使得软件开发效率与质量无法得到系统性的保障。此时的软件开发与维护成本极高，失败的软件项目屡见不鲜，“软件危机（software crisis）”开始爆发[6]。
|
||||
|
||||
  这一历史阶段的典型案例是IBM OS/360通用操作系统[7]的研发，该项目组织实施过程中遇到的失败经验，使软件从业者产生了历史性的觉醒。软件开发若不产生变革性的指导原则与方法论，任何看似偶然发生的事件如硬件故障、应急任务、人员变动等，累积叠加后就极有可能导致其开发过程的灾难性偏离和项目崩溃。处于工业化大生产浪潮中的计算机先驱们，向经典的工业生产管理学习，于1968年正式提出了软件工程的概念[8]，开启了工程范式的探索。软件开发从个体独立创作走向了大规模有组织的生产时代，造就了影响深远的软件产业。
|
||||
|
||||
  我们将软件工程遵循的软件开发理念和方法称为软件开发的工程范式。作为脱胎于计算机工业的软件开发范式，软件工程潜移默化地继承了机械的世界观或科学观，即世界是一部确定不变的、可被理解表述的、可被线性分解还原的“机器”。由此派生出软件生产的基本原则和方法：**自上而下、逐步求精**，其具体实施过程则总体上遵循“还原论”的思想[13]，即将软件开发过程中的各个任务自上而下精细化分解，简化为可管理、易开发的基本功能单元，完成基本单元开发后再通过自底向上组装获得目标软件，期望达到“整体等于部分之和”的效果。这里涉及软件开发的三个经典概念：
|
||||
|
||||
  **第一是需求**，这是工程范式的起点和依据。软件工程强调，需要通过一套标准过程与技术，指导开发人员系统化地进行用户需求识别和分析，获得规范一致的需求规格说明，由此开展“自上而下、逐步求精”的开发活动。
|
||||
|
||||
  **第二是质量**，保障质量是工程范式关注的核心目标。所谓软件质量是指软件代码满足需求规格的程度，其保障方法与手段包括形式化验证、自动化测试等方式。
|
||||
|
||||
  **第三是效率**，提高效率是工程范式关注的重要目标。开发效率是指开发出满足需求规格的软件所需要人力、时间、投资等资源成本，需要对软件生命周期进行阶段分解与过程控制，再通过相应的自动化手段提升投入与产出的效能比。
|
||||
|
||||
  软件开发的工程范式伴随着计算机产业的成熟取得了历史性成功[9]，形成了软件产业，但在互联网产业蓬勃发展环境中工程范式面临发展瓶颈。从软件自身特点规律看，软件开发的工程范式遇到两个瓶颈：第一，协同效率瓶颈，即软件开发过程管理面临群体协同规模的“人月神话”[10]；第二，自动化瓶颈，即软件自动化工具面临能行可表达的理论极限[11]。从软件发展的外部环境看，工程范式的发展出现两个不适应：第一，软件的生产效率与摩尔定律带来的计算基础设施硬件发展速度严重不适应；第二，工程范式的经典原则与迅猛到来的网络时代[12]严重不适应。特别是进入到互联网时代，软件的利益相关者从明确领域相关的小规模需求主导者转变为动态开放的大规模互联网用户群体，导致了软件开发不再是边界清晰、需求明确的生产活动，而是如何持续构造“人在回路”的复杂软件系统。
|
||||
|
||||
  这些新的变化动摇了工程范式的基本前提假设[11]，即用户需求可以被事先完整分析、获取和描述，软件系统具备可拆分的明确边界和结构，软件开发过程精确可控等。正如当今广泛存在于互联网上的各类应用软件，在开发之初可能根本无法明确最终的用户群体，自然也不可能冻结所谓用户需求规格并精细拆分。随着云计算技术发展与云服务的普及，软件产品越来越多以网络服务呈现，软件项目的商业成功逻辑不再是能否在确定的预算约束下按时交付用户满意的软件版本，或销售复制成本极低的软件版本拷贝，而是能否形成大规模网络用户生态圈。
|
||||
|
||||
## 3.2 开源范式：从规模化生产到大规模创作
|
||||
|
||||
  在软件开发的工程范式面临巨大发展瓶颈之际，发端于1980年代中期自由软件运动的开源软件经过20多年的蓬勃发展，取得了出人意料的成就[13]，开源软件创作的成功实践让开源范式进入学术界的视野。相对于封闭式、标准化、强组织的工程范式，开源范式更尊重每个开发者的个体创作意愿，通过营造开放性、多元化、自组织的创作环境[14]，充分激发大规模程序员群体的参与热情与创作灵感，通过群体智慧涌现，最终形成高水平的软件。这样的软件开发过程我们称之为软件创作活动，由此产生的软件制品称之为软件作品。优秀的开源作品通过互联网可以高效聚集数以万计的开发者参与贡献，其规模远远超过任何单一商业软件公司，形成了极高质量的软件社区。
|
||||
|
||||
  相较于软件开发的工程范式，业界并没有就开源范式形成共识。我们将发端于1980年代中期自由软件运动之后开源软件20年实践所遵循的软件开发理念和方法统称为开源范式。作为脱胎于互联网环境的软件开发范式，开源范式看似无序状态背后的逻辑是演化的世界观和科学观，即遵循自然演化两个基本原则：一是（可以传递给后代的）变异，二是竞争（什么样的变化可以在后代继续存在）。传统开源软件的发起往往源于少部分人的创作冲动，一开始并没有明确的目标用户，也未必有详细的设计和规划。发起者将软件源代码公开分享出来，任何感兴趣的人都有机会参与创作[15]，根据个性化需求自由地进行修改和完善，并自己决定是否向源项目提交贡献[16]。开源软件的核心维护者对社区大量自发提交的贡献进行选择，决定吸纳什么样的代码合并到原始分支中，故被采纳（即竞争）的社区贡献（即变异）则随着开源软件的版本迭代传承下去。
|
||||
|
||||
  开源范式这种基于创作兴趣和社区自组织的发展理念可以简单概括为：**自下而上、关联演化**。开源范式的软件创作方法是“程序代码开源、开发过程开放、大众自由参与”。开源范式支持在不确定的网络世界，通过众多的开发者带来丰富变异和竞争，自然演化出得到用户欢迎的软件制品。以Linux演化历程为例，每个Linux内核的自由“下载者”都可能修改内核，从而产生“变异”并“繁殖”出新的Linux版本，这个过程带来的多样性整体上大大提高了Linux种群基因延续的可能性。自2005年至2017年期间，Linux仅内核就发行了6个稳定版本（4.8 release至4.13 release），超过15,600多位开发者为其开源内核贡献过代码。这些开发者来自全球1400个不同的企业或组织。Linux通过开源范式带来的易变性和多样性，更能应对未来操作系统发展的不确定性，Linux基因被更多的衍生操作系统继承，从而家族“人丁兴旺、儿孙满堂”，当智能手机、云计算、物联网等新的需求涌现时，Linux的后代就具有更大竞争力。自21世纪以来，越来越多期盼寻找软件开发“银弹”的传统软件企业遵循开源范式进行革新。这种基于达尔文“演化论”科学观下的开源范式是软件工程历史上的又一次重要觉醒，适应了互联网时代软件作为服务的发展趋势。
|
||||
|
||||
  从软件开发的三个经典概念（即需求、质量、效率）出发观察开源范式，我们可以发现开源范式相对于工程范式是颠覆性的：
|
||||
|
||||
  **第一，关于需求问题**。开源范式不坚持“需求在先、开发在后”的原则，甚至不坚持在开发软件之前有明确的用户，开发者基于自己的构思进行软件创作。
|
||||
|
||||
  **第二，关于质量问题**。按照工程范式的原则，需求是质量的依据和前提，在开源范式中，软件质量则体现为软件开发社区的规模和口碑。
|
||||
|
||||
  **第三，关于效率问题**。在开源范式中，开源软件是在开发社区中持续演化的，因此就不存在工程范式中的最终交付时刻，开发效率可以理解为开源项目的迭代效率，例如缺陷的响应与修复速率、新版本发布的频率等。
|
||||
|
||||
  随着开源范式的发展，各类相对独立的开源软件开发社区逐步演变为多种元素交织依赖、持续成长动态演化的开源软件生态。置身在自然演化生态中，开源范式难逃“物竞天择、适者生存”的自然规律。虽然宏观上开源生态发展热火朝天，但任何一个开源项目是否能够成功是不可控的，开源出来的代码能否得到关注是未知的，甚至任何一个开放的开发任务什么时候能完成以及是否能完成都无法保证。据统计，截止至2019年，全球最大的开源托管平台GitHub中无任何关注用户的代码仓库占91.78%，超过100位开发者关注的项目仅占0.13%。真正产生应用价值的开源项目更是可遇不可求。
|
||||
|
||||
## 3.3 群智范式的提出与三类范式的对比
|
||||
|
||||
  如果将开源范式和工程范式做一个比较，工程范式强调面向确定性场景下的问题，软件需求表达越清晰（即需求熵越低），开发团队目标就越明确、资源配置越聚焦，进而可以通过强组织的方式进行过程管理。开发过程聚焦软件产品，强调团队中每个开发人员各司其职（可以称为群智熵低），不需要太多的发散思维。因此，这一范式可以在相对稳定的环境（即两类熵都较低）进行稳定的群智汇聚，但几乎放弃了对不确定性问题的关注。
|
||||
|
||||
  开源范式则面向开放式场景问题，通过自组织的社区群体，鼓励开展基于兴趣驱动的软件自由创作，以多样性促进创新涌现。这种对自由创作的极端追求（即需求熵高）加剧了群体协同过程的不确定性（即群智熵高），能够在开放环境下（即两类熵都较高）激发出丰富多样的创新需求，但软件作品收敛为软件产品的成本极高，几乎无法对结果做出可预期性承诺。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-9.png' width=60% alt='图9 从熵的角度理解和认识工程范式、开源范式与群智范式'>
|
||||
|
||||
<center>图9 从熵的角度理解和认识工程范式、开源范式与群智范式</center>
|
||||
</div>
|
||||
|
||||
  那么，如何平衡软件需求的确定性和不确定性之间的矛盾，进而更有效地、可预期地组织软件开发群体智能？特别是面对未来“人机物”三元融合的万物智联泛在计算时代[1]和数字经济新型应用形态[17]，软件的范畴将从信息空间拓展至物理空间与人类空间三元融合的新场景，“万物均需互联、一切皆可编程”的新计算特征，将激发用户对软件的功能、服务与应用模式产生更灵活多样且个性化的期待，因此这类复杂软件的需求不确定性可能更为显著。群智范式正是在这样一个新的时代孕育出的软件开发新范式，其关注的核心问题是：面对不确定的世界，如何高效激发和汇聚群体智能，以实现软件的持续演化，主动适应变化的世界。工程范式、开源范式和群智范式在基本理念的对比如下表所示。
|
||||
|
||||
<div align='center'>
|
||||
<center>表1 三类软件范式基本理念的对比</center>
|
||||
|
||||
<img src='./imgs/table-1.png' alt='表1 三类软件范式基本理念的对比'>
|
||||
</div>
|
||||
|
||||
# 4 群智范式怎么做
|
||||
|
||||
  群智范式是一个软件开发的新范式、新理念、新方法和新模型，试图为人机物融合泛在计算时代软件开发提供新的认知和方法指导。但群智范式不止于此，还进一步沉淀形成了支持群智范式理念、方法和模型物化落地的面向群智范式的软件开发平台，并且其本身也采用群智范式的理念和方法来推进平台项目的建设，力图联合多方力量合力打造支持群智软件开发的新型基础设施。
|
||||
|
||||
## 4.1 群智范式的软件开发平台
|
||||
|
||||
  自2006年以来，我们立足工程范式与开源范式，持续深入的研究群智范式，在国家持续支持下形成了“Trusite确实”技术体系，并建设运营了“Trusite确实”系列工具平台，开展面向群智范式的软件开发平台探索与实践。
|
||||
|
||||
  面向群智范式的软件开发平台建设总体可分为以下三个阶段：
|
||||
|
||||
  （1）Trustie 1.0阶段（2006年-2014年）：以开源范式视角革新企业级工程范式，基于“大众化协同开发、开放式资源共享、持续性可信评估”为核心的互联网大规模群体协同机理[18-20]，提出软件生产线构造方法，研发构建了可信的国家软件资源共享与协同生产环境Trustie 1.0，重点解决企业内、企业间的大规模软件协同开发、可信评估、运行监控和持续演化等问题，初步建立了群智范式“两个联接、一个转化”迭代飞轮的基础架构。相关技术和平台在东软集团、神州数码、航天科技集团、成飞等企业以及各地软件园区得到应用。
|
||||
|
||||
  （2）Trustie 2.0阶段（2014年-2020年）：重点聚焦小规模核心团队与互联网大规模开发者群体（即群智范式两类群体）的高效联接与协作[21-26]，研发了基于开源大数据的智能化工具，构建升级了开放创新服务平台Trustie 2.0。相关方法、技术和平台在启智开源社区、红山开源社区，以及头歌实践教学社区得到应用，为新一代人工智能、云计算与大数据等行业开源孵化和开源人才培养提供了有力支撑。
|
||||
|
||||
  （3）Trustie 3.0阶段（2020年至今）：以“群智”为核心，系统性支撑软件开发群智范式，研发大规模群体的激励、协作与调控工具链[27,28]，建立面向“核心团队”与“外围群体”协同创新的群智激发汇聚关键机制与开发平台[29-31]，加速建设“两个联接、一个转化”创新飞轮，实现面向大规模软件涉众的稳态群智激发与持续汇聚。以Trustie开源内核为基础，构建并发布了中国计算机学会开源创新服务平台“确实开源”GitLink，探索共建共享的新型开放创新平台以及学术共同体驱动的开源创新新途径。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-10.png' alt='图10 GitLink开源创新服务平台'>
|
||||
|
||||
<center>图10 GitLink开源创新服务平台</center>
|
||||
</div>
|
||||
|
||||
## 4.2 群智范式的平台项目
|
||||
|
||||
  2023年6月11日，中国计算机学会与开放原子开源基金会、开源中国、华为、腾讯、阿里云、CSDN等学术界、产业界及开源组织多家单位联合发起共建一个本身开源的开源基础设施项目，并将该项目命名为“群智范式”（后文统一称为“群智范式平台项目”），希望以群智开源的方式，汇聚群智力量，共同打造我国新型开源基础设施基座，避免重复投入平台。
|
||||
|
||||
  **（1）总体建设思路**
|
||||
|
||||
  群智范式平台项目旨在融合工程范式与开源范式，将群智范式的核心理念、开发方法和开发模型等物化为基础平台的机制和能力，并联合政府、企业和社会等多方力量，充分发挥各方优势，广泛联接，深度融合，形成合力，共同建设和提升我国群智开源基础设施底座能力。总体建设思路如下：
|
||||
|
||||
+ 建设开放可扩展的高性能共性能力基础内核
|
||||
|
||||
  群智软件开发离不开一系列共性的基础能力，包括代码版本管理、代码保存管理、疑修管理、用户管理等。这些能力是支持群智软件开发的基础，也是当前国内开源平台和企业内部平台基本都具备的基础能力。我们联合各方力量建设一个开放、可扩展的基础内核系统架构，并在此基础上整合各参与方最具优势的基础功能和服务，形成一个高性能共性能力基础内核。
|
||||
|
||||
+ 围绕共性能力基础内核拓展形成群智范式平台项目群
|
||||
|
||||
  在共性能力基础内核基础上，面向群智范式开发方法和模型，研发集成相应的支撑机制和拓展服务，包括底层互联互通服务、群智激励机制和服务、两个联接一个转化的机制和服务、持续需求获取-持续协同开发-持续在线演化的支撑机制和服务等。这些机制和服务可以由科研机构成果开源、企业内部能力开放、开源社区志愿者开发等方式来贡献，作为群智范式平台项目的组成部分开源发布、开放共建，形成群智范式平台项目群。
|
||||
|
||||
+ 群智范式平台项目群支持多领域服务平台的建设和运营
|
||||
|
||||
  群智范式平台项目群向全社会开放、共建、共享，支持不同领域的个性化群智服务平台的建设和运营，有平台建设和运营需求的均可基于该项目群进行定制开发和部署。同时，在底层互联互通能力的支持下，各领域服务平台可以形成联通互动，进而形成充满活力的群智开源生态系统。
|
||||
|
||||
  **（2）能力规划**
|
||||
|
||||
  群智范式平台项目的核心目标是将群智范式的核心理念、开发方法等物化为平台通用能力，构建出适应群智软件开发需要的开源基础设施内核，支撑国内群智开源生态建设。具体的，群智范式平台项目将重点围绕基础服务、生产关系重构、组织模式重构和生产力提升四个方面的支撑能力建设推进。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-11.png' alt='图11 群智范式平台项目发展规划' align='center'>
|
||||
|
||||
<center>图11 群智范式平台项目发展规划</center>
|
||||
</div>
|
||||
|
||||
  1）基础服务支撑能力
|
||||
|
||||
  基础服务支撑能力主要包括用户管理、代码管理、项目管理和平台管理的基础能力建设。该能力目前已经具备，后续将进一步推动相关性能提升。
|
||||
|
||||
  2）生产关系重构支撑能力
|
||||
|
||||
  吸引和激发大规模群体持续参与是群智软件从长出态向长优态演进的关键，外围群体与核心团队之间的生产关系对激发大规模外围群体参与、吸引核心团队持续贡献至关重要。
|
||||
|
||||
  在开源范式下，主要是一种外围群体自由参与贡献并自愿让渡知识产权给核心团队的关系，外围群体的参与动机主要包括内在动机（例如：理想主义、兴趣爱好）、内化的外在动机（例如：社区声誉、个人对软件的使用）以及外在动机（例如：职业需要和付费贡献），核心团队则因为爱好和责任等因素而持续贡献。但是，由于社区对新人不友好、精力有限、缺少资金支持、缺乏有效的协商机制等原因，导致外围群体参与意愿不强、核心团队容易流失等。
|
||||
|
||||
  在群智范式下，我们借鉴市场经济中股权激励思想，设计基于知识产权共享的群智持续激励机制，实现对群智范式下外围群体与核心团队间的生产关系重构。其核心思想是：将群智项目视为一个股权公司，群智项目的所有贡献者共享知识产权及相对应的项目股权份额，在项目获得物质收益时将实行股权激励。项目创始团队在创建项目时设定一定规模的股份，创始团队拥有一部分原始股权，剩余股份作为未来开源社群贡献的股权激励。在项目后续发展过程中，根据开源社群的贡献给予相应的股权，贡献越多所获得股权越多。当未来项目获得投资或者其他物质收益后，根据项目贡献者的股权占比给予相应的物质回报。在具体实施过程中，将利用区块链技术来实现群智贡献的存证、知识产权的确权以及股权共享的激励。
|
||||
|
||||
  3）组织模式重构的支撑能力
|
||||
|
||||
  群智范式下的软件开发模型可以概括为“持续需求获取、持续协同开发、持续在线演化”，这种开发模型的实现需要“两个联接、一个转化”开发方法的支持，即外围群体与核心团队的联接、软件创作与规范生产的联接、软件作品与原型版本的转化，这需要研发相应的支撑工具和服务，从而实现对组织模式的重构。
|
||||
+ 外围群体与核心团队的联接工具/服务：如跨域协作感知工具、合作者推荐工具、实时代码评审功能等。
|
||||
+ 软件创作与规范生产的联接工具/服务：贡献协议在线签署工具、疑修关联工具、任务规划与跟踪工具、质量评估工具等。
|
||||
+ 软件作品与原型版本的转化工具/服务：持续交付工具、在线反馈工具等。
|
||||
|
||||
  4）生产力提升的支撑能力
|
||||
|
||||
  该项能力主要为群智软件开发提供智能化辅助工具和服务，从而提升群智软件开发的生产力，主要包括AI驱动的智能化软件开发工具/服务、云原生开发运维一体化工具/服务以及群智创新生态持续运营工具/服务。
|
||||
+ AI驱动的智能化软件开发工具/服务：运用大模型等技术为个体开发者提供辅助开发服务，如代码/摘要自动生成与推荐、快速原型构建、智能开发机器人应用市场等。
|
||||
+ 云原生开发运维一体化工具/服务：主要为群智软件的快速迭代演化提供支撑，包括持续集成持续部署、持续运行监控等。
|
||||
+ 群智创新生态持续运营工具/服务：主要为群智软件生态构建提供支撑，包括生态健康度量与监测、群智软件供应链风险分析、许可证合规检测、跨社区联接同步等。
|
||||
|
||||
  **（3）治理规划**
|
||||
|
||||
  群智范式平台项目本身是一个群智软件，希望联合国内包括学术界、产业界、开源组织等多方力量，以开放共建模式推进，共同提升群智开源基础设施底座能力，并支撑不同领域、不同主体构建群智协作平台服务版本，建立产学研深度融合的群智生态。群智范式平台项目的整体治理拟成立项目委员会、技术委员会、品牌建设委员会、生态运营委员会等，推动项目有效建设和治理。
|
||||
|
||||
<div align='center'>
|
||||
<img src='./imgs/image-12.png' width=80% alt='图12 群智范式平台项目治理架构'>
|
||||
|
||||
<center>图12 群智范式平台项目治理架构</center>
|
||||
</div>
|
||||
|
||||
  1）项目委员会
|
||||
|
||||
  项目委员会（以下简称“委员会”）是群智范式平台项目的最高决策机构，主要职责包括但不限于：制定或修改项目群开源治理制度、决定重大业务活动计划、制度或调整项目群重大方向等。委员会由项目成员单位代表及委员会委员共同组成。项目委员会设常务委员会，代表项目委员会行使委员会职责，并定期向委员会汇报决策项。委员会下设技术委员会、品牌建设委员会、生态运营委员会等，负责具体工作的推进实施。
|
||||
|
||||
  2）技术委员会
|
||||
|
||||
  技术委员会是本项目的技术领导机构，技术委员会设主席一名，委员若干名。技术委员会负责群智范式平台项目内新项目的准入、孵化、毕业的技术决策；负责群智范式平台项目内各基础设施的技术整合，为群智范式社区提供技术支持等。技术委员会下设多个SIG或子项目SIG，在技术委员会的指导下负责项目群特定子项目的架构设计、群智开发及维护等。SIG组包括Maintainer、Committer及贡献者等。
|
||||
|
||||
  3）品牌建设委员会
|
||||
|
||||
  品牌建设委员会是群智范式项目品牌营销的领导机构，主要负责推广群智范式平台项目，打造群智范式平台项目品牌影响力，策划相关的品牌营销活动及其他对群智范式平台项目有关的品牌工作等。
|
||||
|
||||
  4）生态运营委员会
|
||||
|
||||
  运营委员会负责推动项目生态运营工作的落实和发展，包括拓展吸引更多开发者参与，协调并建立与其它社区、开源组织、企事业单位的合作，协调项目各组织机构开展相关工作，负责项目内部日常运营，筹备和召开吸纳新成员加入项目工作委员会等。
|
||||
|
||||
# 5 结束语
|
||||
|
||||
  人类科技发展的历程从一定意义上讲就是在不确定的世界中获得更多确定性的过程。在这个过程中，群体智能是获得确定性的锐利武器，是人类文明的标志。软件开发经历了工程范式和开源范式两次范式变革，这两次范式变革反映了人类对世界的两种科学认知，即机械论与演化论。在“人-机-物”日益融合的三元世界中，计算平台的泛在化必然驱使软件应用的泛在化，软件定义一切预示着在不久的将来软件必将更加全面渗透人类社会方方面面，孕育新的软件开发范式的变革——群智范式。
|
||||
|
||||
  本白皮书讨论的三种软件开发范式的共同点是群体智能。不同点是由于需求的确定性程度所导致的如何认识群体智能（即理念层面）和如何发挥群体智能（即方法层面）的不同，以及由此导致软件开发质量和效率的认知差异。工程范式与开源范式的本质差异不在是否开源上，而在于需求是否确定以及由此导致的群体智能如何发挥上。工程范式关注的问题是：在需求（规范表达）确定的前提下，如何高效汇聚开发团队的智力资源以高质量达成目标。也就是说，工程范式专注的焦点是“汇聚”群体智能，理念和方法是“工程化”，所以被称为“工程范式”。开源范式关注的问题是：在需求不确定的情况下，如何高效激发群体智能，以获得有意义或有价值的软件需求。也就是说，开源范式专注的焦点是“激发”群体智能，理念和方法是“开源”，期待通过开源的“祭品效应”吸引“信众”，所以被称为“开源范式”。群智范式关注的问题是：面对不确定的世界，如何高效激发和汇聚群体智能，以实现软件的持续演化，主动适应不断变化的世界。
|
||||
|
||||
  群智范式为我们应对未来不确定性世界的软件开发提供了理论和方法指导。我们在群智范式理论和方法的基础上，进一步发起和推动该理论和方法的物化平台：群智范式平台项目，希望国内学术界和产业界力量联合起来，共同推动这样一种新的范式落地实践。
|
||||
|
||||
  我们将群智范式下的软件项目生命周期分为孕育态、长出态、长成态和长优态等，群智范式白皮书和群智范式平台项目可以视为经历了孕育态，尚处于长出态，能否长成、长优，还需要更多志同道合者一起来研究探索与建设实践！
|
||||
|
||||
# 参考文献
|
||||
|
||||
[1]. Mei H, Cao D G, Xie T. Ubiquitous operating system: toward the blue ocean of human-cyber-physical ternary ubiquitous computing. Bull Chinese Acad Sci, 2022, 37: 30–37 [梅宏, 曹东刚, 谢涛. 泛在操作系统: 面向人机物融合泛在计算的新蓝海. 中国科学院院刊, 2022, 37: 30–37]
|
||||
|
||||
[2]. 国家自然科学基金委员会, 中国科学院. 软件科学与工程. 北京: 科学出版社, 2021
|
||||
|
||||
[3]. 王怀民, 软件开发范式的变革, 中国计算机学会通讯, 第18卷, 第2期, 2022年2月
|
||||
|
||||
[4]. 王怀民, 余跃, 王涛, 等. 群智范式: 软件开发范式的新变革. 中国科学: 信息科学, 2023, 53: 1490–1502
|
||||
|
||||
[5]. Wang H M, Yin G, Xie B, et al. Research on network-based large-scale collaborative development and evolution of trustworthy software. Sci Sin Inform, 2014, 44: 1–19 [王怀民, 尹刚, 谢冰, 等. 基于网络的可信软件大规模协同开发与演化. 中国科学: 信息科学, 2014, 44: 1–19]
|
||||
|
||||
[6]. Fitzgerald B. Software crisis 2.0. Computer, 2012, 45: 89–91
|
||||
|
||||
[7]. Amdahl G M, Blaauw G A, Brooks F P. Architecture of the IBM System/360. IBM J Res Dev, 1964, 8: 87–101
|
||||
|
||||
[8]. Pressman R, Maxim B. Software Engineering: A Practitioner’s Approach. London: Palgrave Macmillan, 2005
|
||||
|
||||
[9]. Boehm B. A view of 20th and 21st century software engineering. In: Proceedings of the 28th International Conference On Software Engineering, 2006. 12–29
|
||||
|
||||
[10]. Brooks Jr F. The Mythical Man-month: Essays on Software Engineering. New York: Pearson Education, 1995
|
||||
|
||||
[11]. Wang H M, Wu W J, Mao X J, et al. Growing construction and adaptive evolution of complex software system. Sci Sin Inform, 2014, 44: 743–761 [王怀民, 吴文峻, 毛新军, 等. 复杂软件系统的成长性构造与适应性演化. 中国科学:信息科学, 2014, 44: 743–761]
|
||||
|
||||
[12]. Mei H, Huang G, Xie T. Internetware: a software paradigm for internet computing. Computer, 2012, 45: 26–31
|
||||
|
||||
[13]. Bonaccorsi A, Rossi C. Why open source software can succeed. Res Policy, 2003, 32: 1243–1258
|
||||
|
||||
[14]. Von, Hippel, Eric. Innovation by User Communities: Learning from open-source software. MIT Sloan Management Rev, 2001, 42: 4
|
||||
|
||||
[15]. Statista. Number of employees at the Microsoft Corporation from 2005 to 2022. 2022. https://www.statista.com/statistics/273475/number-of-employees-at-the-microsoft-corporation-since-2005
|
||||
|
||||
[16]. Li W, Wu W, Wang H, et al. Crowd intelligence in AI 2.0 era. Front Inf Technol Electron Eng, 2017, 18: 15–43
|
||||
|
||||
[17]. 中国信息通信研究院. 中国数字经济发展白皮书. 中国信息通信研究院, 2021
|
||||
|
||||
[18]. Wang H W. Harnessing the crowd wisdom for software trustworthiness. ACM SIGSOFT Softw Eng Not, 2018, 43: 1–6
|
||||
|
||||
[19]. Wang T, Yin G, Yu Y, et al. Crowd-intelligence-based software development method and practices. Sci Sin Inform,2020, 50: 318–334 [王涛, 尹刚, 余跃, 等. 基于群智的软件开发群体化方法与实践. 中国科学: 信息科学, 2020, 50:318–334]
|
||||
|
||||
[20]. Yin G, Wang T, Wang H, et al. OSSEAN: mining crowd wisdom in open source communities. In: Proceedings of IEEE Symposium On Service-Oriented System Engineering, 2015. 367–371
|
||||
|
||||
[21]. Li Z, Yu Y, Zhou M, et al. Redundancy, context, and preference: an empirical study of duplicate pull requests in OSS projects. IEEE Trans Softw Eng, 2022, 48: 1309–1335
|
||||
|
||||
[22]. Li Z, Yu Y, Wang T, et al. Opportunities and challenges in repeated revisions to pull-requests: an empirical study. In: Proceedings of the ACM On Human-Computer Interaction, 2022
|
||||
|
||||
[23]. Li Z, Yu Y, Wang T, et al. Are you still working on this? An empirical study on pull request abandonment. IEEE Trans Softw Eng, 2022, 48: 2173–2188
|
||||
|
||||
[24]. Wang H M, Wang T, Yin G, et al. Linking issue tracker with Q&A sites for knowledge sharing across communities. IEEE Trans Serv Comput, 2018, 11: 782–795
|
||||
|
||||
[25]. Zhang X, Wang T, Yu Y, et al. Who, what, why and how? Towards the monetary incentive in crowd collaboration: a case study of Github’s sponsor mechanism. In: Proceedings of CHI Conference On Human Factors In Computing Systems, 2022
|
||||
|
||||
[26]. Zhang X, Yu Y, Gousios G, et al. Pull request decisions explained: an empirical overview. IEEE Trans Softw Eng, 2023, 49: 849–871
|
||||
|
||||
[27]. Yu Y, Wang H, Yin G, et al. Reviewer recommendation for pull-requests in GitHub: what can we learn from code review and bug assignment? Inf Softw Tech, 2016, 74: 204–218
|
||||
|
||||
[28]. Li Z, Yu Y, Wang T, et al. To follow or not to follow: understanding issue/pull-request templates on GitHub. IEEE Trans Softw Eng, 2023, 49: 2530–2544
|
||||
|
||||
[29]. Vasilescu B, Yu Y, Wang H, et al. Quality and productivity outcomes relating to continuous integration in GitHub.In: Proceedings of the 10th Joint Meeting on Foundations of Software Engineering, 2015. 805–816
|
||||
|
||||
[30]. Wu Y, Zhang Y, Xu K, et al. Understanding and predicting docker build duration: an empirical study of containerized workflow of OSS projects. In: Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, 2022. 1–13
|
||||
|
||||
[31]. Zhang Y, Vasilescu B, Wang H, et al. One size does not fit all: an empirical study of containerized continuous deployment workflows. In: Proceedings of the 26th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE ’18), 2018. 295–306
|
||||
Binary file not shown.
Loading…
Reference in New Issue