6 月 1 日，开放原子开源基金会（如下简称基金会）发布针对孵化项目的毕业标准 v1.0。毕业标准 v1.0 制定整体遵循“宽进严出”原则，注重考察项目代码和社区的成熟度，并把项目的安全性做为最高优先级。编程

为进一步了解毕业标准 v1.0 制定意义和其背后价值观，OSCHINA 采访了 TOC 副主席谭中意，TOC 成员徐亮、霍海涛、马涛；并参与 TOC 组织的针对毕业标准 v1.0 的讨论会，本文据此梳理各方对毕业标准 v1.0 的见解和解读。若是你对本份毕业标准有疑问或看法，或是想参与开放原子开源基金会共建工做，欢迎在评论区留言，或发送消息到 xuyijun@oschina.cn 联系咱们。浏览器

毕业标准详情查看：开放原子开源基金会发布孵化项目毕业标准 v1.0安全

往期报道回顾：【专题】多角度深刻解析开放原子开源基金会运维

受访人物简介：ide

谭中意：TOC 副主席、百度前开源技术委员会的负责人工具

徐亮：TOC 成员、华为开源能力中心技术专家区块链

霍海涛：TOC 成员、360政企浏览器事业部总经理大数据

马涛：TOC成员、阿里云研究员、基础软件部操做系统团队负责人ui

研讨会部分参与者阿里云

TOC 成员：

堵俊平：开放原子开源基金会TOC主席、Apache软件基金会Member、华为计算开源总经理

开源界 KOL：

刘天栋：开源社理事兼联合创始人

庄表伟：开源社理事长

姜宁：华为开源能力中心技术专家、基金会孵化项目导师、Apache软件基金会 Member

王泽锋：华为云原生开源负责人、CNCF技术监督委员会贡献者、基金会孵化项目导师

温铭：支流科技联合创始人＆CEO、 Apache Skywalking committer

孙金城：阿里云物联网分析负责人、Apache软件基金会 Member、基金会孵化项目导师

林旅强：华为云 AI 开发者生态专家，开源社理事兼联合创始人

高阳：SegmentFault 思否 CEO，开放原子大学第一届特聘讲师

江波：SegmentFault 思否 COO，开源社副执行长

梁尧：开源社理事

毕业标准 v1.0 制定遵循“宽进严出”原则

开放原子这次发布的毕业标准 v1.0 共分红 10 大章节，共 45 条条款，相较于项目进入基金会孵化时的 4 条要求，数量陡增，这实际上与标准制定时的原则——“宽进严出”有较大关系。

TOC 成员徐亮解释，基金会的整体原则是宽进严出。项目进入基金会孵化的准入门槛很是宽松，“基本上只要咱们认为比较符合的项目均可以进入”。可是在毕业时，TOC 作了很是多调研工做，好比大量参考 ASF 和 CNCF 的毕业条款、规章制度，同时也根据开放原子自身的定位作了一些调整，如表述的变动等等。

“基金会最重要的事情就是指导一个项目从孵化到毕业，咱们采用宽进严出的原则，相对来讲毕业条件很是高，这应该是整个 TOC 里最重要的文档，并且会指导咱们以后不少导师的工做，因此重要性很是高，因此咱们也很是慎重。”TOC 副主席谭中意表示。

毕业标准注重考察什么，为何？

本份标准考察重点包括项目成熟度、安全性、中立性等方面。关于这些问题的讨论以及相关条款的制定，也折射出开放原子的价值观取向。

聚焦成熟度

谭中意介绍，此份毕业标准在制定时聚焦在成熟度上，一个项目商业意义上的成功分为三个阶段：第一是项目开发的成熟度，即项目自己具有可信的程度；第二是项目上下游的联动，即该项目成为事实标准；第三是成为商业、产业界标准。

“咱们在制定标准时讨论，先聚焦在第一个阶段项目成熟度上，让项目可信，让用户有信心使用项目。”

项目成熟度主要包括社区成熟度和代码成熟度。第九部分【Maturity（成熟度）】中对项目代码的成熟度作了详细要求。

关于社区成熟度的考量主要包含在毕业标准第六部分【Community（社区）】中，这也是整个毕业标准中篇幅最长的一部分，共有 10 条条款。

为何有关社区的考核标准最多？谭中意解释，项目能走下去的最关键特征是有成熟的社区作支撑，社区的多样性和长期的可持续性是项目发展必不可缺的条件，这也是 TOC 花很大篇幅制定其相关内容的缘由。

项目的安全性是最高优先级

毕业标准第 5 章【Quality（质量）】第 2 条（OA-QU-20）规定：“项目的安全性是最高优先级”。

【英】The project puts a very high priority on secure software.

【中】项目的安全性是最高优先级的

对此，TOC 主席堵俊平向一些开源界人士征询意见：强调安全性最高优先级是否有必要？

姜宁认为，安全问题要高度重视，也要在内部创建相应的响应机制，不然后续可能没人敢再用这些软件。

庄表伟认为，开放原子是否将安全性放在最高优先级，涉及到基金会对开源项目、安全的理解，这是选择问题，不是对错问题。堵俊平回答道：“基金会设定孵化毕业标准，自己就是对旗下项目成熟度有所承诺，是对项目用户负责的一种体现。若是不重视安全性，或者项目对用户的安全性不提供任何承诺，则会对项目自己以及基金会品牌形成大的伤害。强调项目的安全性既是咱们的选择也是咱们的态度。”

中立性是重要的

当咱们提到开源软件基金会，一般会谈到“中立性”，进入某一基金会的开源软件能够将其版权、商标权等经过多种方式转移至基金会，以此保证项目中立性。反之，基金会在项目进入或是毕业时也会对项目中立性有所要求，为社区繁荣提供保障。

开放原子开源基金会毕业标准中也有许多条款是为了保障开源项目以及社区中立性而设计。

但近年来一些企业开源的项目，相似 Android，TensorFlow 甚至最近国内比较火的 PingCAP 并无强调中立性也取得了成功，这种现象该如何解释？中立性为何仍是重要的？堵俊平向你们抛出了这两个问题。

姜宁认为中立性是创建社区很重要的原则，若是基金会不保持中立的话，有些事情可能就守不住了。

刘天栋认为，中立性的取舍也是选择问题，若是想要项目保持中立能够加入基金会，若是但愿社区由公司主导，能够选择不进入基金会。

庄表伟和林旅强都认为这件事涉及基金会的价值取向。庄表伟称，能够先区分红功的开源项目和好的开源项目，开放原子须要对好的开源项目有一个界定，好比认定成功的可是不中立的开源项目是很差的，须要有价值观的判断。林旅强则认为，若是基金会的目的在“孵化成功”，中立性则非成功的必要条件，若是将“产业多方共建”做为判断标准，中立性是必要关键，先肯定逻辑问题就解决了。

对此，堵俊平表示，多数基金会都比较中立，这个观点不管是从逻辑仍是历史上都是一直存在的。

部分条款详解

项目代码有完整的变动历史

OA-CD-30

【英】The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.

【中】应经过源代码管理系统保留项目代码的完整变动历史，全部已发布版本均可以被从新构建

TOC 副主席谭中意：

代码的管理应该有完整的变动历史，全部变动的版本均可以被从新构建。这实际上是两件事情。

一是针对大公司捐献的项目，不但愿出现内部一个版本、外部一个版本，而后按期同步，但同步过程当中会把许多编程历史丢掉，这是一种不够开放的方式。若是采用这种方式是咱们不能接受的，咱们但愿每一条代码提交都应该有完整的变动历史，这样社区就知道是谁提交的，为何提交。

二是已经发布的版本均可被从新构建，社区用户能够根据文档，从零代码开始从新构建出来。这也涉及到研发成熟度，好比社区的每一个发布版本的二进制文件是否能够知足被从新构建的条件。这条看似简单，但想要作到，就须要每一个版本都实实在在按照可信的操做方式来生产，同时每次提交都要在公开可见的版本管理软件上进行。

贤能治理

OA-CO-40

【英】The community strives to be meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.

【中】社区要符合贤能治理的精神，随着时间的推移，为项目增值的贡献者会被赋予更多的权利和责任

TOC 成员徐亮：

贤能治理，最初咱们在翻译的时候，是没有贤能治理这四个字的，是通过不少轮讨论肯定下来的。在英文语境中，这个词是 meritocracy，并不彻底是一个褒义词，咱们并不以为用 meritocracy 形容社区是彻底正确的事情，可是咱们又以为在开源社区中，所谓的能者上氛围是比较积极向上的，是社区可以健康运转的主要因素。

不少开源项目中，一方面你们都是贡献者，另外一方面你提交的功能越重要，或者对项目自己作出了更有意义的贡献，就更有可能被现任维护人员选中去承担更重要的角色。开放原子开源基金会也鼓励这样的行为。

包括也考虑到咱们但愿毕业项目的社区是相对独立的，在毕业标准制定过程当中但愿避免出现一家公司主导的状况，咱们也但愿给开放原子负责的项目推荐一个“到底如何产生独立运起色制”的概念。最终咱们肯定下来，但愿社区能以贤能治理的精神去让项目本身不断成长，更好地走下去。

CLA 贡献者协议

OA-CD-40

【英】The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance.

【中】每一行代码必须由具有强认证机制的提交者经过源代码管理系统创建，当提交第三方贡献时，提交备注中要包含可靠的代码来源信息

TOC 副主席谭中意：

强认证机制能够理解成每一个代码提交者都必须签署 CLA 或者 DCO，愿意把本身贡献的代码的版权受权给到基金会的项目，这样就能够保证其余开发者或用户使用开放原子毕业的项目时，不存在太大的版权问题。

注：Contributor License Agreement 贡献者许可协议(Contributor License Agreement，简写 CLA)是一套向开源项目运营主体（基金会或企业）授予知识产权权利的机制，不一样开源项目和开源社区一般有各自的一套 CLA 协议，协议行文及受权表述相对严谨。CLA可分为我的贡献者许可协议（Individual CLA）和法人贡献者许可协议（Corporate CLA）。

Developer’s Certificate of Origin开发者原创声明（Developer’s Certificate of Origin，简写DCO）是开发者声明贡献为原创及有权基于开源许可证对下游受权许可的文档，其内容简洁，非法律人士也易于阅读和理解，不一样开源许可证项目都可适用。

TOC 成员霍海涛：

这条在标准里讨论的确不少很细节，对毕业项目来讲相当重要。

如今开源的项目不多有每一行代码都是从新开发的，越大的项目越是会引入不少成熟的第三方软件，它里面的一些贡献者条例涉及到是否容许受权。若是引入一些有许可证/版权问题的代码，影响是很大的。因此成熟的社区中，参与代码贡献时，即使已经有了代码，第一步必定要签署 CLA 或者DCO，签署完成以后你提交的代码才有可能被 review 或者 merge。

举个极端的例子，若是不签署CLA或者DCO，某个代码提交者可能在项目成功被使用后，会由于某些代码由他来提交的而要求使用者来找他受权。这样对使用者来讲是很不现实的，风险极大，每每会放弃使用该项目。所以，签署了CLA/DCO以后，使用者能够在没有法律风险的状况下去使用、推广项目。

从执行来讲，已经在孵化或者已经运行了一段时间的项目，CLA/DCO清理工做仍是一个比较大的工做量。基金会在运维方面，提供一个通用的 CLA/DCO模板，更好地去把流程打通，也是未来发力的一个重点。

毕业标准给谁看？

庄表伟在研讨会中提出本身对毕业标准意义的理解，包含三个层面：一是对被孵化项目的指引；二是对外的展现，表明开放原子某种品质上的认证；三是放手的意思，基金会认为该项目能够自由健康的发展下去。他认为，若是从这些意义出发，基金会针对这个标准应该有更多的解读和发声，以便更适合外界查看并理解这些标准。

针对这个问题，堵俊平表示目前这份毕业标准其实是写给项目导师和 TOC 的，在可执行的层面。

此外，关于对毕业标准意义的理解，孙金城认为，这不是在研究项目该怎么作，而是从让项目更好的角度出发，基金会能够在这些维度上提供更好的帮助，梳理出基金会可以为项目作哪些事情、提供哪些经验等等。姜宁进一步解释，毕业标准可让孵化中和以后的项目都有明确目标，包括参与指导孵化的导师也有了明确目标，对后续业务开展有很大帮助。

主要争议

这次采访与研讨会中，主要的争议点是许可证。开放原子在毕业标准中仅设置了一条许可证相关条款：

Licenses and Copyright（许可证与版权）

OA-LC-10

【英】The code is released under the open source license that project used, meets the compatibility requirements and complies with OpenAtom Foundation's IPR policy

【中】代码发布须要知足项目所采用开源许可证的合规性/兼容性要求，且符合开放原子开源基金会的知识产权政策

该条款并未划定许可证使用范围，且开放原子开源基金会的知识产权政策目前在草案阶段，其中符合“OSI 认证的开源许可证”都被容许使用，推荐优先使用宽松类许可证。姜宁认为这是开放原子的一大特色：许可证没有做出明确规定实际上是给项目必定的发展空间，好比 Apache 许可证可能不太适合一些云厂商，可是咱们加了“OSI 认证”，框了一下，也是一个很大的亮点。

不过，也有许多人对此提出疑问，下面将问题与基金会TOC成员的回答列出：

OSCHINA：冷门许可证也是能够接受的吗？

徐亮：咱们在项目捐赠的时候，其实都会和项目讨论，你为什么要选择这样一个许可证？

无论是宽松的仍是相对更为限制的许可证，咱们都会探讨选择的缘由，是基于什么考虑，是否有更好的建议，咱们并不把本身局限于什么样的许可证，也不局限推荐特别宽松的，咱们指望的是说，基于项目的状况去讨论，但首先要是一个开源许可证。

刘天栋：基金会是否有关于许可证兼容方面的考量？

堵俊平：一方面要遵照 OSI 的规范，知足十大原则；一方面项目捐献以前容许存在许可证问题，可是要整理一个待办清单，毕业时要保证兼容性。因此孵化过程当中，孵化团队要把兼容性风险降下来。

温铭：基金会如今支持全部的许可证使用，这会有一个问题，若是别人不敢在商业环境中使用它，可不能够把协议改掉？

堵俊平：咱们首先不歧视任何一个 OSI 下的协议，不歧视、不反对、咱们优先推荐你们使用更宽松的协议，包括木兰许可证、Apache 许可证，它们不只商业友好，并且法律风险更小。咱们认为全部捐赠项目都要扩大社区和开发者生态。

庄表伟：其实许可证的选择也是基金会的选择。开放原子基金会选择什么？不能说我都要，我甚至以为大家应该给出一组具体许可证。各类许可证都要可能会带来复杂性，但挑一组就能够避免冲突问题。

姜宁：许可证冲突实际上是开源项目许可证与项目引入第三方开源项目许可证的冲突，在这里开源项目选什么样的许可证均可能引发冲突，须要具体问题具体分析。

林旅强：庄表伟讲的是立场问题，很多国外基金会立场鲜明，例如 ASF 有本身的许可证。相较之下，开放原子基金会彷佛没有特别明显的立场？

堵俊平：Linux 基金会旗下的许可证也有宽松和传染性的。开放原子诞生的定位就是包容性的开源基金会，可能承载了 Linux 的形态，也兼容了 Apache 的形态。咱们也有特点，吸纳了 Linux 的商业友好特质，也吸纳了 ASF 对社区的态度。

至于吸引什么样的项目取决也自己的生态，大数据领域不少项目使用 Apache 许可证，区块链领域不少内核是 GPL。从整个理念上咱们仍是坚持包容的原则，许可证不该该是拒绝一个好项目的条件，兼容性方面若是须要法律支持，咱们后续会适当扩充一些法律资源。

对话基金会丨有机会在嵌入式 OS，区块链等方向构建独特生态

刘天栋：基金会目前有 8 个正在孵化中的项目，将来考不考虑设置沙箱？有一些项目社区还没成熟可是能够在沙箱里作调整，包括稀缺资源导师也能够在沙箱里观察。

堵俊平：这是看分几个孵化阶段。ASF 大体有 2 个阶段，CNCF 是 3 阶段，这个问题咱们也讨论过。现阶段根据导师资源的状况，2 个阶段是相对合理的选择。将来项目多了，能够考虑再加一个阶段。

刘天栋：基金会考不考虑为我的贡献者作激励机制？如今的贡献者许可能是由公司支持，或是 ASF 都是志愿者，因此彻底不会为开发者付费。开放原子开源基金会是否是考虑采用适当的激励我的开发者贡献者的机制，让如今企业单位成员以外，我的贡献者也有平衡发展的机会。

堵俊平：首先企业有参与的热情，有开源项目和很强的意愿加入。从我的角度来讲，如何回馈或是激励我的开发者，若是有好的建议会去参考。

刘天栋：进入孵化器，毕业成为顶级项目，这不是目的而是一个结果。目的不同，产出结果就会不同。国内的项目为何要进入开放原子开源基金会，而不是国际上的基金会？

再具体一点，对于一些新创企业、项目，是否是能够提供更多机会让他们加入？

堵俊平：咱们并不认为开放原子是局限于中国的基金会，它是立足中国面向全球，从这个角度，项目加入基金会是对本土开源生态的丰富。

从项目角度，ASF 生态中的项目已大数据为主、中间件生态强；Linux 基金会偏重内核项目；咱们认为在新的领域会有新的机会，好比嵌入式 OS，区块链等其余方向，开放原子在这些领域可能构建一个比较好的生态。

对于孵化项目的进入，采用宽进严出原则，准入门槛低，由理事会推荐并找到 TOC 背书。咱们的 TOC 分布也很普遍，一些 TOC 是以我的身份加入，知足准入标准并不难。

OSCHINA：毕业标准 OA-CO-80 规定要有必定数量的活跃提交者和至关规模的代码提交数量和合并数量，为何没有具体肯定下来？

谭中意：

具体数字咱们没有拍下来，由于 ASF 毕业条件默认数量是 3，可是咱们以为应该大于等于 3，而不限于 3，咱们但愿看到项目多样性，项目能够有长期可维护的状态，但很差一下在拍成 3。

徐亮：

咱们在这里把一些判断项目是否足够活跃、是否有至关规模的事情交给导师。由于每一个项目在向 TOC 陈述的时候，须要项目导师提供一个在辅导过程当中的报告，包括他们对项目的评估。咱们也但愿在这个事情上赋予导师更大的权限。

咱们理解不一样项目在软件供应链中有不一样的位置，可能底层软件达到某种状态后就会比较稳定，有些更加上层的应用则会持续快速往多个方向延伸，咱们但愿有不一样的项目，把部分责任交给导师，由导师提供意见给 TOC，TOC 再进行评判，因此咱们如今没有轻易把数量拍成 3。

OSCHINA：那关于保证活跃度这项，TOC 会给到什么帮助吗？

霍海涛：个人想法是，TOC 主要目的仍是在孵化流程制定，就像徐亮老师说的，给导师更高的自由度，由于他们可能在这个项目上更专业、看得更细。固然 TOC 的角色，自己也会转化为部分项目的导师。

再说下为何不能一刀切。由于开源项目有大有小，大的项目好比操做系统级别，组件很是多，其持续迭代能力也很强，活跃度、参与人数天然会比较多；小的项目好比一些工具类的项目，开发到必定程度以后就会成熟，活跃度天然会降下来。因此具体的活跃度作不到一刀切。