6 月 1 日，开放原子开源基金会（以下简称基金会）发布针对孵化项目的毕业标准 v1.0。毕业标准 v1.0 制定总体遵循“宽进严出”原则，注重考察项目代码和社区的成熟度，并把项目的安全性作为最高优先级。
为进一步了解毕业标准 v1.0 制定意义和其背后价值观，OSCHINA 采访了 TOC 副主席谭中意，TOC 成员徐亮、霍海涛、马涛；并参与 TOC 组织的针对毕业标准 v1.0 的讨论会，本文据此梳理各方对毕业标准 v1.0 的看法和解读。如果你对本份毕业标准有疑问或见解，或是想参与开放原子开源基金会共建工作，欢迎在评论区留言，或发送消息到 xuyijun@oschina.cn 联系我们。
毕业标准 v1.0 制定遵循“宽进严出”原则
开放原子此次发布的毕业标准 v1.0 共分成 10 大章节，共 45 条条款，相较于项目进入基金会孵化时的 4 条要求，数量陡增，这实际上与标准制定时的原则——“宽进严出”有较大关系。
TOC 成员徐亮解释，基金会的总体原则是宽进严出。项目进入基金会孵化的准入门槛非常宽松，“基本上只要我们认为比较符合的项目都可以进入”。但是在毕业时，TOC 做了非常多调研工作，比如大量参考 ASF 和 CNCF 的毕业条款、规章制度，同时也根据开放原子自身的定位做了一些调整，如表述的变更等等。
“基金会最重要的事情就是指导一个项目从孵化到毕业，我们采用宽进严出的原则，相对来说毕业条件非常高，这应该是整个 TOC 里最重要的文档，而且会指导我们之后很多导师的工作，所以重要性非常高，所以我们也非常慎重。”TOC 副主席谭中意表示。
毕业标准注重考察什么，为什么？
本份标准考察重点包括项目成熟度、安全性、中立性等方面。关于这些问题的讨论以及相关条款的制定，也折射出开放原子的价值观取向。
- 聚焦成熟度
谭中意介绍，此份毕业标准在制定时聚焦在成熟度上，一个项目商业意义上的成功分为三个阶段：第一是项目开发的成熟度，即项目本身具备可信的程度；第二是项目上下游的联动，即该项目成为事实标准；第三是成为商业、产业界标准。
“我们在制定标准时讨论，先聚焦在第一个阶段项目成熟度上，让项目可信，让用户有信心使用项目。”
项目成熟度主要包括社区成熟度和代码成熟度。第九部分【Maturity（成熟度）】中对项目代码的成熟度做了详细要求。
关于社区成熟度的考量主要包含在毕业标准第六部分【Community（社区）】中，这也是整个毕业标准中篇幅最长的一部分，共有 10 条条款。
为什么有关社区的考核标准最多？谭中意解释，项目能走下去的最关键特征是有成熟的社区做支撑，社区的多样性和长期的可持续性是项目发展必不可缺的条件，这也是 TOC 花很大篇幅制定其相关内容的原因。
- 项目的安全性是最高优先级
毕业标准第 5 章【Quality（质量）】第 2 条（OA-QU-20）规定：“项目的安全性是最高优先级”。
对此，TOC 主席堵俊平向一些开源界人士征询意见：强调安全性最高优先级是否有必要？
姜宁认为，安全问题要高度重视，也要在内部建立相应的响应机制，否则后续可能没人敢再用这些软件。
庄表伟认为，开放原子是否将安全性放在最高优先级，涉及到基金会对开源项目、安全的理解，这是选择问题，不是对错问题。堵俊平回答道：“基金会设定孵化毕业标准，本身就是对旗下项目成熟度有所承诺，是对项目用户负责的一种体现。如果不重视安全性，或者项目对用户的安全性不提供任何承诺，则会对项目本身以及基金会品牌造成大的伤害。强调项目的安全性既是我们的选择也是我们的态度。”
- 中立性是重要的
当我们提到开源软件基金会，通常会谈到“中立性”，进入某一基金会的开源软件可以将其版权、商标权等通过多种方式转移至基金会，以此保证项目中立性。反之，基金会在项目进入或是毕业时也会对项目中立性有所要求，为社区繁荣提供保障。
开放原子开源基金会毕业标准中也有许多条款是为了保障开源项目以及社区中立性而设计。
但近年来一些企业开源的项目，类似 Android，TensorFlow 甚至最近国内比较火的 PingCAP 并没有强调中立性也取得了成功，这种现象该如何解释？中立性为什么还是重要的？堵俊平向大家抛出了这两个问题。
姜宁认为中立性是建立社区很重要的原则，如果基金会不保持中立的话，有些事情可能就守不住了。
刘天栋认为，中立性的取舍也是选择问题，如果想要项目保持中立可以加入基金会，如果希望社区由公司主导，可以选择不进入基金会。
庄表伟和林旅强都认为这件事涉及基金会的价值取向。庄表伟称，可以先区分成功的开源项目和好的开源项目，开放原子需要对好的开源项目有一个界定，比如认定成功的但是不中立的开源项目是不好的，需要有价值观的判断。林旅强则认为，如果基金会的目的在“孵化成功”，中立性则非成功的必要条件，如果将“产业多方共建”作为判断标准，中立性是必要关键，先确定逻辑问题就解决了。
对此，堵俊平表示，多数基金会都比较中立，这个观点无论是从逻辑还是历史上都是一直存在的。
部分条款详解
- 项目代码有完整的变更历史
TOC 副主席谭中意：
代码的管理应该有完整的变更历史，所有变更的版本都可以被重新构建。这其实是两件事情。
一是针对大公司捐献的项目，不希望出现内部一个版本、外部一个版本，然后定期同步，但同步过程中会把许多编程历史丢掉，这是一种不够开放的方式。如果采用这种方式是我们不能接受的，我们希望每一条代码提交都应该有完整的变更历史，这样社区就知道是谁提交的，为什么提交。
二是已经发布的版本都可被重新构建，社区用户可以根据文档，从零代码开始重新构建出来。这也涉及到研发成熟度，比如社区的每个发布版本的二进制文件是否可以满足被重新构建的条件。这条看似简单，但想要做到，就需要每个版本都实实在在按照可信的操作方式来生产，同时每次提交都要在公开可见的版本管理软件上进行。
- 贤能治理
TOC 成员徐亮：
贤能治理，最初我们在翻译的时候，是没有贤能治理这四个字的，是经过很多轮讨论确定下来的。在英文语境中，这个词是 meritocracy，并不完全是一个褒义词，我们并不觉得用 meritocracy 形容社区是完全正确的事情，但是我们又觉得在开源社区中，所谓的能者上氛围是比较积极向上的，是社区能够健康运转的主要因素。
很多开源项目中，一方面大家都是贡献者，另一方面你提交的功能越重要，或者对项目本身做出了更有意义的贡献，就更有可能被现任维护人员选中去承担更重要的角色。开放原子开源基金会也鼓励这样的行为。
包括也考虑到我们希望毕业项目的社区是相对独立的，在毕业标准制定过程中希望避免出现一家公司主导的情况，我们也希望给开放原子负责的项目推荐一个“到底如何产生独立运转机制”的概念。最终我们确定下来，希望社区能以贤能治理的精神去让项目自己不断成长，更好地走下去。
- CLA 贡献者协议
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 的，在可执行的层面。
此外，关于对毕业标准意义的理解，孙金城认为，这不是在研究项目该怎么做，而是从让项目更好的角度出发，基金会可以在这些维度上提供更好的帮助，梳理出基金会能够为项目做哪些事情、提供哪些经验等等。姜宁进一步解释，毕业标准可以让孵化中和之后的项目都有明确目标，包括参与指导孵化的导师也有了明确目标，对后续业务开展有很大帮助。
主要争议
此次采访与研讨会中，主要的争议点是许可证。开放原子在毕业标准中仅设置了一条许可证相关条款：
该条款并未划定许可证使用范围，且开放原子开源基金会的知识产权政策目前在草案阶段，其中符合“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 的角色，本身也会转化为部分项目的导师。
再说下为什么不能一刀切。因为开源项目有大有小，大的项目比如操作系统级别，组件非常多，其持续迭代能力也很强，活跃度、参与人数自然会比较多；小的项目比如一些工具类的项目，开发到一定程度之后就会成熟，活跃度自然会降下来。所以具体的活跃度做不到一刀切。
谭中意：怎么实现活跃度的问题。我们现在的毕业条款怎么实现，会通过导师具体指导进入孵化的项目，通过导师的言传身教来达到毕业的标准。