跳到主要内容

Apache 衡量项目成熟度的方式

Apache 成熟度模型旨在阐述 Apache 项目运营时的关注目标，以及一个可以衡量各个关注目标的定性模型。实践当中，这个模型广泛用于指导进入 Apache 孵化器的开源软件项目建立起高质量的开源软件以及围绕软件的活跃社群。

当然，由于项目类型、背景、参与者和用户各不相同，这些指标都不是教条的，更不是每一条都必须要做到。Apache 成熟度模型当中也没有“必须”达到的字样，或者定量的描述，而是定性地描述一个相对多数 Apache 成员认同的衡量模型。

代码​

  • CD10 项目生产开源软件，并免费向公众分发。
  • CD20 任何人都可以轻易发现和访问项目代码。
  • CD30 任何人都可以使用公开的标准工具可复现地从源码中构建软件。
  • CD40 项目代码的完整历史都被源码控制系统管理起来，任何人都可以重新构建已发布的版本。
  • CD50 源码控制系统记录的信息可以明确每行代码的出处，及其对应的提交者的可信签字认证。对于第三方贡献的代码，提交信息也能清楚地表明代码来源。

虽然 The Apache Way 强调了 Community Over Code 的原则，但是这不意味着只要社群不要代码，而是强调代码不会自动演进，只有活跃的社群才能保证代码持续迭代。

开源社群不是别的社群，而是围绕开源软件形成的社群。高水平的开源社群依赖高质量的开源软件支撑，Apache 成熟度模型首先描述了支撑社群的软件代码应该有哪些特质。除了源码控制系统管理和代码来源审计以外，需要关注的是最基础的要求是软件必须是开源软件，并且免费向公众分发。

虽然有些声音指出“开源不等于免费”，但是无论是 Apache 软件基金会还是自由软件基金会，都强调了源代码必须免费可得。“开源不等于免费”的合理解释是开源软件距离生产系统的解决方案还有距离，为了满足生产系统的需求和承担生产系统的责任，产生的定制化需求和服务需求是存在商机的。

ASF 的章程当中明确定义了 Apache 项目生产开源软件，并免费向公众分发。ASF 甚至做了一个专门的页面讨论关于开源、自由和免费的话题。

协议及版权​

  • LC10 发布代码以 Apache License v2.0 许可。
  • LC20 项目代码必须依赖的库，不会产生比 Apache License 更多的限制。
  • LC30 项目代码必须依赖的库都是开源的。
  • LC40 提交者都签署了个人贡献者协议，该协议定义了提交者可以提交什么代码以及如何识别非己所有的代码。
  • LC50 项目清晰地定义和记录了一切产物的版权所有权。

Apache 孵化器在孵化新项目时，一个关键的问题就是处理好冠以 Apache 名号的软件的协议和版权问题。

毫无疑问，Apache 项目应该以 Apache License 许可。值得注意的是 LC20 的描述，这是关于 GPL 和 Apache License 不兼容的一个侧面。一方面，依赖以 GPL 许可的库会导致软件本身无法仅以 Apache License 许可。另一方面，GPL 依赖库会带来比 Apache License 更多的限制，例如要求下游采用特定的许可条款发布。ASF 同样做了一个专门的页面讨论与 GPL 的兼容性问题，也有专门的页面将依赖分类并指导项目如何处理各个类型的依赖。

另一个关注点是 ASF 要求提交者都签署个人贡献者协议。虽然 Apache 的个人贡献者协议当中也有个人贡献者让渡 relicense 权利的条款，但是其目的在于 Apache License 演进时能够适时更新项目的开源协议。这不同于商业公司的 CLA 经常是为将来改变为更加封闭的商业协议埋伏笔。

发布​

  • RE10 发布包含了以标准、开放可读的归档格式分发的源码，从而保证分发的源码长期都是可读的。
  • RE20 发布经过项目管理委员会（PMC）批准，从而保证所有发布都是 Apache 基金会所为。
  • RE30 发布内容包含发布人的签名和内容摘要，从而保证所有人都可以校验下载到的归档文件。
  • RE40 项目可以随源码分发二进制文件，但是这些二进制文件不是 Apache 发布版，只是为了方便用户使用而分发，不带任何保证。
  • RE50 项目记录了完整的发布流程，新用户可以独立地重复构建与发布版相同且完整的内容。

Apache 孵化器在孵化新项目时，另一个关键问题就是项目必须能够制作一系列的 Apache 发布版。

如前所述，ASF 章程中明确定义了 Apache 项目生产开源软件，并免费向公众分发。所有 Apache 发布版某种意义上都代表了 Apache 这个品牌的价值。进入 Apache 孵化器的项目各有各的动机，但是一个明显的实惠就是能够冠名 Apache 来进行市场营销。ASF 制定了详细的发布政策讨论什么是 Apache 发布版，以及一个 Apache 项目可能会制作哪些与发布相关的产物。

对于具体的一个 Apache 项目来说，完整记录发布流程，并且确保新用户可以独立地重复构建与发布版相同且完整的内容是很重要的。这背后是 Apache 的文化对开源的认识。开源从来都不只是开放源代码，生产开源软件不只是将源代码丢给用户，而是要保证可运行的软件的整个交付过程。每个 Apache 孵化器项目在毕业成为顶级项目之前，不仅至少要制作若干个 Apache 发布版，还必须要证明这个过程可以由不同人分别相对独立地完成。

TiDB 项目也试图记录自己的发布流程，但是由于受到某些公司内部决策和工具依赖的限制，并非任何人都可以承担发布协调员的职责。此外，TiDB 发布版的获取也是不稳定的，直到最近的版本才依托 GitHub 完成源代码的发布，而二进制文件的发布仍然托管在一个临时的文件服务器上，其地址并不像 Apache 的发布地址 downloads.apache.org 一样可靠。发布的内容也没有电子签名，发布本身也没有一个公开测试和投票决议的过程。

质量​

  • QU10 项目对自身代码质量保持开放且诚实的态度。不同模块有不同质量和成熟度水平是自然的，只要能够清楚地沟通就可以接受。
  • QU20 项目高度重视生产安全的软件。
  • QU30 项目提供记录良好、安全且私密的渠道以报告并回应安全问题。
  • QU40 项目重视后向兼容性，对任何不兼容改动都予以记录，并提供工具和文档帮助用户迁移到新功能、新特性。
  • QU50 项目全力及时回应记录在案的缺陷报告。

这些内容都是典型的软件工程的要求。实际上，开源协同很大程度上是一种先进的软件工程实践。Apache 项目对后向兼容性的重视闻名在外，Apache ZooKeeper 等项目都保持了良好的后向兼容性，在满足语义化版本的定义限制下，你可以使用最新的客户端连接上十年前发布的服务端。对于安全问题的反馈，只要看到 Apache Log4j2 在发现安全漏洞以后第一时间修复和发布的责任心，应该就能有所理解。

软件不可能没有缺陷，最低的要求是对软件的缺陷和问题保持开放且诚实的态度，最高的要求是全力及时回应缺陷报告。这两点似乎看起来无甚差异，但是实际做到“全力及时”的项目，又有多少呢？

社群​

  • CO10 项目有一个广为人知的官网，包含所有根据成熟度模型运营项目所需的信息。
  • CO20 社群欢迎任何人的参与贡献，只要这是真诚、相互尊重且为项目创造价值的。
  • CO30 参与贡献是多样的，包括代码、文档、建设性的缺陷报告和讨论、市场营销以及任何为项目创造价值的活动。
  • CO40 社群致力于精英治理，并赋予持续为项目创造价值的参与者更多权利和责任。
  • CO50 项目文档记录了参与者如何赢得更多权利，包括提交权限和决策权限等等，并始终实践这些原则。
  • CO60 社群基于参与决策的成员的共识运行。Apache 项目不欢迎任何形式的独裁者。
  • CO70 项目全力及时回应用户问题。

社群方面 Apache 成熟度模型强调最多的是创造价值，这与《共同创造价值》一文不谋而合。

开源面对面在推特上曾经提到“共同创造价值，而不是欢迎谁给谁贡献代码，不存在谁给谁的事情！”这正是一个对开源误区的阐述。

很多时候，一个公司或组织想要运营一个开源项目社群，却总是落入了傲慢的陷阱。它们自以为是地认为自己是项目的主人，允许其他人来“贡献”已经是莫大的恩赐，“贡献”者应该感恩戴德，无偿付出，以至于公司或组织甚至以有多少人无偿“贡献”来直接衡量运营的结果。这种认识并不是“共同创造价值”的思路，而是寻找无偿工作的员工的思路，应该予以批判。

共识​

  • CS10 项目维护一个拥有决策权限的成员名单，这些成员组成了项目管理委员会（PMC）。
  • CS20 决策必须在 PMC 成员当中达成共识，共识需要记录在项目主要的沟通渠道上。PMC 会在考虑社群成员的意见后做出最终决定。
  • CS30 讨论得不到结论时，项目采用记录在案的投票规则达成共识。
  • CS40 否决仅适用于代码提交，同时，提出否决的成员需要给出合理的技术解释。
  • CS50 所有重要的讨论都应该异步地进行，并以文字形式记录在项目主要的沟通渠道上。关乎项目发展的线下讨论、当面沟通和私下交流事后都应该公开记录。

如同社群 CO60 提到的，Apache 社群不欢迎任何形式的独裁者，这是 The Apache Way 当中 Community of Peers 原则的体现。Apache 一方面更加相信精英集体决策的力量，另一方面竭力避免独裁者模式导致巴士系数过低的情形。

《大教堂与集市》当中《开垦心智层》一章第 3.16 小节《项目组织结构与所有权》也讨论了社群应当如何组织的问题。同样关注这个话题的还有《社群运营的艺术》当中《治理》一章。这两本书都推荐阅读。

此外，The Apache Way 还有 Open Communications 的原则，也就是上面提到的所有重要的讨论都应该记录在案，所有线下的讨论事后也都应该公开记录。

关于这一点，《制造开源软件》专门有一章《避免私下讨论》做了详细分析。

独立性​

  • IN10 项目独立于任何公司或组织的影响。
  • IN20 参与者仅代表他们自己，而不代表任何公司或组织。

Apache 是中立的。从 Apache Group 的第一天起，它就不曾由相同背景的成员所组成。不出意外的是，独立性也是写进 The Apache Way 的原则之一。此外，Apache 有两个文档都专门提到了它的独立性。

避免公司和组织的显式影响是 Apache 的选择。每个 Apache 孵化器项目在毕业之前，都要回答 Homogeneous Developers 的问题，也就是说，项目的开发者是否都是相同背景的。这同样是对集体智慧的信任和避免过低的巴士系数带来的风险。

阿里巴巴曾经向 Apache 捐赠了 Weex 项目，然而在这个单一开发者群体由于种种原因离开以后，社群从此凋敝，并于 2021 年退休。

其他一些相似的例子，例如曾经在 Hortonworks 支持下运作的 Apache Ambari 项目，在商业公司被并购之后，就失去了活力并于 2022 年 1 月退休。同样，开发者背景相近的 Apache Livy (Incubating) 和 Apache Heron (Incubating) 这两个孵化项目，也先后提出了退休的讨论。

其中，Heron 于 2023 年 1 月通过了项目退休的投票。Livy 虽然开发者背景相对单一，但是用户多样性还行，因此有用户希望转变为开发者继续维护这个项目，目前退休讨论搁置。至于去年已经退休的 Ambari 项目，实际上在许多公司的 Hadoop 软件栈当中还占据着重要位置，因此在已有用户和新的希望成为 Ambari 供应商的公司的努力下，项目在不到半年的时间里就复活了。

Apache 相信 Community Over Code 的原则，前提是这个 Community 有足够的多样性，从而能够支撑项目在仍然有人需要的时候保持响应和演进。