Apache 成熟度模型[1]旨在阐述 Apache 项目运营中的关注目标和定性模型，可以衡量每个关注目标。在实践中，该模型被广泛用于指导进入 Apache 孵化器开源软件项目围绕软件建立了高质量的开源软件和活跃社区。
当然，由于项目类型、背景、参与者和用户不同，这些指标不是教条，更不用说每个指标了。Apache 成熟度模型中没有必要的字样或定量描述，而是定性地描述了相对多数字 Apache 成员认可的测量模型。
代码 CODE
?CD10 项目生产开源软件，免费分发给公众。?CD20 任何人都可以很容易地找到和访问项目代码。?CD30 任何人都可以使用公共标准工具从源代码中复制软件。?CD40 源码控制系统管理了项目代码的完整历史，任何人都可以重建已发布的版本。?CD50 源代码控制系统记录的信息可以明确每行代码的来源和相应提交人的可信签名认证。对于第三方贡献的代码，提交信息也可以清楚地标明代码来源。
虽然The Apache Way[2]强调了 Community Over Code 但这并不意味着只要社区不想要代码，而是强调代码不会自动演变，只有活跃的社区才能保证代码的持续迭代。
开源社区不是其他社区，而是围绕开源软件形成的社区。高水平的开源社区依赖于高质量的开源软件，Apache 成熟模型首先描述了支持社区的软件代码的特点。除了源代码控制系统管理和代码源审计外，最基本的要求是软件必须是开源软件，并免费分发给公众。
尽管有声音指出开源不等于免费 Apache 软件基金会和免费软件基金会都强调，源代码必须是免费的。开源不等于免费的合理解释是，开源软件离生产系统的解决方案还有很长的路要走。为了满足生产系统的需要，承担生产系统的责任，定制需求和服务需求存在商机。
ASF 的章程[3]明确定义 Apache 项目生产开源软件，免费分发给公众。ASF 甚至只做了一个特殊的页面[4]讨论开源、自由和免费的话题。
协议及版权 LICENSES AND COPYRIGHT
?LC10 发布代码以 Apache License v2.0 许可。?LC20 必须依赖项目代码的库不会产生比较 Apache License 更多限制。LC30 必须依赖项目代码的库都是开源的。LC40 提交人签署了个人贡献者协议[5]，该协议定义了提交人可以提交的代码以及如何识别非自己的所有代码。LC50 该项目清楚地定义和记录了所有产品的版权所有权。
Apache 孵化器孵化新项目时，一个关键问题是处理冠以 Apache 软件名称协议和版权问题。
毫无疑问，Apache 项目应该以 Apache License 许可。值得注意的是 LC20 这是关于的 GPL 和 Apache License 不兼容的一个侧面。一方面，依赖 GPL 允许的库会导致软件本身无法使用 Apache License 许可。另一方面，GPL 依赖库会带来比较 Apache License 例如，下游需要发布特定的许可条款。ASF 也做了一个特殊的页面[6]讨论与 GPL 的兼容性问题，也有专门的页面[7]如何处理各种类型的依赖将依赖于分类和指导项目。
另一个关注点是 ASF 尽管要求提交人签署个人贡献者协议。 Apache 个人贡献者协议中也有个人贡献者让渡 relicense 协议的条款，但其目的是 Apache License 项目的开源协议可以及时更新。这与商业公司不同 CLA 它通常是为未来变更封闭的商业协议铺平道路。
发布 RELEASE
?RE10 发布包括以标准和开放可读的归档格式分发的源代码，以确保分发的源代码长期可读。?RE20 发布经过项目管理委员会（PMC）为了确保所有的发布都是批准的 Apache 基金会所为。?RE30 发布内容包括发布人的签名和摘要，以确保每个人都能验证下载的归档文件。?RE40 二进制文件可以随源码分发，但这些二进制文件不是 Apache 发布版只是为了方便用户使用而分发，没有任何保证。?RE50 项目记录了完整的发布过程，新用户可以独立重复构建与发布版本相同的完整内容。
Apache 孵化器孵化新项目时，另一个关键问题是项目必须能够制作一系列 Apache 发布版。
如前所述，ASF 章程中明确定义 Apache 项目生产开源软件，免费分发给公众。 Apache 从某种意义上说，发布版代表了 Apache 这个品牌的价值。 Apache 孵化器项目各有动机，但一个明显的好处就是可以命名 Apache 营销。ASF 制定了详细的发布政策[8]讨论什么是 Apache 发布版，还有一个 Apache 与发布相关的产品可能是什么？
对于具体的一个 Apache 对于项目来说，完整地记录发布过程，确保新用户能够独立地重复构建与发布版本相同且完整的内容是非常重要的。这背后是 Apache 文化对开源的理解。开源不仅仅是开源代码，生产开源软件不仅是将源代码留给用户，更是保证软件的整个交付过程。每个 Apache 在毕业成为顶级项目之前，孵化器项目不仅要制作至少几个项目 Apache 还必须证明，这一过程可以由不同的人相对独立地完成。
?Apache Curator 发布流程文档[9]?Apache Flink 发布一系列流程文档[10]
TiDB 项目还试图记录自己的发布过程[11]，但是由于受到某些公司内部决策和工具依赖的限制，并非任何人都可以承担发布协调员的职责。此外，TiDB 发布版的获取也不稳定，直到最近的版本才依赖 GitHub 完成源代码的发布，二进制文件的发布仍然托管在临时文件服务器上，其地址不同 Apache 的发布地址downloads.apache.org[12]同样可靠。发布的内容没有电子签名，发布本身也没有公开测试和投票决议的过程。
质量 QUALITY
?QU10 项目对自己的代码质量保持开放诚实的态度。只要能清晰地沟通，就可以接受不同模块的不同质量和成熟度。?QU20 高度重视生产安全软件。?QU30 为报告和回应安全问题提供记录良好、安全、私密的渠道。?QU40 重视项目后的兼容性，记录任何不兼容的变化，并提供帮助用户迁移到新功能和新特性的工具和文档。?QU50 项目全力及时回应记录在案的缺陷报告。
这些内容是软件工程的典型要求。事实上，开源协作在很大程度上是一种先进的软件工程实践。Apache 该项目以重视后向兼容性而闻名，Apache ZooKeeper 所有其他项目都保持了良好的后向兼容性。在满足语义版定义的限制下，您可以使用最新的客户端连接十年前发布的服务端。只要看到安全问题的反馈 Apache Log4j2 发现安全漏洞后，应理解第一时间修复和发布的责任感。
软件不可能没有缺陷。最低要求是对软件的缺陷和问题保持开放和诚实的态度。最高要求是及时响应缺陷报告。这两点似乎没有什么不同，但有多少项目实际上是及时的？
社群 COMMUNITY
?CO10 该项目有一个广为人知的官方网站，包括所有根据成熟度模型运营项目所需的信息。?CO20 只要真诚、相互尊重、为项目创造价值，社区就欢迎任何人的参与和贡献。?CO30 参与贡献多样，包括代码、文档、建设性缺陷报告和讨论、营销和任何为项目创造价值的活动。?CO40 社区致力于精英治理，并赋予继续为项目创造价值的参与者更多的权利和责任。?CO50 项目文件记录了参与者如何获得更多的权利，包括提交权限和决策权限，并始终实践这些原则。?CO60 基于参与决策的成员的共识运作。Apache 该项目不欢迎任何形式的独裁者。?CO70 及时响应用户问题。
社群方面 Apache 成熟模型最强调的是创造价值，这与共同创造价值有关[13]一文不谋而合。
开源面对面[14]在推特[15]上面曾经提到过共同创造价值，而不是欢迎谁贡献代码，没有人给谁！这是对开源误解的解释。
很多时候，一个公司或组织想要经营一个开源项目社区，总是陷入傲慢的陷阱。他们自以为是地认为自己是项目的所有者，允许他人贡献是一份伟大的礼物。贡献者应该感谢戴德的免费努力，这样公司或组织甚至可以直接衡量有多少人的免费贡献。这种理解不是共同创造价值的想法，而是寻找免费工作的员工的想法，应该受到批评。
共识 CONSENSUS BUILDING
?CS10 项目维护成员名单由项目管理委员会组成会（PMC）。•CS20 决策必须在 PMC 成员当中达成共识，共识需要记录在项目主要的沟通渠道上。PMC 会在考虑社群成员的意见后做出最终决定。•CS30 讨论得不到结论时，项目采用记录在案的投票规则达成共识。•CS40 否决仅适用于代码提交，同时，提出否决的成员需要给出合理的技术解释。•CS50 所有重要的讨论都应该异步地进行，并以文字形式记录在项目主要的沟通渠道上。关乎项目发展的线下讨论、当面沟通和私下交流事后都应该公开记录。
如同社群 CO60 提到的，Apache 社群不欢迎任何形式的独裁者，这是 The Apache Way 当中 Community of Peers 原则的体现。Apache 一方面更加相信精英集体决策的力量，另一方面竭力避免独裁者模式导致巴士系数[16]过低的情形。
《大教堂与集市》[17]当中《开垦心智层》一章第 3.16 小节《项目组织结构与所有权》也讨论了社群应当如何组织的问题。同样关注这个话题的还有《社群运营的艺术》[18]当中《治理》一章。这两本书都推荐阅读。
此外，The Apache Way 还有 Open Communications 的原则，也就是上面提到的所有重要的讨论都应该记录在案，所有线下的讨论事后也都应该公开记录。
关于这一点，《制造开源软件》[19]专门有一章《避免私下讨论》[20]做了详细分析。
独立性 INDEPENDENCE
•IN10 项目独立于任何公司或组织的影响。•IN20 参与者仅代表他们自己，而不代表任何公司或组织。
Apache 是中立的。从 Apache Group 的第一天起，它就不曾由相同背景的成员所组成。不出意外的是，独立性也是写进 The Apache Way 的原则之一。此外，Apache 有两个文档都专门提到了它的独立性。
•Project independence[21]•INDIVIDUALS COMPOSE THE ASF[22]
避免公司和组织的显式影响是 Apache 的选择。每个 Apache 孵化器项目在毕业之前，都要回答 Homogeneous Developers 的问题，也就是说，项目的开发者是否都是相同背景的。这同样是对集体智慧的信任和避免过低的巴士系数带来的风险。
曾经在 Hortonworks 支持下运作的 Apache Ambari[23] 项目，在商业公司接受合并之后，就失去了活力并最终退休。相似的例子不胜枚举，Apache 相信 Community Over Code 的原则，前提是这个 Community 有足够的多样性，从而能够支撑项目在仍然有人需要的时候保持响应和演进。
References
[1] Apache 成熟度模型: https://community.apache.org/apache-way/apache-project-maturity-model.html[2] The Apache Way: https://www.apache.org/theapacheway/index.html[3] ASF 的章程: https://www.apache.org/foundation/bylaws.html#6.3[4] 页面: https://www.apache.org/free/[5] 个人贡献者协议: http://apache.org/licenses/icla.pdf[6] 页面: https://www.apache.org/licenses/GPL-compatibility.html[7] 页面: https://apache.org/legal/resolved.html[8] 详细的发布政策: https://www.apache.org/legal/release-policy.html[9] Apache Curator 的发布流程文档: https://cwiki.apache.org/confluence/display/CURATOR/For+Curator+Committers#ForCuratorCommitters-ReleasingCurator[10] Apache Flink 的系列发布流程文档: https://cwiki.apache.org/confluence/display/FLINK/Releasing[11] 发布流程: https://pingcap.github.io/tidb-dev-guide/project-management/release-train-model.html[12] downloads.apache.org: https://downloads.apache.org/[13] 《共同创造价值》: https://tisonkun.org/2022/02/10/value-creation/[14] 开源面对面: https://github.com/opensource-f2f/episode[15] 推特: https://twitter.com/osf2f/status/1491677885677334529[16] 巴士系数: https://en.wikipedia.org/wiki/Bus_factor[17] 《大教堂与集市》: https://book.douban.com/subject/25881855/[18] 《社群运营的艺术》: https://book.douban.com/subject/26976995/[19] 《制造开源软件》: https://producingoss.com/en/producingoss.html[20] 《避免私下讨论》: https://producingoss.com/en/producingoss.html#avoid-private-discussions[21] Project independence: https://community.apache.org/projectIndependence.html[22] INDIVIDUALS COMPOSE THE ASF: https://www.apache.org/foundation/how-it-works.html#hats[23] Apache Ambari: https://attic.apache.org/projects/ambari.html