@toc

开源社区治理

1范围

本标准提出了开源社区组织结构、板块划分、开源软件分类、新提项目/功能审核、开源软件质量评估、开源软件漏洞扫描和安全管理等方面的要求。

本标准适用于指导开源社区的治理及所有开源技术参与者利用开源技术进行项目开发、部署、运营和推广

2术语和定义

开源社区 open source community

开源社区，也称为开放源代码社区，由拥有共同兴趣爱好的人所组成，根据相应的开源软件许可证协议公布软件源代码的网络平台，同时也为网络成员提供一个自由学习交流的空间。

3缩略语

下列缩略语适用于本文件。

API 应用编程接口（Application Programming Interface）

4治理模型

开源社区治理模型包括原则、成员、项目、许可、贡献、商业化几个模块，如图1所示：

图1 开源社区治理模块

5社区原则

开源社区所有项目遵循以下原则：

a) 开源

开源社区不生产“开放核心”软件；开源社区致力于创建可用且可扩展的开源软件；开源社区没有“企业版”。

b) 开放式设计

致力于开放式设计流程。 每个开发周期每个开发项目，社区都会举行面对面的活动来收集需求并为即将发布的版本编写规范。对所有人都包括用户，开发人员和上游项目开放。社区收集需求，确定优先级并充实技术设计，以指导下一个开发周期的开发。

c) 开放式开发

整个开发过程中维护一个公开可用的源代码存储库。社区进行公共代码审查。社区将制定有公共路线图。

d) 开放社区

社区的核心目标之一是维护一个健康，充满活力的开发人员和用户社区。大多数决策都是使用惰性共识模型进行的。所有流程都记录在案，公开透明。社区的技术治理由社区本身提供，贡献者选举团队负责人和技术委员会成员。

e) 商业友好

社区是一个地理分布的社区，来自不同文化的成员，其第一语言为中文。这两个特征都会使沟通更加容易，社区鼓励每个人通过认真和建设性的写作以及寻找对不明确信息的积极解释，有意识地努力克服这一挑战。沟通明显提高了我们协作以更有效地解决技术挑战的能力。

f) 自愿

参与中国开源社区是其参与者首先做出的选择。如果不同意我们遵循的原则或流程，可以寻求一个更符合您的理想或观点的不同社区。但是，如果致力于开源的使命和我们的开放理念，我们鼓励您根据我们的治理规则为开源做出贡献并参与改进开源流程并从社区内记录我们的原则。

g) 公平

开源社区致力于支持在开源构建产品的企业，并帮助他们取得成功。但是，开源产品不应该授权一个企业而不是另一个企业，否则我们的社区就不会真正成为每个人都可以协作的地方。虽然组成企业的需求是必不可少的，但它们必须相互平衡，以免开源社区决定无意中被非选举产生的人们闭门造车。

6成员管理

6.1董事会

董事会负责根据基础章程管理和监督社区的业务和事务，这包括管理基金会的资产（资金，知识产权，商标和支持设备）以及为项目分配资源。董事会共有X个席位，其中包括X个白金会员单位，X个黄金会员单位，X个独立董事。

6.2项目管理委员会

项目管理委员会由董事会决议设立，负责一个或多个社区的积极管理，这也由董事会决议确定。每个PMC由至少一名ASF官员组成，他们将被指定为主席，并可能包括一个或多个ASF的其他成员。PMC 是作为其项目走向的唯一的实体，再没有其他团体可以参与。特别强调的是，PMC必须对其项目软件产品的正式发布进行投票。

由具备一定社区影响力的贡献者组成。项目管理委员会作为一个整体，独立监管一个或多个项目。

6.3会员管理

为了促进和规范化开源社区的发展，同时保护参与者的利益，社区管理实行会员制，会员根据其等级享有特定的权利和义务。根据参与者的组织形式，分为企业会员和个人会员。企业会员包含有三类正式会员：（1）白金，（2）黄金，和（3）白银，以及一类无表决权的参与者，称为准会员。

6.3.1企业会员

6.3.1.1白金会员

白金会员需要缴纳X万元的会员费，并且至少负责N个开源项目，并具有一定的贡献度。连续两年贡献度不够将降为黄金会员。

6.3.1.2黄金会员

黄金会员需要缴纳X万元的会员费，并且至少负责N个开源项目，并具有一定的贡献度。连续两年贡献度不够将降为白银成员。

6.3.1.3白银会员

白银会员需要缴纳X万元的会员费，并且至少负责N个开源项目，并具有一定的贡献度。连续两年贡献度不够将取消其会员资格。

6.3.1.4准会员

准会员应是非营利性的政府实体（例如：大学、研究所），参与或支持基于开源技术的生产、制造、使用、销售或标准化。初级会员没有投票权，并且应取得董事会的资格批准。如果实体辞职或不符合相应标准，则取消其准会员的资格。

6.3.2个人会员

个人会员需缴纳X元的会员费，便可以折扣价参加X。我们提倡社区参与者的多样性和包容性。个人会员所缴纳的会费，会被用于X（例如：鼓励女性在技术职业中脱颖而出，帮助学生参与开源项目等）。

6.3.3会员资格评定

6.3.3.1会员资格申请

6.3.3.2会员升级激励机制

6.3.3.3会员资格终止

6.4会议

a)常规会议

b)特殊会议

c)会议通知

d)投票权

6.5用户管理

使用社区产品的使用者都属于用户范畴，用户可以通过社区下载使用带有开源协议生命的系统或软件，并向开源项目反馈建议和意见。

7项目管理

7.1项目分类

7.1.1面向编程语言的软件类别规划

开源软件分类可参考附录A的编程语言。

7.1.2面向应用领域的软件类别规划

软件分类可参考附录B的行业应用和技术领域。

7.2流程管理

7.2.1新提项目与评审

社区可以通过他人贡献或发掘优秀项目的方式提出对新项目的孵化提议，在项目达到孵化评审标准的前提下召开评审投票，对超过50%投票的开源项目，成立或指派项目管理委员会对项目进行指导和监督。具体孵化评审标准如下：
由现有核心成员提名，根据对社区的推进和演化来进行选举而定。相比开源项目贡献者，社区核心成员更关注和聚焦于社区本身建设，这主要体现在项目相关和垮多个项目的活动和事件中。从权利和职能上看，核心成员可以参与理事会选举，成为理事会选举候选人，推荐提名新的核心会员，提出新的孵化项目等。

a) 超过5个或10%以上社区核心成员提出孵化提议；

b) 使用社区指定的安全可控的代码托管平台如如码云(gitee.com)；

c) 采用 OSI 认可 License 或社区指定认可的 License；

d) 季度/年度更新频率稳定，有良好的版本规划计划；

e) 社区积极响应用户反馈；

f) 项目满足开源软件质量评估要求；

g) 项目官网显著位置标注项目在指定代码托管平台的链接地址和社区收录的项目链接；

h) 协作贡献者人数至少 10 人；

i) 提供完善的开发和使用文档；

j) 社区用户评价(Star) >= 100。

7.2.2项目功能新提与评审

对于项目的功能和演进，所有参与者均可以个人身份对项目提出意见和建议，其演进方向和功能评审由社区意见决策，开源社区理事会不能干预社区内的具体事宜。
项目管理委员会作为监督和指导治理的角色，提供在法律等方面的指导。同时项目通常又是自我进行管理的，即由志愿者来驱动去做一些工作。当需要协调的时候，最终的决定采用的是共识法：一些没有反对票的正面投票就足够了。具体投票的形式有下面三种：

a) +1 —— 表示同意的投票；

b) 0 —— 表示弃权，没有意见；

c) -1 —— 表示反对。
当投反对票的时候，要明确提出替代方案，以及投反对票的详细解释。社区然后试图就解决问题的备选提案达成共识。在绝大多数情况下，此方式可以解决导致投票反对的担忧。

7.2.3版本管理制度

应保证版本的兼容性和一致性。

7.3文档管理

文档概述了我们流程中需要改进的四个关键领域。这些领域包括记录用例，设定期望，提高内容可见性以及为文档做出贡献。

7.4质量管理

a) 功能性

——软件可以正常编译和运行；

——无明显代码缺陷（如空指针）；

——需求覆盖度达到100%，1个测试需求用例至少拥有2条用例（1个正常用例，1个异常用例）；

——测试用例累计执行通过率：已经通过的用例数/已经执行的用例数，该项指标可以判断软件的质量是否符合质量目标；

——测试用例首次执行通过率：第一次执行通过的用例数/已经执行的用例数，该项指标可以判断提测的软件代码质量的好坏程度，通过率越高，我们认为代码质量越高；

——Bug修复率达到97%；

——历史Realease间Bug趋势呈稳定收敛趋势。

b) 可靠性

——测试用例执行情况大概分为测试用例执行率，测试用例累计执行通过率，测试用例首次执行通过率；

——测试用例执行率：已经执行的用例数/用例总数，该项指标可以判断测试的进度。

c) 易用性

——软件的易学性、易理解性和易操作性。

d) 维护性

——应支持后续维护性

e) 可移植性

——应支持多样性异构环境的移植性

7.5开源软件安全漏洞和缺陷管理

软件不是完美无缺的，正常情况下，出现惹人厌烦的Bug不可能成为软件工程师们的期待。缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。优质的开源项目，在安全漏洞和缺陷管理上，应该满足以下的特征：

a) 使用成熟的项目管理工具进行缺陷管理；

b) 使用成熟的代码扫描工具（如Sonar）进行静态缺陷和代码扫描；

c) 具备明确的安全缺陷种类

——输入验证与表示（Input Validation and Representation）；

——API误用（API Abuse)；

——安全特性（Security Features）；

——时间和状态（Time and State）；

——错误和异常处理缺陷（Errors）；

——代码质量问题（Code Quality）；

——封装和隐藏缺陷（Encapsulation）；

——代码运行环境的缺陷（Environment）。

d)对社区反馈的缺陷和漏洞及时响应，提出反馈和具体解决方案。

8贡献管理

贡献管理应满足 GB/T CCCC CCC 的要求。

9许可管理

a) 官方开源项目在许可方面需要遵循许多规则；

——项目必须明确其下获得的许可类型。

——项目和库（由官方项目团队制作）通常应该在ASLv2下获得许可，否则必须在授权许可协议（CLA）支持的许可下获得许可，该许可允许开源社区在ASLv2下重新分发为了成为OpenStack项目的依赖项， 外部库（由第三方开发人员生成和发布）必须根据OSI批准的许可证进行许可，该许可证不限制消费项目的分发。可接受的许可证列表包括XXX。

——在验证或测试开发阶段使用的GPL库属于灰色区域 - 它们不被认为是兼容的或不兼容的，而是根据具体情况进行审查。请使用legal-discuss 邮件列表来提出任何此类案例。

10商业化管理

10.1认证管理

 为保证社区代码的质量、可用性、互操作性等内容，社区将依托于项目管理委员会作为社区官方唯一认证机构。

10.2赞助管理

开源社区开发功能是帮助开发者接受赞助。在线支付系统如PayPal、支付宝等对此种方式有着非常大的帮助。知名前端框架Vue就是基于此类模式实现的商业化。

10.3广告管理

通过在开源项目社区等渠道投放广告获得收入。

10.4商标

与开源社区或任何技术项目相关的任何商标，包括但不限于与任何一致性程序相关的任何商标，必须转让给社区项目,并由其持有，并可根据社区的商标使用政策使用

11补充社区对自己推广

12补充社区本身的功能，如推广运营