我在《GreptimeDB 社群观察报告》当中提过，GreptimeDB 的 good-first-issue 流转速度极快，大部分容易上手的工作往往在一周甚至两三天内就会有人认领，并且完成的情况也还不错。这个体验很难得。

在最近一些 Good First Issue 的流转过程中，我重新发现了一些典型的模式。正好同大家分享一下我对于如何处理 Good First Issue 这个问题的看法。

还是先看几个案例。

第一个案例算是标杆：

• Support automatic DNS lookup for kafka bootstrap servers
• feat: Support automatic DNS lookup for kafka bootstrap servers

可以看到这里有两个要点。

1. Issue 上仔细说明了问题是什么，为什么要解决这个问题，相关代码在哪里，可能的实现思路是什么。
2. Pull Request 里作者积极的提问，并且说明他做了什么改动，有哪些 alternative 是考虑过但是不可行的。

这位 contributor 后来也开始参与到其他 issue 的解决中。

第二个案例介绍了一种处理 stale assign 的方法：

• Unexpected trim behavior of join_path
• fix(util): join_path function should not trim leading /

注意这里我并没有直接 assign 给这位新出现的开发者，而是在他提交 PR 之后才 assign 给他表示这个 issue 已经有人开始工作。当然，如果他能在 issue 中表达任意有效信息推动 issue 前进，我也会 assign 给他。

第三个案例是我相对担心的：

• Add strict mode to validate protocol strings

因为 issue 的描述我读完以后都觉得，可能需要耗费相当时间梳理清楚相关逻辑。这个时候一个没有过任何开源项目 contribution 经验的新人贸然说要开始接手这个工作，且不说明他的计划，也没有任何问题要追问。在我的记忆里，这种 assignee 很容易回头发现搞不定。如果能主动说自己搞不定，unassign 还好，但是更多人是默默离开，一言不发。

于是我追加问了一下他的计划：

嗯……虽然有点抽象，但是至少多产生了一些有用的信息，暂且信一回。

关于这个问题，我有一段相关的论述：

Assign contributor 的时候可以做个背调，或者直接问一下 TA 的实现计划，除非 issue 确实是闭着眼睛都能做的。另一方面，这也跟 good first issue 有没有相关代码链接，有没有写清楚需求有关。比如上面的典范写清楚了，就容易让 contributor 上手做起来。

Contribution 不只是上来写代码，能经过交流把 issue 往前推进一步，对项目都是有帮助的。因此 issue 也不一定每个都要写得那么详细，毕竟大佬可以自己脑补很多内容。只是很多新手，他不知道可以问问题，或者就模糊地问一句“你有什么可以帮我的吗”。

不用害怕劝退潜在的参与者，如果正常交流都不能回答，大概率不能解决问题，或者做出 PR 来很抽象，review 起来想死。当然，我也见过不用太多交流也能做得很好的，那种大佬会一个 PR 拍你脸上，也不会被劝退。

最近比较像的比如这位：

• Implement itertools.batched with a function to drop requirement of Python 3.12

不过无论如何都有可能出现 assignee 出于各种原因无法完成 issue 的情况。从维护者的角度说，兜底可以问一下进度然后 unassign 掉。这个是可以自动化的。我在 GreptimeDB 上记了一个 Good First Issue 来实现这个自动化：

• Auto un-assign if an open issue without PR associated stale

其他相关的话题这里就不展开了，如果各位有兴趣听，可以回复我来讲。

• 不同文化背景的 Assignee 的倾向；比如这位是比较典型的。
• Good First Issue 怎么设置比较合适？
• 企业开源项目如何在 Issue 上与跨越组织边界合作？

对于关注 GreptimeDB 想找机会参与的读者，现在主仓库还有一些未解决的 Good First Issue 可以上手，即使有人 Assign 了，如果过去数周没有什么进展，也可以由你来接手推进。

如果你不是 Rust 开发者，GreptimeDB 也有各个语言的客户端正在开发。对于 DevOps 开发者，GreptimeDB 的命令行工具 gtctl 正在准备发布第一个版本，我和项目作者都会及时处理上面的信息。对于前端开发者，GreptimeDB 的 Web UI 也是一个独立的开源项目。

总的来说，GreptimeDB 是一个值得参与的开源项目。其软件产品目标是成为一个高效、实惠，且可以处理分析大规模时序数据的云数据库。目前已经可以替换 InfluxDB 和作为 Prometheus API 的存储后端。

GreptimeDB 是格睿科技（Greptime）公司研发的一款开源时序数据库，其源代码在 GitHub 平台公开发布。

我从 2022 年开始知道有 GreptimeDB 这个项目。2023 年，我注意到他们的 Community Program 是有认真写的，不是无脑复制所谓成功项目的大段规则，于是开始跟相关成员探讨开源治理和社群运营的话题。后来，我读过 GreptimeDB 的源代码，发现他们的工程能力很不错，于是就开始参与贡献。

经过这几个月的参与，我对 GreptimeDB 的社群有了初步的了解。我认为，这是一个值得参与的拥有巨大潜力的开源社群。于是写作这份社群观察报告做一个简单介绍和畅想。

GreptimeDB 的社群量化情况

两年前，曾有人半开玩笑地说 Rust 和时序数据库都快成开源世界的一个梗了，因为当时有大量的 Rust 语言写作开源项目和定位在时序数据库的开源项目出现。GreptimeDB 也算其中一员，它同样是用 Rust 语言写成的。

不过两年过去，回过头看能够坚持下来不断发展的项目，GreptimeDB 就是为数不多硕果仅存的一员。哪怕跟主流时序数据库项目社群相比，GreptimeDB 的活力也可圈可点。

上面两张图展示了 2023 年，即 GreptimeDB 开源运营第一年，从 OpenDigger 数据集生成的每月 OpenRank 和活跃指数（Activity）数据折线图。

可以看到，从 OpenRank 的维度看，GreptimeDB 显著超越了近年来发展乏力的 InfluxDB 项目，跟 TimescaleDB 和 Prometheus 不分伯仲，相比起战斗民族出品的商业开源产品 VictoriaMetrics 仍有差距。从项目活跃指数的维度看，GreptimeDB 则与 InfluxDB 之外的主流项目同属第一梯队。

OpenRank 是同济大学赵生宇博士定义的一个开源价值流分析指标。相比于容易受先发优势影响的 Star 数和 DB Engines 分数等指标，上面展示的每月 OpenRank 和 Activity 变化情况更能体现出项目当前的发展情况和未来趋势。

GreptimeDB 的社群运营情况

前面提到，我真正开始关注 GreptimeDB 社群的契机是发现他们的 Community Program 并非船货崇拜，而是明显经过思考，有一定可行性的。事实证明，确实如此。2023 年 GreptimeDB 按照 Community Program 的设计发展了两名公司之外的 Committer 新成员：

• Biweekly Report (Jun.5 - Jun.18) – A Key Milestone, First External Committer Onboard
• Biweekly Report (Jul.17 - Jul.30) – Welcome the Second External Committer!

这两位 Committer 都是通过代码贡献被提名的，提名前都提交了大约二十个代码补丁，且质量被项目团队所认可。此外，这两位 Committer 从开始参与项目发展到成为 Committer 都经过了若干个月的持续投入。可以看到，这个标准下筛选和认可的两位 Committer 在上个月仍然有活跃参与。

应该说，目前 GreptimeDB 的项目功能已经初具规模，能够达到线上交付的标准。这也意味着开荒阶段的大量初创工作已经完成，新加入的社群成员可以在一个坚实的工程基础上发挥自己的创造力。同时，GreptimeDB 在实现优化上还有很大的进步空间，倒排索引、WAL 和存储引擎等技术方向上还有很多未解决的设计实现问题。现在仍然是参与 GreptimeDB 成为 Committer 的机遇期。

不过，GreptimeDB 的 Community Program 距离成为一个商业开源标杆还有不少可以改进的地方。

例如目前邀请新的 Committer 只在 Biweekly 上简单提及。Community Program 设计的结构上并没有即时体现出它正常运转，以及社群存在公司之外的 Committer 的事实。对于活跃参与者和 Committer 的介绍和成功经验分享，也尚有欠缺。目前社群基本处于给代码写得好的人一份权限的朴素运营阶段。

此外，Community Program 虽然已经相比其他船货崇拜的同行删减了许多内容，以保证它能够务实地运作，但是仍然存在一些空洞的组织结构。例如设计出的 Steering Committee 做技术和社群发展决策，但是实际上当前阶段大部分工作就是公司团队商议决定后公开；例如还是定义了 SIG 乃至 OSPO 的组织，但是根本没有人力填充运营这些机构。

我认为，Community Program 应该继续依托当前社群实际运行的状态，结合期望达成且有能力达成的下一个状态，来做修订。例如，提高成为 Committer 的标准和路径的透明性，积极分享案例和邀请 Committer 说出自己的故事。例如，精简冗余和虚假的组织架构的同时，保留在社群征求意见和决策结果向社群公开的关键动作。例如，强调社群成员参与渠道的多样性，鼓励在不同渠道帮助他人使用 GreptimeDB 和参与贡献。这部分是 Ambassador/Advocate 的核心。

除了这个堪称开拓性探索工作的 Community Program 之外，GreptimeDB 社群还有两件事情让我印象深刻。

第一个是 GreptimeDB 社群积极参与开源之夏这样的务实的开源活动，今年释放的三个挑战项目都实现了不错的开源导师传帮带效果：

• Greptime & 开源之夏完美收官
• 邹伟：从 0 到 1 迈出开源世界第一步
• 实现 Truncate Table 功能
• 实现滑动采样窗口函数的语法及计算
• 实现对 Duration 和 Interval 数据类型的支持

第二个是 GreptimeDB 的 good-first-time issue 流转速度极快，大部分容易上手的工作往往在一周甚至两三天内就会有人认领，并且完成的情况也还不错。实际认领实现过程中，只要你能够主动更新进展和提问，项目团队成员大多能及时回复。这个体验还是很难得的。

GreptimeDB 的未来发展期望

前面介绍 GreptimeDB 的时候，提到了开源、Rust、分布式、云原生、时序数据库等关键词。虽然这些 buzzword 确实也是 GreptimeDB 能力或特点的一部分，但是从注重实效的程序员（The Pragmatic Programmer）的角度来说，我们还可以做一个具体的展开。

即使当初市面上已经有“恒河沙数”的时序数据库存在，GreptimeDB 的创始团队还是发现了这些现存解决方案没能处理好的问题。对于时序数据当中重要的三个分类：指标（Metrics）、事件（Events）和日志（Logs），大多数时序数据库都只能最优化其中一到两种分类的存储和访问。

GreptimeDB 的创始团队认为，这三类数据可以共用同一套查询层和对象存储层能力，只需要针对各自的数据特性实现各自的存储引擎即可。其中大部分 DB 的架构和能力，例如数据分片、分布式路由，以及查询、索引和压缩等都可以共享。这样，GreptimeDB 最终能够成为同时提供所有时序数据最优化的存储和访问体验的单一系统。

开源应用监控项目 Apache SkyWalking 自研数据库 BanyanDB 也是基于相似的挑战和思考，不过它作为一个监控项目的子项目，更多是以相当特化的方式在实现。但是这反应了时序数据可以统一存储逐渐成为业内共识，所有的通用主流产品都将朝这个方向发展。

在仰望星辰大海的期许之外，GreptimeDB 也有脚踏实地的挑战。

例如，虽然我前面夸赞 GreptimeDB 的工程化水平不错，工程师做功能扩展和代码重构都能找到一个相对整洁的切面，但是软件工程是一个即使知道了原理和最佳实践，真正做出来还是有相当长的必要劳动时间的领域。在快速原型迭代的过程中，GreptimeDB 对内存和抽象的使用是相对奔放的。随着线上应用逐渐增多，GreptimeDB 团队也能收到用户上报的各种性能问题。这就要求重新关注到在快速开发过程里被刻意忽略的细节，精打细算关键路径上的内存使用，针对性能修改抽象以充分利用机器资源。这部分工作都是细致工作，讲究一个 benchmark 发现性能瓶颈并逐个优化。目前的 GreptimeDB 应该有相当多这样的优化机会。

例如，之所以过去时序数据库没能同时服务前面提到的三种不同数据，除了数据建模上的差异，更主要还是因为在数据量暴涨之后，特定数据类型的特定访问形式的读写性能会骤然降低。目前针对此类问题，业界提出了一系列索引方案进行改良。GreptimeDB 目前正在实现其中倒排索引的方案，也将探索结合倒排索引、基于 Cost 的查询优化器和 MPP 查询引擎的自适应方案。这些工作存在许多参与机会，目前 GreptimeDB 团队成员也有不少精力投入在此。

例如，系统层面数据一致性和性能之间的取舍依赖 WAL 模块的实现。目前，GreptimeDB 仅提供了本地的 RaftEngine 实现和 Kafka Remote 的实现，其中 Kafka Remote 的实现发布还不足三个月。这部分工作现在跟进来，参与到现有实现的完善和优化，以及可能的自研 WAL 设计实现过程当中，对任何数据系统开发者而言都将是一段宝贵的经历。

例如，GreptimeDB 在部署形式上支持云端同构部署，时序数据从设备端到云端都是同一套技术栈在处理。这时，如果 GreptimeDB 能够支持一些高级的分析能力，那么时序数据分析的成本将大大降低，体验也将进一步提高。目前，GreptimeDB 已经支持通过 SQL / PromQL / Python 脚本等形式执行分析，正在设计实现基于 Dataflow 技术的分析功能。分析的需求无穷无尽，这一部分对于熟悉数据分析的开发者来说，是一个很好的切入点。

核心数据库系统代码之外，GreptimeDB 还开源了完整的 Dashboard 方案和多语言客户端。再加上本身 GreptimeDB 就支持 SQL 和 PromQL 等业内通用接口，从 GreptimeDB 与生态集成的角度入手参与到 GreptimeDB 的发展，也是一条不错的道路。就在几天之前，我还看到有位同时使用 EMQX 和 GreptimeDB 的开发者向 GreptimeDB 的 Erlang 客户端提交补丁。

软件开发参与之外，Greptime 社群维护的两个重要渠道：GitHub Discussions 主题讨论平台与 Slack 即时通信工作空间都欢迎任何对 Greptime 开源和商业产品感兴趣的人加入。

GreptimeDB 的商业与可持续

我曾经表达过一个观点：商业化不是开源项目可持续的必要条件。因为许多开源软件是个人开发者兴趣所为，这些个人开发者可以有其他经济收入。即使不基于其创造的开源软件做商业变现，也不影响这些开源项目持续维护和发展。

不过，GreptimeDB 是 Greptime 公司研发的开源软件，而公司要想存续下去，就必须以某种形式取得盈利。Greptime 公司投入了不少资本和人力在 GreptimeDB 的研发上，那么 GreptimeDB 总要为 Greptime 的商业成功创造价值。

Greptime 公司目前有两条商业产品线：

• GreptimeCloud 提供了全托管的云上时序数据库服务，其内核是 GreptimeDB 系统。这个服务可以免费试用，其 Playground 和 Dashboard 做的技术品味都很好。

• GreptimeAI 是为 AI 应用提供可观测性的服务。不同于其他数据库在赶上 AI 浪潮时采用的 PoweredBy AI 增强自身产品的思路，GreptimeAI 是 For AI 增强 AI 产品的思路。其实本轮语言大模型带动的 AI 浪潮对 Database 服务本身的提升还十分有限，反而是这些 AI 应用自身产生的数据需要 Database 来存储和管理。

这两个产品的底层都是 GreptimeDB 的开源代码提供的核心能力，而云控制面、企业管理、安全集成等功能，则是商业代码实现的。

至于为什么要开源 GreptimeDB 数据库核心代码，而不是干脆全部都是私有的商业代码，前几天 Meta 的财报上介绍的 Llama 开源的理由帮我省去了很多口水：

应用在 GreptimeDB 的情况，在 Greptime 团队决心做这个产品的时候，先发的主流时序数据库已经取得极大的优势，且它们几乎全是开源的。这种情况下，就算 GreptimeDB 存在没有历史包袱的优势，直接朝着正确的方向飞奔，但是软件工程的固有复杂度和必要劳动时间并不能无限减少，所以开源是追赶现有主流产品和赢得用户信赖的必选项。

当然，开源软件允许任何用户免费使用，因此构建商业价值不能直接基于开源软件本身。关于 Greptime 如何设计开源模型，或许我会另写一篇文章做对比介绍。目前而言，其开源模型接近 Databricks 的策略。虽然 GreptimeDB 是从头开始写的，不像 Databricks 直接基于开源的 Apache Spark 构造解决方案，但是其核心功能实现重度复用了已有的开源软件：

• Apache Arrow DataFusion
• Apache OpenDAL
• TiKV RaftEngine
• Apache Kafka
• …

而且，Greptime 团队对于什么功能应该开源是谨慎的，而不是 by default 开源。只有存在这样一个踌躇推敲的过程，才有可能做商业可持续的战略开源。

DISCLAIMER

在社群参与过程中，我跟 GreptimeDB 的核心社群成员有深入的交流，并于近期加入了 Greptime 团队，因此我的观察和评价可能存在一定的主观误差。欢迎各位留言或私信交流意见。

Apache OpenDAL 简介

Apache OpenDAL 是一个以软件库形式提供的数据访问层。它允许用户通过统一的 API 简单且高效地访问不同存储服务上的数据。你可以把它当作是一个更好的 S3 SDK 实现，也可以通过统一的 OpenDAL API 来简化配置访问不同的数据存储服务的工作（例如 S3 / HDFS / GCS / AliyunOSS 等）。

OpenDAL 以库形式提供，因此使用 OpenDAL 无需部署额外的服务。OpenDAL 的核心代码用 Rust 写成，因此它原生的是一个 Rust 软件库。在项目孵化和成长的过程中，社群也开发出了 Java / Python / Node.js / C 等语言的绑定，以支持在其他语言程序中方便地集成 OpenDAL 的能力。

下图列举了 Apache OpenDAL 多语言实现的线上用户：

OpenDAL 核心的统一 API 设计，其使用方式如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

async fn do_business() -> Result<()> {
    let mut builder = services::S3::default();
    builder.bucket("test");

    let op = Operator::new(builder)?
        .layer(LoggingLayer::default())
        .finish();

    // Write Data
    op.write("hello.txt", "Hello, World!").await?;
    // Read Data
    let bytes = op.read("hello.txt").await?;
    // Fetch Metadata
    let meta = op.stat("hello.txt").await?;
    // Delete Data
    op.delete("hello.txt").await?;

    Ok(())
}

可以看到，实际读写数据的 API 是经过精心设计的。用户想要访问存储在不同服务上的数据，只需修改 Operator 的配置构造，所有实际读写操作的代码都不用改动。

Apache OpenDAL 孵化

OpenDAL 起初是 @Xuanwo 在 DatafuseLabs 为 Databend 项目开发数据访问层时创造的软件库。再往前追溯，Xuanwo 在青云工作时就开发过 BeyondStorage 这一目标相近的软件。不过，由于种种原因，BeyondStorage 最终夭折了。

不同于 BeyondStorage 遇到的挫折和经历的歧路，OpenDAL 在一个明确目标的指引下快速成长：

• 2021 年 12 月，Xuanwo 在 Databend 的代码库中开始开发后来作为 OpenDAL 核心代码的数据访问层逻辑。
• 2021 年 12 月，Xuanwo 同步开始起草 OpenDAL 的定位和目标。
• 2022 年 2 月 14 日情人节，OpenDAL 的核心代码从 Databend 代码库中抽离，开始作为一个独立开源项目运作。

2022 年 8 月，Xuanwo 找到我讨论进入 ASF Incubator 孵化的可能性。彼时项目发展才大半年，几乎所有代码都是 Xuanwo 一个人开发的，也没有 Databend 之外的用户。我发给 Xuanwo 一份 ASF 孵化项目提案的模板并给出项目发展的一些建议，并告诉他如果能在用户增长上做一些工作，主动集成其他知名软件和打造示例场景，过程中发觉合作开发契机招徕开发者，年底应该项目就能成长到进孵化器标准的水平。

今天再次看到 OpenDAL 的提交历史，实际上这个时候 GreptimeDB 应该已经开始调研采用 OpenDAL 的方案。可以看到在 v0.11.0 和 v0.11.4 两个版本的发布里都有 GreptimeDB 的主创人员的参与贡献。

2023 年 1 月，春节前我正好跟 Apache Kvrocks 的成员讨论年后开始准备孵化毕业的事情，想起来之前跟 Xuanwo 交流过 OpenDAL 进入孵化器的意向，于是拉着 Xuanwo 一起起草了孵化提案，并在 2 月初开始孵化讨论。

由于项目定位清楚，并且潜在地寄托了替代行将就木的 Apache jclouds 项目的希望，孵化提案顺利地“全票通过”。

这段时间的经历可以补充阅读这两篇博文：

• OpenDAL successfully entered Apache Incubator
• 2023-07: 一些里程碑

接下来的一年，Apache OpenDAL 孵化项目社群高速发展，在功能开发、版本发布和社群成长等各个方面全面取得可观的成绩：

上图所显示的是，孵化期间 OpenDAL 发展了 10 名新 Committer 和 3 名新 PPMC 成员，并有 8 名不同的 Release Manager 发布了 11 个符合 Apache 标准的版本。

上图未显示的是，孵化期间 OpenDAL 发起并实现了 23 个技术提案，处理了超过 1000 个问题报告，合并了 2000 多个代码补丁。

早在 2023 年 8 月，我就判断 OpenDAL 已经接近孵化毕业的标准。2023 年 10 月，在进行过一些沟通之后，项目导师之一吴晟将他发现的毕业前需要完成的工作列了一份清单，正式开始推进毕业工作：

这份清单上的工作对于 OpenDAL PPMC 来说并不全是简单易懂的，甚至有很多项内容颇有挑战。后面展开讨论 OpenDAL 毕业面临的挑战时，你将看到一些挑战解决起来是很有难度的。于是，在部分简单易懂的工作完成后，清单上的项目有四五周的时间没有任何推进。

2023 年 11 月底，我在准备发起两个新的孵化提案的同时，也决定同时推进 OpenDAL 毕业的工作，免得这些理论上可以一次性完成的工作越拖越久，反而日后需要彻底重新做一遍。

事后，我在跟 Xuanwo 的讨论中得知，这些事务性工作对于开发者来说还是有一定的门槛，看到很多个一眼不知道如何开始的工作项，下意识搁置是第一反应（俗称摆烂）。我作为项目导师，把这些颇具官僚主义色彩的事务性工作用通俗的语言向 PPMC 成员解释，并拆解成一些实际可执行的工作，才能推动项目往毕业的方向前进。

2023 年 12 月，OpenDAL 项目社群内部达成了毕业共识。随后，毕业提案提交到 ASF Incubator 列表上讨论。经过一个月的激烈探讨和继续处理项目存在的问题，2024 年 1 月，项目成功通过毕业投票并在 Board Meeting 上由董事会审核通过：Apache OpenDAL 正式成为 ASF 的顶级项目。

PMC Member 的标准

ASF 词汇体系下，PMC Member 即项目管理委员会成员，大致上相当于开源项目的维护者。所有 PMC Member 都是 Committer 并且额外具有对项目发展议题投有效票（binding vote）的权力。

项目在 ASF Incubator 孵化期间也有项目管理委员会，称为 Podling 项目管理委员会（PPMC），其中 Podling 意即孵化中的项目。最初的 PPMC 通常由孵化提案中的 Initial Committers 组成。随后就是上文图中显式的走提名投票流程邀请新的 PPMC 成员。

项目毕业时，毕业提案需要说明最终形成的顶级项目的 PMC 由哪些人组成。通常，原先 PPMC 的成员包括项目导师会加入到顶级项目 PMC 中。此外，孵化阶段邀请的 Committer 也是潜在成为顶级项目 PMC 成员的候选。

万事皆有例外。比如 Apache Doris 毕业时，原先 PPMC 成员部分加入了现在的 StarRocks 公司，并且在孵化期间持续损害 Doris 的品牌。这些成员在毕业时就没有被包含在 PMC 中，甚至不是顶级项目的 Committer 了。

• Have an agreement on the members of the PMC

如同我在《Maintainer 的标准》中提到的，我倾向于给予做出贡献的社群成员更高的权限以减少他们参与的门槛，因此在发起 OpenDAL PMC 成员讨论时，我先抛出了一个极端的所有 PPMC 成员和 Committer 都加入 PMC 的提案。

这个提案遭到了 Xuanwo 和其他 PPMC 成员的挑战。他们认为因为“项目毕业”这个契机将 Committers 加入到 PMC 当中，这个说法是行不通的。

随后，项目导师吴晟回应说到 ASF 文化崇尚积极引入 Committers 和项目维护者，Committer 和 PMC Member 在代码权限上是相同的，只是 PMC Member 具有额外关注项目管理的责任，例如处理安全问题、响应 Board 的提问和要求、参与版本发布和投票决议等等。

在后续的讨论中，OpenDAL PPMC 成员表现出把 PMC Member 和 Committer 差别对待，以至于类似等级制度的表述。不过这更多的是一个表达和语境的差异，我在推特上提到：

在国内的开源宣传和讨论语境下，确实经常会有一个升级甚至权限交易的 mindset 在。甚至有人就是说开源参与像打游戏一样打怪升级。不同流派和认识存在是很正常的，只是这确实不是 ASF 倡导的方式。

最后，OpenDAL 采取的做法是在包括 PPMC 的成员和项目导师的基础上，询问所有 Committers 参与项目管理成为 PMC Member 的意愿。如果 Committer 都不看邮件列表不回这个邮件，显然跟有意愿参与项目管理事务还是有一定距离的。最终有两位 Committer 回应了轮询，他们也在近期积极参与了项目发展的讨论和组织版本发布。

另一方面，在轮询以外，直到完成毕业流程的两个月间，OpenDAL 也按照以往的流程和标准提名了一位 PPMC 成员。最终毕业成为顶级项目的 Apache OpenDAL 共有 14 名 PMC 成员：初始 4 位，孵化期间提名 3 位，轮询增补 2 位，以及 5 名孵化导师。

从我个人的标准来看，至少愿意花时间做 Release Manager 或是作为项目某个模块的 CODEOWNER 的社群成员，都应该是 PMC 成员。按照这个标准看，PyO3 的核心开发者和 OpenDAL Python 绑定的原始作者 @messense 还不是 PMC 成员，这点应该再 Review 一下。

官方网站和文档

OpenDAL 的官方网站并不算非常“惊艳”。这一方面是由于核心开发者大多缺乏前端开发技能，另一方面也是作为一个被应用集成的软件库，OpenDAL 不需要独立部署服务，自然也就没有一个独立服务配套的管控页面相关的需求可以展示。大部分情况下，OpenDAL 的使用方式是在软件当中以代码的形式被调用。

在上面的首页信息展示中，可以看到 OpenDAL 主要设计了三个扩展点。

1. OpenDAL 的核心代码是 Rust 库，但是提供了多语言的绑定，从而可以在诸多语言写成的程序中调用。提供新语言的绑定是一个扩展点。
2. OpenDAL 的核心价值是屏蔽不同存储服务后端，从而使得用户可以用统一的 API 访问不同位置的数据。提供新的存储后端集成是一个扩展点。
3. OpenDAL 设计了 Layer 抽象，以在统一 API 的访问链路上提供不同切面的增强，包括重试、日志、监控、超时等功能。

紧接着文档导航页几乎就展示了所有文档内容：OpenDAL 的设计理念，以及跳转到 QuickStart 页面的如何配置四个已经正式发布的语言的软件库。侧边栏的 Services 与其说是文档，不如说是已经支持的部分存储后端的参考手册。

相反，关于如何参与 OpenDAL 开发和作为 Committer 或 PMC Member 如何处理事务性工作的文档，由于有实际需要，是相对完整的。

其余页面，博客截至目前只发了四篇，且已经有小半年没有新发布。API 页面除了 Rust 文档，其他语言的 API 文档主要是参考手册性质的。Downloads 和 ASF 相关的页面主要是为了符合 ASF 的要求，对于项目本身基本没什么价值。

项目导师吴晟在毕业自检清单中提到了文档的问题，主要关注的是文档的版本化和避免露出未正式发布的软件库的临时文档。大体上，这是在以 Apache SkyWalking 多语言集成和多模块功能文档的标准给 OpenDAL 提建议。

OpenDAL PMC 成员之一 @suyanhanx 初步完成了文档版本化的调研工作，但是没有彻底完成，也没有更新开发和发布文档以包括相关操作。

我认为，在文档上，OpenDAL 还是有很大的提升空间的。不过在做毕业检查时，我采用了以下的标准：

• 官网大致能用起来，谈到项目概念时引用链接要齐备。
• 至少需要让想用 OpenDAL 的人知道如何用起来，整个内容阅读路径是清楚的，就还算可以了。至于版本化的问题，OpenDAL 还没到 1.0 版本，可以先只提供 nightly 版本的文档，这也是目前用户实际的用法。

其实，关于 OpenDAL 的内核设计和各个服务后端的使用方式，Rust 核心实现中已经包括了详细的版本化文档。

我认为，OpenDAL 接下来的文档优化方向，除了继续完成所有语言的版本化发布以外，应该注重阐明概念的定义和常见的设计、使用模式，以及不同语言之间的翻译定式。在这一前提下，把实际的文档内容用引用链接导向 Rust 核心实现当中伴随代码的活文档，就可以把存在于 Rust API 文档中的完整文档给利用上。

用户实际的阅读路径，首先从设计、使用模式的文档中确定自己要到 Rust API 文档中查看哪部分模块的具体文档，了解相应的接口契约之后，对应自己使用的语言，查看不同语言直接接口翻译的定式，完成逻辑开发。

如果能做到这个程度，从软件产品角度说，OpenDAL 的产品力才算堪堪能打。

多语言软件库的开发与合规

如前所述，OpenDAL 的一大特色就是在 Rust 核心软件库的基础上，提供了不同语言的绑定，以支持在各种语言写成的程序中利用 OpenDAL 的能力。这也是为什么 OpenDAL 能被寄托替代 Java 写成的 jclouds 库的原因。

目前正式发布的四种语言的 OpenDAL 库的绑定方式如下：

• Rust Core 原生 Rust 库
• Java Binding 使用 jni-rs 和 JNI 技术完成绑定
• Python Binding 使用 PyO3 技术完成绑定
• Node.js Binding 使用 napi-rs 和 NAPI 技术完成绑定

其余开发中的语言绑定包括：

• C
• C++
• .NET
• Golang
• Haskell
• Lua
• OCaml
• PHP
• Ruby
• Swift
• Zig

这其中 C Binding 已经有线上用户直接拿去用了，而其他语言的绑定则还未发布或者甚至就只有一个占位符。

在开发多语言绑定的过程中，OpenDAL 总结了一套最佳实践：

1. 暴力开发出 Hello World 示例；
2. 重构完成基本的工程化编译和测试流程；
3. 重构完成基本的 API 映射设计；
4. 跑通语言对应的发布形式。

这其中最麻烦的其实是工程化的部分和搞清楚最终要怎么发布到目标平台。目前 C Binding 的设计开发已经相对完善，但是由于 C 生态没有一个发布的定式，因此导致了 C Binding 迟迟未能正式发布。

又或者说其实 C 生态就是直接拷贝源文件，所以实际上也已经“发布”。

相反，Rust / Python / Node.js 这样有官方背书的发布平台的语言生态，OpenDAL 可以很轻松的创建对应的 GitHub Actions 工作流来完成自动发布。

值得一提的是，虽然 Java 软件库大多发布到 Maven Central 上，但是 ASF 软件对应的 Repository 不是其他项目常用的 Sonatype 资源库，而是 ASF 自己的资源库。考虑到 Maven 也是一个 ASF 项目，这一点并不奇怪。不过，这就导致支持 OpenDAL Java Binding 自动发布需要 ASF INFRA 介入。OpenDAL Java Binding 是 ASF 第二个支持自动发布的 Java 库，也是第一个自动发布 JNI 原生共享库的 Java 库。相关的工作如下：

• Setup opendal-java project GitHub secrets for signing artifacts
• ci: automatic java binding release
• docs: auto release maven artifacts
• docs(release): describe how to close the Nexus staging repo

此外，OpenDAL PMC 积极与 ASF 的品牌官员合作，探讨在 @apache scope 下发布 OpenDAL NPM 包的方案：

• Add Apache org account as the OpenDAL NPM package owner

Apache Airflow 的 Jarek Potiuk 正在与 PyPI 团队合作探讨创建一个 ASF 账号的方案。OpenDAL PMC 密切关注进展并随时准备集成 OpenDAL Python Binding 到这个账号下：

• Provide a trusted PyPI publisher capability for Python projects via INFRA

可以看到，OpenDAL 认真对待软件发布工作，通过平台提供的机制，以及与 ASF INFRA 密切合作，切实提高了所发布软件包的可靠性。

最后，ASF 在技术合规方面还非常看重所发布的软件的依赖项采用的软件协议是否符合 ASF 对软件协议的政策。OpenDAL 为每个发布的制品都提供了 DEPENDENCIES 文件来披露这一消息。同时，由于大部分其他语言的绑定都是 Rust 核心库的一个翻译层，OpenDAL 开发者们尽可能减少不必要的第三方依赖，以降低下游使用时的合规负担。

技术上，由于需要对接多个存储服务后端，并且存在提供不同语言绑定的愿景，OpenDAL 高度重视代码工程化。

查看 OpenDAL 的 GitHub Actions Workflows 就可以发现，OpenDAL 开发了一套可重用的测试框架，任何新语言绑定或新存储服务后端都能快速具备现有的测试覆盖范围。不过这也不算新奇，同样提供多语言支持和多模块分散开发的 SkyWalking 也研发了适用于自身情况的 SkyWalking Infra E2E 测试框架。

就语言绑定技术而言，Rust 本身支持 C FFI 决定了 C Binding 的实现是非常流畅的。大部分语言也会提供访问 C API 的集成方式，于是通过 C Binding 可以产生其他语言的绑定。这也是 OpenDAL Haskell / Lua / Zig 等一众绑定的实现方式。

在这种大量利用现有技术的方案之外，上面提到的 jni-rs 和 napi-rs 等技术，则是在已有的 C API 集成方式之上，封装了一层符合 Rust 习惯的接口，从而在开发层面只需要涉及 Rust 语言和绑定目标语言。PyO3 更进一步，为这个开发过程研发了一套脚手架，中间打包和配置对接的工作也全部简化了。应该说，这是 Rust 生态主动向绑定目标语言靠拢。底层技术上，两边仍然是基于 C ABI 在通信。

于是这些技术统统可以归类到 FFI 的框架下，跨语言通信的主要成本就产生于数据拷贝和线程模型同步上。可以阅读我的另一篇技术博客《Rust 与 Java 程序的异步接口互操作》了解 OpenDAL 做过的实践。我想 OpenDAL 应该会活跃在 Rust 与其他语言深度集成的前沿。如果生态中有人想要改进 Rust 与某个目标语言的互操作体验，不妨在 OpenDAL 上实践你的想法。

ASF 的政策、官僚主义与基金会发展

上文提到，在毕业讨论进入孵化器邮件列表后，截至顺利毕业前经过了一个月的激烈探讨和继续处理项目存在的问题。

绝大部分毕业前需要处理的问题，其实都包括的项目导师吴晟罗列的清单当中。在处理清单列表的过程中，文档版本问题、依赖合规问题和最终 PMC 人选问题花了一些时间研究讨论，剩下的基本都是按部就班顺利完成。

不过，在清单当中忽略了一个重要问题，那就是 ASF 项目的 PMC 要遵守品牌政策，保护项目品牌和 ASF 的品牌。这其中主要且基础的一条就是以 Apache Xxx 正式名称来引用项目。

OpenDAL 的捐赠没有经历过改名，所以大部分材料和项目核心成员在捐赠过后仍然沿用原来的称呼习惯用 OpenDAL 来指代项目，并认为既然已经捐赠到 ASF 了，那么项目归属 ASF 的事实会随着时间推进被不断强化，因此也没有特别在意。

实际上，ASF 当中明确违反品牌政策的行为主要是 DorisDB 这样直接占用品牌宣传竞争产品，或者在商业公司中用某某项目商业版来称呼自己的产品等等。OpenDAL 虽然脱胎于 DatafuseLabs 公司，但是跟商业化可以说是一点关系也没有。其核心开发者也大多是个人身份参与，所以我认为只要大家没有损害 ASF 品牌的行为也就差不多了。

但是 IPMC Chair Justin Mclean 不这么认为，他在 OpenDAL 毕业提案的讨论里抛出了品牌问题的挑战。

现在回头看，其实一开始 Justin 的表达是 “I found a few minor issues where some name and branding work needs to be done.” 并不十分强烈。但是在 Xuanwo 首次回复没有做到 Justin 期望的完美符合 ASF 政策之后，他表示 PMC 应该要“好好学习相关政策”。

随后，在 PMC 成员完全一头雾水不知道 Justin 所指的到底是什么问题的情况下，项目导师吴晟表达了不同看法，大致跟我上面说的类似，即 OpenDAL 项目成员没有损害 ASF 品牌的动机，实际指出的问题也并不是什么明显的问题，只是没有达到完美主义的标准而已。

这个回复让 Justin 彻底破防，认为 PMC 目无政策，在主观遵守规定的意愿上有严重的缺陷，于是对毕业提案投了 -1 票，并在接下来的一个月时间里充分发挥轴的特性不停地全方位质问。

这个过程给 OpenDAL 项目成员带来了非常不好的体验。不是说不能投 -1 票，而是在主观认定 OpenDAL PMC 不配合、不愿意解决问题之后，连续的挑战都不是奔着具体解决问题去的，而是为了证实 OpenDAL 的项目成员就是一群坏人，且就算 OpenDAL PMC 成员读过品牌政策做过一些 nice to have 的改进以后，得到的也不是认同和进一步改进的建议，而是“你做得还不够好”的持续 -1 批评。

我于是专门写了一篇文章《全票通过？同侪社群无须整齐划一》批评这种行为。实际上，最后 OpenDAL 的毕业提案确实没有“全票通过”。

不过，Justin 本人是 Board Member 之一，哪怕孵化项目在 IPMC 中如上图决策通过，最终是否可以建立顶级项目，还需要 Board 核准。

所以从 Justin 开始挑战，直到最终 Board 一致通过了 OpenDAL 成为顶级项目这一个月间，我跟 ASF 的商标品牌官员 Mark Thomas 以及其他 Board Member 就这个问题进行了全面的讨论。最终我们发现，实际上很多顶级项目都没有严格按照品牌政策来落实自己发布的内容，甚至一些 ASF 基金会层面官方渠道发布的内容，严格按照品牌政策来“审查”，也会有做得不够完美的地方。

不过，这并不是大家可以一起摆烂的原因。相反，这揭示了 ASF 项目在品牌保护上孱弱的现实。我做这些相关内容的讨论，也从来不是为了争个对错，而是带着相关人员重新审视一下目前 ASF 品牌政策的执行情况，从而能够用建设性的目光来评判 OpenDAL PMC 在过去和近一个月来处理品牌政策问题的行为到底做得怎么样。

在 ASF 孵化器里，一般而言顶级项目是不能作为参考的。从务实的角度出发，这是因为很多顶级项目都并不完全合规，也就是这里提到的问题。

但是我仍然坚持应该在孵化器中讨论顶级项目的做法，至少对于做得好的地方应该予以传播和认可。对于做得不好的地方，也不应该局限于孵化器的范畴，而是站在基金会的角度统一协调解决。

这是因为我清楚地知道大多数开源项目进入孵化器，或多或少受到了其他顶级项目的影响，而且进入孵化器明面上的目的就是毕业成为顶级项目。如果顶级项目都在摆烂，都没有按照 ASF 政策行事，孵化项目如何能理解它们被要求符合的政策规定？

探讨的过程中，我们发现了 OpenDAL 和其他顶级项目存在的各种品牌问题，所有已知被发现的问题都被积极解决了。这些工作被总结发送到上面提到的毕业提案结果讨论串上。

Justin 仍然认为 OpenDAL PMC 做得不像他为另一个有志于捐赠到 ASF 孵化的项目做的那样“完美”。但是在我通过对话将他的挑战彻底转化为主观担忧以后，由于我本人问心无愧，说 OpenDAL PMC “不愿意解决问题，只是被动反应，并且习惯性向外甩锅”更是无稽之谈，所以这些挑战在我列举事实的回应之下也就烟消云散了。

在交涉探讨的过程中，我认为有以下几个片段是值得注意的。

第一个是关于孵化器当中指出问题的方式。

我用了两组对比。第一个是某个孵化项目对 ASF 执行政策时体现出的官僚主义失望，从而主动退出孵化器时，提到孵化器的维护者们并不是以帮助它们的姿态出现，而是表现得像是要通过项目的失败来证实自己的权威。如前所述，Justin 在 OpenDAL 的案例上最后完全是走向“我对你错”的模式，而不是我如何帮助你一起变得更好。

这未必是 ASF 结构性的问题。对于某个孵化项目来说，主要给予它们这个印象的就是孵化器主席 Justin 本人，有一个“权威”不断地否定你，这种挫败是非常明显的。

第二个是作为一个开源社群，指出问题最好的方式是提交补丁来修复，并在此过程中传达自己的理念，再不济也是提供一个可复现的问题报告，而不是说我认为你有点问题，你要自己发现问题并解决。我用的一个类比，是现在如果有个从未参与过项目开发，也不实际使用项目软件的人，跑过来说我感觉你代码写的方式会出现一些性能问题，你最好自己测一测改过来，这种莫名其妙的报告是无法得到项目维护者的注意的。

这两组对比用英文表达会更加对仗：

• Helping us rather than failing us
• Correcting with contributions rather than instructions

第二个是关于政策的文档和实践的问题。

ASF 一个做得非常好的地方是它的社群规则和工作方式都有相应的文档记录：

• 基金会官网 apache.org 记录了基金会的目标，核心定义和各个角色的职责，以及发布、品牌和投票等相关政策。
• 社群发展网站 community.apache.org 是政策实际执行时的最佳实践参考。
• 孵化器官网 incubator.apache.org 包括了孵化全过程的指南。
• 基础设施官网 infra.apache.org 说明了主要资源的位置和使用方式。

但是，这些网站上的内容很是年久失修。

基金会官网的内容东一块西一块，除非很有经验的老成员，否则大多很难快速找到相应的材料。

社群发展网站的最佳实践基本都是十几年前的实践。号称目前开源世界最泛用的成熟度模型，对本次毕业讨论时被挑战的品牌问题只字未提。

孵化器网站内容也是极其杂糅，且有部分“指南”实际是 Justin 个人的偏好，虽然更新时流程上也是经过讨论的，但是大部分审阅的人也很久没有参与孵化，很难对指南落实的时候实际产生的问题有直观的感受。

基础设施官网也是内容稀碎，除非很有经验的老成员，否则大多很难快速找到相应的材料。而且，ASF 在过去二十几年里，基本都在 Maven Central 上发布 Java 代码库，在 SVN 仓库上发布源代码压缩包，对于新时代的不同语言不同软件的发布形式有很大的落差。

Apache OpenDAL 一方面遇上了 Justin 近期跟品牌问题较劲的点子上，另一方面由于它多语言多平台想做自动化发布的工作直接挑战了 ASF INFRA 常年的舒适区，所以在孵化和毕业时相比起其他项目，跟 ASF 的各个机构打交道的次数和时间都要多得多。

这也算是一件好事。毕竟只有新鲜血液的加入，才能促进基金会不断向前发展。只要挑战被正确引导、合作解决，那么遇上问题就不是一件可怕的事情。

第三个是关于基金会本身发展的问题。

从另一个角度考虑，为什么 Justin 总是不断地在孵化器当中投 -1 票呢？其实这也反映出孵化器人才梯队建设的问题。由于太多人并不在乎 ASF 政策和 The Apache Way 到底要以什么形式建设出一个什么样的社群和发布什么样的开源软件，所以这些违反政策和文化冲突的问题才会不停挤压到 Justin 这里处理。

久而久之，比起费尽心力去了解项目社群发展的来龙去脉，到底是什么人出于什么动机做了这些事情，人类懒惰地天性就会促使有严格要求的人先直接一个 -1 拍脸，你自己反省。对我来说，我是有足够的动力来处理合规和文化问题的，所以这种处理方式对我来说很冒犯，我会认为原本好好谈合作解决就能行。但是对于某些项目来说，确实你不 -1 我就不管你了，也不是没有这样的案例。

一个更高抽象层次的问题是，ASF 的社群发展和孵化项目的形式，迄今为止仍然是某种“作坊式”的做法。ASF 起源于几个志同道合的开发者聚在一起成立的 Apache Group 并延续了它“一小部分人掌握一系列部落知识运作起一个开源社群”的模式。

在我直接指出作为孵化毕业标准之一的成熟度模型中根本没有关于品牌的论述之前，Justin 宁愿地低效逐个讨论他发现的品牌问题，不断评价 PMC 到底是听话还是不听话，主动还是不主动，也没想到其实这个可以在孵化的必经之路上做提示，最好能做成现在官网基本合规的检查器来提升整个社群的合规水平。

The ASF is well past the point where a small number of folks who have huge “tribal knowledge” can guide the number of projects and podlings that we now have.

我在探讨这些问题的时候，推动和主动修复了一系列文档的缺失，促进了最佳实践的产生和归纳，并且思考到底我们怎么把这些政策、理念和文化传播给更多的人，让他们主动的承担起裂变传播的责任。我想这是 ASF 在走过 25 年之后，面对新的开源社群形势和软件开发方法，应该要考虑和改进的问题。实际上，这也是从参与 ASF 项目接触 Apache 社群理念和方法论的人，成长为基金会成员的一条康庄大道。

近几年，国内开源项目捐赠到 Apache 软件基金会（ASF）的案例很有一些。几乎每个在进入孵化器和从孵化器当中毕业时发通稿的项目，都会选择在标题中加入“全票通过”的字样。

诚然，大部分项目在 ASF 孵化器中茁壮成长，实际上投票结果也是没有反对票，使用这一标题无可非议。然而，对于把同侪社群（Community of Peers）作为社群核心价值之一的 ASF 来说，追求全票通过并不是必须的。

在 ASF 孵化器当中，近些年来由于孵化器主席 Justin Mclean 个人风格的原因，许多项目遭受了无端的审查压力。我认为有必要在国内营造出人人都可以，甚至都应该“全票通过”的氛围时，阐明 ASF 同侪社群的理念和工作方式，以减少项目在面临不合理的挑战时遭受的挫败，尤其是当它来自于某个看起来权威的成员时。

理念与制度支撑

The Apache Way 当中即包括同侪社群的理念：

• ASF 的参与者是个人，而不是组织。ASF 的扁平结构决定了无论职位如何，角色都是平等的，投票权重相同，贡献是基于志愿的（即使有人因为 Apache 代码的工作而获得报酬）。Apache 社区期望成员之间相互尊重，遵守我们的行为准则。我们欢迎领域专业知识，但不允许有终身仁慈独裁者。

也就是说，ASF 当中所有人在原则上都是平等的，所有的 PMC 成员在投票表决议案时具有相同的权重。

进一步地，ASF 关于投票的专门文档中写到：

• 对于流程问题的投票，遵循多数原则的常见格式：如果赞成票多于反对票，该问题被认为已通过，而不考虑赞同或反对的具体票数，即反对票不构成否决。
• 对于代码补丁的投票，反对票构成否决。为了避免否决权被滥用，投票人必须在行使否决权时提供技术理由，没有理由的否决是无效的，没有影响力。
• 对于版本发布的投票，要通过至少需要三票有效赞同票，且有效赞同票多于有效反对票。反对票不构成否决。

实际操作中，行使技术否决时，如果其他 PMC member 不认同否决者提出的理由，否决也不成立。

因此，全票通过当然是一件值得开心的事情，但是 ASF 的运作方式并不要求需要全票通过。

面对反对意见

我在指导 ASF 孵化项目的过程中遇见过多次反对意见。

先看一个压力没那么大的。StreamPark 的孵化提案在提交表决时，最终是以 8 票有效赞成票，12 票其他赞成票，两票其他反对票通过的。

• [DISCUSS] Incubating Proposal for StreamPark
• [RESULT][VOTE] Accept StreamPark into the Apache Incubator

两票反对票来自 Apache StreamPipes 的项目成员，他们没来由地觉得 StreamPark 跟他们的项目“很像”，所以不应该进入孵化器。

且不说 ASF 并不禁止定位相似的项目进入孵化器，例如复数个消息队列和功能相似的大数据软件，StreamPipes 定位是物联网的工具箱，而 StreamPark 是为流计算系统 Flink 打造的作业管理平台（现在也部分支持管理 Spark 作业）。

所以，这种反对意见，既不是有效票，更没有什么可靠的理由，忽略即可。

再看一个比较搞笑的。Doris 的毕业提案在 2022 年 4 月 27 日以 12 票有效赞成票，13 票其他赞成票“全票通过”。但是孵化器主席 Justin Mclean 在 5 月 15 日找了一下存在感发了一个反对意见。

显然，时间已经过去了，而且赞成票远多于反对票，因此 Doris 毕业是既定事实。

面对傲慢的审查

既然是同侪社群，那么允许不同的意见存在就是合理甚至必要的。有人提出反对意见，有人行使投票权投有效反对票，这都是正常的。我在本文开篇所反对的，是通过投反对票带给项目无端压力的傲慢的审查。

上面 Justin 给到 Doris 连续的负面意见，虽然对毕业结果没有影响，但是实际上作为 Doris PMC 整体处理起来的负担并不小。Justin 不停地抛出各种链接，要求 PMC 对此做出解释，其中各种无厘头或者过分的要求层出不穷。

例如，他提到，搜索 Baidu Doris 或者 DorisDB 会出现可能模糊 Apache Doris 品牌的内容，这些内容都需要 Doris PMC 去处理解决。

这根本就是扯淡的。

今天，你主动搜索 Baidu Doris 或者 DorisDB 还是会有各种导向非 Apache 品牌的内容，难道 PMC 整天啥正事儿不干，就陪你做因特网警察？这还是在 Doris PMC 对当时的品牌侵占大户，如今的 StarRocks 有较大影响力，且 Doris PMC 中不少成员受雇投入时间解决这些问题的情况下。

另一个例子来自于几乎全员志愿者的 OpenDAL 项目。

• [DISCUSS] Graduate Apache OpenDAL (incubating) as a TLP - Incubator

OpenDAL 自进入孵化器以来已近一年，在这段时间里，OpenDAL 提名了 9 位新 Committer 和 3 位新 PPMC 成员，发布了十几个版本，且分别由近十位 Release Manager 主导，不同语言的版本被多个下游软件所依赖。以任何开源社群的标准来看，这都是一个蓬勃发展且做出成绩的项目社群。OpenDAL 的作者 Xuanwo 信任 ASF 的社群发展理念，把 OpenDAL 捐赠到 ASF 当中，其本身就是对 ASF 品牌的认同。

那么好了，在上面链接对应的孵化毕业讨论中，OpenDAL 遭受了怎样的审查呢？

第一次回复，Justin 表示 OpenDAL 的一些引用最好改成 Apache OpenDAL 并带上商标标记，一些第三方的网站提到 OpenDAL 的时候也没有 Apache 的品牌。Xuanwo 看到以后及时的处理，甚至到第三方项目中提交 PR 将 OpenDAL 改成 Apache OpenDAL 的字样。

一般来说，到这里我们就可以认为 OpenDAL PMC 认真对待商标问题，尽力展现 Apache 商标，这已经很足够了。

足够吗？Justin 认为还不够呢。

Justin 进一步提出，按照 ASF 品牌政策的字面意思，所有 OpenDAL 网站的页面，都要用 “Apache OpenDAL” 来指称项目，而且都要带商标名称。最为离谱的是，这个要求连带要执行到 API 文档的每个页面上。

这个真的是保护 ASF 品牌吗？我要打个大大的问号。且不论 OpenDAL 的网站明晃晃的是在 opendal.apache.org 域名下的，根本就没有任何一个 ASF 项目，能够做到在所有网页和材料里都用 Apache ProjectName 指称项目，还要带上商标名称。还是那句话，PMC 整天啥正事儿不干，就陪你搞这些？

说到“任何一个 ASF 项目”，就不得不提 ASF 孵化器讨论里某些人的 360° 立体防御体系。其运作方式如下：

1. 顶级项目不能作为参考，原因不明反正就是不行。你说某个顶级项目也是如此，他们不会解释为什么顶级项目那么做是有问题的，甚至为什么很多顶级项目都没管这些破事，只会说顶级项目不能作为参考，其回答模式就像低水平 AI 一样。难道孵化器项目毕业，不是为了成为顶级项目？怎么顶级项目反而没这么多破事，到你这就有了？
2. 其他孵化项目不能作为参考，因为它们反正也没毕业，有问题是正常的。
3. 基金会以外的项目不能作为参考，因为我们是 ASF 孵化器，别人爱咋咋地。

你发现了吗？这样一套操作下来，一个孵化项目要 argue 自己的做法的时候，不能援引任何其他项目做参考，建设性讨论几乎无法进行。

不能参考其他项目，那怎么界定合理性呢？那就要回到 ASF Policy 及其解释了。

例如，Justin 援引 ASF 品牌政策和自己写的 Incubator Distribution Guideline 说，政策规定项目正式名称是 Apache ProjectName，所以你的 NPM 包名应该是 apache-projectname，PyPI 包名应该是 apache-projectname。下面一众项目发出问号：

• https://www.npmjs.com/package/echarts
• https://www.npmjs.com/package/openwhisk
• https://www.npmjs.com/package/@apachedubbo/dubbo
• https://www.npmjs.com/package/thrift
• https://www.npmjs.com/package/skywalking-client-js
• https://pypi.org/project/avro/
• https://pypi.org/project/datafusion/
• https://pypi.org/project/pyarrow/
• https://pypi.org/project/pyspark/

哦对了，其他项目不能被引用论述。这下无敌了。

哦，也不一定。比如 Justin 自己要证明说这个包名用 apache- 前缀是合理的时候，他就可以说：

This is no different to any project that comes to the ASF via the incubator. Many of them need to change names, often before joining the incubator, and all need to change their name to be in the form “Apache Foo”.

这又可以了。

双标。

当然，没有 ASF Policy 支持，Justin 也可以创造出一些村规来审查你。

例如，Justin 表示 opendal.databend.rs 被重定向到 opendal.apache.org 上，那么 OpenDAL PMC 就要能控制 opendal.databend.rs 这个域名。

哈？所幸 databend.rs 是捐赠 OpenDAL 的企业 DatafuseLabs 控制的，这件事情可能还没那么离谱。换个思路，任何人今天就可以搞定 opendal.vercel.app 重定向到 opendal.apache.org 上，其他服务只要想找肯定能找到，是不是 OpenDAL PMC 还得买下 Vercel 啊？

不过我依稀记得 Justin 自己 mentor 的项目 Answer 也有过 answer.dev 的旧域名吧？这个怎么说呢？

Answer 域名的问题还是我提出来的，我也是 Answer 的导师之一。在这里，Justin 明确说：

redirection would be best

这又可以了。

双标。

再来看另一个莫名其妙的审查。

上面说到要用 Apache OpenDAL™ 来指称项目的事情，OpenDAL PMC 觉得也不无道理，一些显著的引用改改也行的。于是 Python API 文档的首页就用 Apache OpenDAL™ 来指称了：

Justin 说这不行，你第一个 opendal 是包名，没有 Apache 字样。所幸我强忍恶心，耐心问了下商标团队的成员这个问题。商标团队的成员是个正常人，曰：“如果工具限制就是这样的，那也没事”。我补了一刀，说你非要说那 PMC 高低得自己做个 API 文档工具来解决合规问题。

当然，只有这个怎么够呢？这首页行了，没说其他页不行啊。pdoc 生成页面是按 Python 模块生成的，Justin 找来一个模块的文档页，指着说：你看，没有 Apache，不行。

真要较真，合着以后大家搞网站全别分页了，塞成一个大单页，就像 Kafka 这样：

合规只要做一次，岂不美哉？哦，Kafka 这个大单页也不符合 Policy 呢。

这种想要做事的人反而莫名其妙多了很多繁文缛节要搞，可不就是官僚主义么？

小结

开源社群存在的首要目的，包括 ASF 自己写的第一愿景，是支持开源开发者生产开源软件。

所谓的政策、指南、规则，其目的应该是保护社群成员免收意外风险侵扰。本身它们是一种非强制性的指引，有道理不遵循也是可以的，更不要说违反了就等同于违法。

我在 ASF 当中得到过很多人的帮助。OpenDAL 作为一个支持多语言的库，为 ASF 在很多发布方面的共识提供了讨论的基础。例如，在我和 Mark Thomas 以及 Drew Foulks 等人的合作下，OpenDAL 搞定了所有 ASF 流程以支持包括 Maven Central 在内多平台自动发布。

Justin 本人愿意花费大量的时间检查孵化项目的发版和提案，我个人对这一点本身是尊敬的。他实际上也指出过很多项目实际存在的合规或品牌问题，而且确实应该被合理的解决，包括上面一开始点出 OpenDAL 的品牌问题，OpenDAL PMC 是有可以改进的地方，也确实改进了。

但是，Justin 把 Policy 苛刻成一种对内进攻项目的武器，用一种非常令人头疼的语气攻击项目，实际上是对 ASF 品牌和孵化器更大的伤害。

此前，这种苛刻又傲慢的审查已经逼退了只有一个核心开发者的 ZipKin 项目：

• [VOTE] Withdraw from the Apache Incubator

OpenZipKin 本是监控领域的明星项目，它愿意进入 ASF 并宣传 The Apache Way 是对 ASF 品牌的巨大帮助。然而，在这封令人伤心的退出提案中，ZipKin 的主创 Adrian Cole 无不失望的写到：

Process and policy ambiguity has been ever present and cost us a lot of time and energy.
The incubator spends more energy on failing us than helping us.

这其实是一个早该被提起更高优先级的反馈，ASF 的孵化项目居然感觉到孵化器在促使它们失败而不是帮助它们成功。有了本文前面的介绍，你应该知道这是怎么一回事。

关于流程和政策的争论，我想引用 Rust 作者 Graydon Hoare 的博文 Batten Down Fix Later

这里所谓的不专业或不健康的处理方式，我至少见过四种具体的形式：

4. 通过花费时间争论消耗对手的精力。

离开阶段常常显得有点突然，因为其原因不透明，并且也有几种不同的形式，通常对应到上述处理的模式：

4. 由于精疲力竭或倦怠而退出。

毫无疑问，Justin 苛刻且傲慢的审查，就走在这个模式上。

OpenDAL 跟 ZipKin 相似，有一位明确的主创 Xuanwo。如果没有几位导师支持，就像 ZipKin 的 Adrian 一样独自面对这些东西，很难想象如何能够坚持下来。不止一次 OpenDAL PPMC 成员和项目导师对 Justin 的雷人言语表示“麻了”。Justin 本人近五年没怎么正式写过代码也让他的很多“意见”显得非常业余。

例如，要求更改发布平台上 OpenDAL 的 README 包括 Apache 商标，PMC 改完以后说下次发版就会更新。Justin 来了一句能不能不发版就更新 … 你说呢？

当然，如标题所言，ASF 是一个同侪社群，孵化器和基金会并不会因为有一个特别苛刻而傲慢的人就不工作。但是 Justin 是孵化器主席，还是 ASF 董事会九人组的成员，身在基金会中的我即使知道这是同侪社群都会感觉到不可避免的压力，更不用说对此了解较少的其他开发者了。

附

真要说起来，Justin 的表达真像他自己那样较真的理解，并没有这么大的压力。

例如，在我挑战 NPM 和 PyPI 的包名到底要不要非得用 apache- 前缀后，他改口说 Guideline 都是 SHOULD 不是 MUST 所以有理由的话不用也行。但是又不死心的加了一条临时村规说这个要改也得在毕业提案前，提前跟 IPMC 商量。争论村规毫无意义，但我确实有心情，就说 IPMC 在每次发布的时候都会检查，这些内容都是公开的。毕业提案前，导师组都觉得没问题，怎么你不在导师组里，就得跟 IPMC 商量了？我看你在导师组的项目都不怎么商量啊。

再有一个例子是蚂蚁集团捐赠 CeresDB 核心代码的时候，出于保留商标的商业动机，用新名字 HoraeDB 捐赠核心代码。另一个 ASF 老玩家 Roman 都说这种 Dual Branding 很正常了，Justin 觉得不行。

• [DISCUSS] HoraeDB proposal

“Daul branding” is nothing new, but recently, some entities have taken unfair advantage of this (including one you mentioned), and I feel the Incubator should take care that others do not also do this.

诛心言论，死了也证明不了自己只吃一碗粉。我就觉得你未来要 taken unfair advantage of this 了，你说你不是，我觉得你是。

Why a company would be unwilling to give up that brand or trademark just because it may be convenient in the future is a concern.

为什么呢？商业行为，甚至都找不到 ASF Policy 来说这不行了，但我不喜欢，我觉得是个 concern，你就要给我解释。

HoraeDB 的提案，最后我就说不剩什么正经问题了，你的这些意见我都听到了，该说的都说了，我们投票表决。最终 HoraeDB 以 13 票有效赞成票，1 票其他赞成票“全票通过”。Justin 没有投票。蚂蚁集团的运营也好险能继续沿用“全票通过！”的标题。

最后复述一遍，我写这篇文章是为了阐明 ASF 同侪社群的理念和工作方式，以减少项目在面临不合理的挑战时遭受的挫败，尤其是当它来自于某个看起来权威的成员时。

随着 Apache 软件基金会（ASF）在国内的深入发展，越来越多的项目希望藉由进入 ASF 孵化器孵化，来建设开源社群。在进入孵化器之前，项目发起人或其核心团队必须撰写一份孵化器提案来介绍项目的基本情况，以供孵化器项目管理委员会（Incubator Project Management Committee, IPMC）评估是否适合孵化。

ASF 孵化器成立于 2002 年，至今已有超过 20 年历史。截至本文写作时，孵化器一共孵化了 347 个项目，其中 241 个项目已毕业，28 个项目正在孵化中。

ASF 孵化器的官网有丰富的文档介绍如何进入孵化器以及按照 The Apache Way 建设开源社群。对于孵化项目而言，最核心的两份文档是：

• A Guide To Proposal Creation
• The Apache Incubator Cookbook

此外，进入孵化器前需要撰写的提案，孵化器也提供了相应的模板，过往的孵化提案都是公开可查的，这也是撰写孵化提案时的重要参考。ALC Beijing 整理翻译了这份材料，可以阅读其发布文章《ASF 新孵化项目提案指导》。

本文从我至今指导孵化五六个项目的经历出发，讨论项目在进入孵化器前撰写提案时经常遇到的问题以及应对方法。

找到一位领路人

提交孵化器提案时，需要一位 IPMC 成员担任该提案的领路人（Champion），其职责主要是作为项目和 ASF 的沟通桥梁，帮助项目进行一些基本的自我评估，并完成孵化提案的评审工作。同样，ALC Beijing 整理翻译了一份材料《Apache 孵化器领路人与导师的职责》做详细介绍。

除了我指导孵化的第一个项目 Kvrocks 是陈亮担任领路人，以及思否捐赠的 Answer 项目是姜宁担任领路人，其他我指导孵化的四个项目都是由我担任这个角色，并帮助项目完成提案撰写和通过孵化器评审。

虽然从流程上说，领路人的职责在项目顺利进入孵化器后就结束，但是许多项目的领路人都会稍后仍然担任项目的导师（Mentor）。毕竟愿意在项目成员还很不了解 ASF 的文化和工作模式的时候，予以指导并帮助项目顺利加入孵化器，需要付出不小的努力。如果不是对项目本身的认同，是很难做这样的投入的。既然如此，那么参与后续孵化，帮助项目进一步建设发展社群，从孵化器中毕业，也就顺理成章。

因此，找到一位领路人不仅是项目进入孵化器时流程上必要的条件，实际上也是找到一位当前在任的 ASF 孵化器导师，愿意支持项目整个孵化过程的发展。

随着 ASF 在国内蓬勃发展，这几年来，进入 ASF 孵化器的源自中国的项目数量可观，我也能看到有许多富有经验的导师和新锐进取的导师在帮助项目孵化。不过，以我现在指导的项目数量来说，我应该很难再支持一个新的项目进入孵化。或许等到现在指导孵化的四五个项目（Kvrocks 已经毕业，OpenDAL 接近毕业）减少到一两个，我还能有多一些时间。国内有作为孵化项目导师意愿的 IPMC 成员我知道一些，但是不合适在这里罗列。如果有想要寻找领路人加入 ASF 孵化的项目，可以跟我联系或者找到 ALC Beijing 或 ALC Shenzhen 等组织询问。

第一大原则：真诚

我所指导孵化的六个项目，它们撰写的提案没有第一次就能通过导师自检的。其中最主要的两个问题，一个是英语技能不熟练，另一个就是不够真诚。

原本我想在这写的原则是“诚实”，因为有部分提案编造项目现状尤其是成员多样性和活跃度。这种问题项目导师和后续参与审议的 IPMC 成员稍微查证一下就会暴露，如果在提案正式讨论时才被公开挑战，那么提案通过的概率就非常渺茫了。

不过，“诚实”到底是一个相对客观的标准。很多情况下，项目团队还不至于直接撒谎。然而，如果用“真诚”这样一个相对主观的标准来界定，那么刻意隐瞒、夸大、春秋笔法之类的问题就能囊括其中了。实际评审过程中，不够真诚往往也是很大的挑战。

所谓真诚，意味着明确阐述项目定位，如实披露项目及其社群目前的状况，以及说明加入孵化器的目的和计划。在此之上，知道评议项目提案的人大都是 IPMC 成员，即潜在的孵化器导师，知道 ASF 孵化器的目的是以 The Apache Way 帮助项目发展开源社群，就能够比较好的确定如何写好这个提案。

例如，一个典型的问题是在提案中填充市场材料。这尤其常见于企业团队捐赠的项目，毕竟企业团队在做内部报告和外部宣传时，标配就是一份 PPT 和一系列营销材料。

某项目的孵化提案草案中，几次三番提到捐赠项目的企业建设了中国最大的某品类平台。诚然，首次提及时补充相关信息无可非议，但是原本就不长的的提案里每屏都会出现一到两处提及此事的长难句，属实有点难绷。

某项目的孵化提案草案中，罗列了项目荣获各种开源奖项，希望以此说明项目如何的好。可惜这些开源奖项本身的认可度极低，很多时候是拿着奖项找人领奖。同时其知名度也极低，放在特定环境下或许还有人关注，但是到了 IPMC 成员的审议里，只会认为项目团队是否只是注重虚名。实际上，在提案中需要回答的问题有一条，就是项目需要解释自己的捐赠行为是否只是“对 Apache 品牌的过度迷恋”。

在我的认知中，往往是对社群本身的发展和软件的价值没什么可说的项目，才会期望以填充市场材料的方式来蒙混过关。相反，真正值得展示已有社群规模的项目，通常寥寥数语就能勾勒其形状，IPMC 成员也知道如何求证。

例如，Seata 是阿里巴巴集团和蚂蚁集团共同开发的开源项目，多年以来独立发展得也很好。由于一些原因两家公司希望将 Seata 捐赠到 ASF 当中以在中立的平台和品牌下继续对 Seata 项目做投入。Seata 项目是这样描述其社群的：

Seata is being developed by the development team inside Alibaba who’s responsible for building internal distributed system too. Since Seata was open-sourced on GitHub, it has gained significant traction, receiving up to 24k stars, being forked over 8k times, and having more than 40 versions released. Besides being widely adopted inside Alibaba and Ant Group, Seata is also widely adopted by hundreds of other companies, including … For more information, please click here. We aim to expand the contributor by inviting all those who make valuable contributions and excel in adhering to The Apache Way. The Seata project and its side projects always accept contributions from individuals outside of Alibaba.

因为它确实有人用，所以展示自己的时候才有的放矢。

当然，并非所有项目都像 Seata 一样经过多年的运作。Fury 是蚂蚁集团今年七月份开源的另一个项目，起初项目团队也犯了难，为了让项目看起来勃勃生机万物竞发，把钉钉群的人数也写进去，还把一些未来可能可以做的事情当做已经做完的事情来表述，显得项目似乎得到了广泛的采用。

我首先要求把提及群聊人数的内容给删掉，因为这个大家都知道是怎么回事，背靠大公司或者经过一定的宣传，拉出几个五百人微信群或几千人钉钉群并不是难事，然而其中到底有多少价值，至少不是按群聊人数来衡量的。

此外，我告诉项目团队，Fury 项目的优点是定位清晰，社群用户反馈积极，可以着重突出这一部分。对于未来能做的事情，只要定位说清楚了，再辅以几个确实做过的集成，认真审议的人是能 Get 到的。社群用户反馈积极，则是项目作者杨朝坤在开源的小半年时间里，积极在 Reddit 和 HackerNews 上宣传项目，由于 Fury 作为序列化方案的定位简单易懂，用于替换 Kyro 和 Protobuf 的一些场景下优势明显，所以有不少用户确实公开表示了对项目的兴趣。

最终，我们把 Fury 实际的几个用例做了一点展开来体现项目的价值和其合作的前景：

Currently, Fury has a group of individual users, and organizations such as Alibaba/Vipshop are Fury users, too. Here are some of Fury’s use cases:

• Ant Ray uses Fury for serialization at 100W+ CPU cores every day at Ant Group.
• Ant Mars replaced its serialization with Fury, which sped up task scheduling TPS by 2.5X and 4X for data transfer.
• Ant real-time-graph computing systems replaced Kryo with Fury to speed graph serialization.
• A few companies replaced Kryo with Fury in Flink jobs for faster data transfer and state persistence.
• Lindorm at Aliyun uses Fury for serialization between clients and servers.
• Taobao Android app, which has 880 million monthly active users, is considering using Fury for IPC serialization between Android processes.
• Vipshop replaced Protobuf with Fury, reducing the end-to-end latency by 30ms.

可以看到，由于开源时间不长，大部分的使用场景仍然在蚂蚁集团内，但这就是实情，而且本身技术场景是多样的。我们没必要编造说因为钉钉群有好几千人，所以或许大概可能这里面对应的几百家企业也在尝试将 Fury 用在生产环境。也许这个逻辑听起来很离谱，但是真的有孵化草案一开始就像这样写的。

这里引出第二个问题，真诚意味着对项目当前的风险如实披露。

例如，Fury 项目开源不久，核心开发者确实只有两个人，而且都是在蚂蚁集团的员工。虽然有过提交的人有几十人，但是显然大家一看 commit 数，时间和内容就清楚怎么回事了。好在前期讨论捐赠的时候，项目引起了 Kvrocks PMC 成员刘明阳（@PragmaTwice）的注意，在提案审议时，项目有三个开发者做出了 non-trivial 的贡献。此外，我为项目找到的另一位导师 PJ Fanning 是 Jackson 的开发者，他也看好 Fury 并改进了 Scala 实现的一些小问题。我也看好 Fury 项目并做了一些微小的改进。最终 Fury 提案是这样表述其开发者团队的：

Currently, Fury has only three core developers, but they are not homogenous: although Chaokun and Weipeng work at the same company, they know each other only due to their common interest in Fury. Mingyang Liu joined the Fury community recently, and he mainly contributed to C++ part of Fury.
We don’t have enough diversity for now. It’s a risk, although we’re optimistic about future developer diversity. Since Fury is open-source, we have attracted more than 20 developers to contribute. We will keep building community diversity following The Apache Way.

在早期商议的时候，其他导师对这一点也提出了担忧。我想到了 OpenDAL 捐赠时也只有 4 个初始成员，且他们都来自 DatafuseLabs 公司，所以我补充了一个评论来自己挑明这个风险和我的判断：

tison’s comment: Although only three initial committers are listed above, PJ (who contributes to Jackson also) and I, as mentors, would participate in the development. Also, another podling that I mentored, named OpenDAL, has four initial committers but so far invited nine (days before its tenth) committers and two PPMC members, done eight (now during its ninth) releases. From my experience with Fury’s initial committers, I saw several shared characteristics with OpenDAL’s members. So, I’d invest efforts to help this project grow within the ASF Incubator.

Hudi 项目到今天也有相当多样的参与者了。然而它起初也只是 Uber 内部的一个方案，在几个合作伙伴间有共享。这就类似蚂蚁集团开发的 Fury 在阿里巴巴集团和唯品会内也有一些采用。Hudi 是这样写关于同质化开发者的风险的：

Currently, the lead developers for Hudi are from Uber. However, we have an active set of early contributors/collaborators from Shopify, DoubleVerify and Vungle, that we hope will increase the diversity going forward. Once again, a primary motivation for incubation is to facilitate this in the Apache way.

这里非常有趣的一句话是，加入 ASF 孵化器的动机之一就是为了发展一个多样的社群。

这体现了撰写孵化器提案的时候另一个常被误解的问题，那就是你并不是来证明说你的项目已经非常好，解决了所有的问题。如果这样，那还要孵化啥呢，直接作为顶级项目运作就好了（这并不是玩笑，实际上已有先例）。或许由于我们总是从一个成功走向另一个成功，我们很少能够坦率的展示项目目前面临的挑战，要么是好的，要么正在往好的方向发展。但是其实 IPMC 并不介意项目有些地方目前还并不跟 ASF 的文化理念和顶级项目的标准对齐，不真诚导致 IPMC 对项目产生信任危机，才是更大的风险。

两个主要段落：现状与风险

我第一次作为孵化项目的领路人，是在 OpenDAL 项目上。当时我误以为孵化提案应该是领路人负责起草的，只是需要项目团队支持补充一些信息。但是，当我实际开始试着写提案的时候，我就发现这个提案的定位就是项目团队的一个自我介绍和自我剖析的。

整个提案大致可以分为两到三个部分：

1. Abstract 和 Rationale 等前几部分是对项目本身的介绍，项目到底是干嘛的，用在什么场景，相比其他方案有什么差异。这个问题只有核心开发团队才能回答。Initial Goals 是项目捐赠的动机和捐赠后的初步工作，这个也只有核心团队心里才有答案。这部分可以算是简答题。
2. Current Status 和 Known Risks 也即现状和风险，是几个具体的问题，需要项目披露当前的社群状况和回答一些常见风险的挑战。这部分可以算是问答题。
3. 此外的内容可以算是填空题，包括源代码的地址，文档的地址，依赖项及其软件协议，捐赠后所需要的资源和初始团队的成员等等。

填空题写起来是比较标准的，简答题除了大规模加塞市场材料突显自己多么 NB 的问题以外通常也不会遇到什么问题，主要出现夸大、掩盖的地方，就是关于现状与风险的问答题。所以我会说它们是一份提案的主要段落。

现状披露分为以下几个方面：

• Meritocracy
• Community
• Core Developers
• Alignment

Alignment 比较简单，就是说一下跟其他 ASF 项目的联系，没有就不说了，通常没什么问题。是的，提案模板只是一个模板，如果没什么好说的，可以不写。

主要出问题的就是前三项，为了证明社群不只是捐赠方一家在参与，有很多人在用，草案里 Community 的 Core Developers 里凑数夸大的情况非常严重。关于 Meritocracy 就更整蛊了，很多时候项目开源不久或者就是一两家公司的员工在维护，雇佣关系决定提交权限，非要编出多么的开放，甚至为此把一些新来的 Contributor 临时提成 Committer 指着说这就是 Meritocracy 了。

实际上 Meritocracy 并不是多样性的意思，而是任人唯贤，对比的是仅由雇佣关系授予和回收权限的方式。把一个没做什么贡献的人提名成 Committer 反而是违反这一条的。

对 Meritocracy 的回答，其实只要表示出理解它是什么含义就行。当然如果确实已经按照这样在运行了，举出例子是最好的。

风险评估分为以下几个问题：

• Project Name
• Orphaned Products
• Inexperience with Open Source
• Length of Incubation
• Homogenous Developers
• Reliance on Salaried Developers
• Relationships with Other Apache Products
• A Excessive Fascination with the Apache Brand

如前所述，下意识的规避项目存在的问题，是不真诚的主要诱因。

Project Name 通常没什么问题，只要做好自检就行。如果要改名或者发现跟其他项目名称冲突，则最好在提案前就完成改名，避免提案对名称产生疑问。Ignite 和 Seatunnel 在捐赠前都改过名字，HoraeDB 也有相似的经历。这里如果没有说清楚改名的缘由，IPMC 评估时发现存在品牌问题，是会有比较大的挑战的。品牌和合规问题是 ASF 当中的红线。

展开说一下，Seatunnel 的原名 Waterdrop 已经被其他组织注册，为了避免品牌问题不得不改名。Ignite 原本是 GridGain 公司的一个项目，其名称 GridGain In-Memory Computing Platform 跟公司名相同，同时作为独立项目也过长。因此实际上 GridGain 可以认为是把 GridGain In-Memory Computing Platform 的核心代码，以 Ignite 的名字捐赠出来。

HoraeDB 情况和 Ignite 类型，是蚂蚁集团的 CeresDB 产品核心代码，用 HoraeDB 的名字捐赠给 ASF 孵化器。然而，由于技术上需要修改代码中对 ceres 文本做替换，我在指导项目撰写提案的时候使用了 rename 一次来表达这个操作。实际评议提案时，技术上的名称替换做了一小部分，rename 的用词导致某些 IPMC 成员对 CeresDB 和 HoraeDB 的关系产生了误会，由此引发了不必要的一系列争论。

Orphaned Products 主要可能的风险有两种，一个是个人开发者捐赠的项目，如果人数很少，一旦开发者转移兴趣，项目可能就死了。另一个是公司捐赠的项目，如果没有 solid 的用例，可能公司一转向，项目也就死了。

如果项目开发者足够多样，有很多用户从中获益，这自然没问题。但是如果人并不多，IPMC 就需要评估项目的定位和未来发展的可能性。例如 Fury 未来长出一个社群的风险并不高，替换逻辑也清晰，不会因为项目没有用而废弃。相反的例子是 Tuweni 作为 Java 作成的区块链工具，虽然也进入了孵化，但是很快就因为没什么人感兴趣，作者自己也觉得没指望而放弃。

如果是公司项目，很多时候公司项目总要打包票说未来可期大大的投入，所以在 IPMC 这关通常也不好挑战。但是对于导师们来说，就要评估这个项目到底有没有足够的高层支持和内外用例。因为公司改主意经常比个人开发者转移兴趣或 burnout 来的快，除非有什么外力牵引，否则项目组换方向或者原地解散，这项目就死定了。对于导师来说，投入帮助项目孵化和成长的努力也就打了水漂。

类似的例子比如 Hotonworks 的 Ambari 项目，在公司被 Cloudera 收购后，项目跟 CDH 冲突，也就停摆了。但是换个角度看，由于 Ambari 仍然有其价值，所以在归档一年后，又有人出来复活这个项目继续运作。可惜的是由于一些其他原因，这次复活后的运作也不顺利。

另一个例子是同样来自 Hotonworks 的 Livy 项目，由于类似的原因停摆。然而在其从孵化器中退休前，有的用户已经上船并在生产环境使用，所以他们自告奋勇来维护这个项目，至少保持能够修复 BUG 和安全漏洞的情况。

Inexperience with Open Source 这个也是经常容易不真诚的地方。

从我的经验来看，大部分想要进入孵化器的项目，往往在社群建设上还有很大的欠缺。如果一个项目已经建立起了完善的社群，例如 ApolloConfig 和 Nacos 这样的，它们很少会想到要捐赠给 ASF 谋求进一步发展。因此，如实披露项目成员在开源方面的经验即可。

反面例子是一些草案在披露是添油加醋故意夸大，说是有某个成员四五年前在某个知名不知名的开源项目里提交过补丁，这就算是不会 Inexperience with Open Source 了。这就像是在建立上放一个 fix typo 的 PR 链接，然后说自己深入参与开源项目开发一样。

Length of Incubation 标准答案是 2 个月进入孵化器，2 年内孵化毕业：

Expect to enter incubation in two months and graduate in about two years.

这个在提案时基本不会被挑战，不过背后是孵化器运作的部分逻辑，即孵化项目是要奔着毕业去的，如果长时间不能毕业，可能会面临被要求退休的风险。历史上退休的孵化项目一共有 78 个，除了项目自己放弃以外，IPMC 会定期评估孵化时间过长的项目，并需要项目对风险做出回应。如果没有回应或确实状况很不健康，可能由 IPMC 出面将其退休。

Homogenous Developers 同质化开发者，即项目核心团队的多样性。这个在前面讨论真诚的时候已经介绍过很多。人的兴趣会转移，精力会消磨，公司的注意力转移得更快。如果项目本身不能凭借自己的价值吸引到足够多样的开发者，那么其失败的风险是极高的。

Reliance on Salaried Developers 这点跟同质化开发者有相似之处，不过其实并不一定是坏事。Flink 的开发如果不是拿钱，一个纯粹的志愿者是很难撑起社群的需要的。所以关于这个问题，我认为要么是不依赖，表达出项目核心团队对技术本身的追求和认同，要么是确实就是一直有钱雇佣开发者做这个项目，都没有问题。同样这里容易产生一些不真诚的地方，明明就是一群拿钱办事的人，编造出自己没钱也会做的谎言就显得很可笑。

HoraeDB 的提案里并没有回避这个问题：

We acknowledge that most developers are supported by their employers to contribute to HoraeDB, which poses a significant risk. However, HoraeDB has already been extensively deployed within Ant Group, with no internal forked versions. The version available on GitHub is the actual production version used in practice. As a result, Ant Group can ensure long-term commitment. We believe that within this timeframe, we can attract more maintainers and developers from diverse backgrounds to address this risk.

作为对比，Fury 的作者独立开发这个项目两年多，他有底气说自己就是会做这项技术，而不只是因为被雇佣做这件事：

Although Fury is created at work time in Ant Group, Chaokun and Weipeng contribute to Fury in their spare time. They love the process of building such a versatile framework and the value it brings to all users and organizations. They will continue to work on Fury even if they leave their current cooperation, and Mingyang Liu also contributes to Fury in his spare time. We plan to attract more committers to address this risk.

Relationships with Other Apache Products 如实回复即可。

A Excessive Fascination with the Apache Brand 这个问题是整个提案模板里最容易被误会的一条，反应了我一开始说的撰写提案时最主要的两个问题，第一个是英语技能不熟练。

这个问题的意思是，项目是否只是“对 Apache 品牌的过度迷恋”而捐赠，而不是孵化器关注的按照 The Apache Way 建设社群。换句话说，是不是只想借 Apache 的品牌做营销。不少草案写作时不知为何理解成要表达对 Apache 品牌的认可，洋洋洒洒写了一堆说 Apache 品牌是如何如何的好，完全是背道而驰。

当然，你说想要捐赠到 ASF 的项目团队不认同 Apache 品牌，这也不可能。可以参考 Kvrocks 提案的写法：

Although we expect that the Apache brand may help attract more contributors, our interest in starting this project is based on the factors mentioned in the fundamentals section. We are interested in joining ASF to increase our connections in the open-source world. Based on extensive collaboration, it is possible to build a community of developers and committers that live longer than the founder.

其他琐碎的问题

第一个，前面已经说过，这里再提出来强调，孵化器提供的模板只是个模板，不一定要完全按照它的格式来写，不知道写啥的可以留空或者询问领路人。

第二个，填空题的标准答案可以看 Fury 提案。一般来说需要三个邮件列表：

• private 用于讨论不适合公开的内容，例如安全问题的处理，涉及具体人的讨论，例如提名新 Committer 或某人行为不端等。
• dev 用于项目开发的讨论。以往还会有一个 users 来回答用户问题，但是现在大部分用户习惯开 Issue 或者 Discussion 聊，除非有明确需求，否则复用 dev 已经足够。
• commits 用于归档项目开发产生的信息。这个主要是 The Apache Way 约定所有开发活动都要在邮件列表上留痕，ASF 会维护邮件服务器和保存所有邮件，这保证 ASF 项目的所有信息资产不会依赖外部系统。

Git 仓库现在基本都是 GitHub 上的迁移，不过 ASF 实际上有自己的 GitBox 做同步来确保不依赖外部系统。

Issue Tracker 大部分新项目都用了 GitHub 的 Issue 功能，老项目很多还使用 ASF 自建的 JIRA 平台。同样这些活动会被同步到邮件列表上，确保信息保存不依赖外部系统。

Initial Committers 的人选要仔细，这个也是经常被挑战的问题之一。在这个问题上，倒是可以多考虑 Meritocracy 的问题，同时不要设置过高的门槛但也不要为了凑人数而把没有什么实质性参与的 Contributor 强行提上来。最后，小心不要把没有参加项目实际工作的公司老板安排进来，这个如果被公开挑战会很难回应，因为跟 ASF 的文化完全格格不入。

Sponsoring Entity 捐赠给孵化器就写孵化器，Sponsors 需要注意领路人（Champion）只负责项目进入孵化器的过程，所以如果他想要继续担任项目导师，在导师一栏里要重复提名。

最后一个，依赖项的协议要认真看，从别处抄来的源代码要保留原先的文件协议头信息。合规和品牌问题是 ASF 的红线，IPMC 里有些人会特别仔细的看这些问题的。关于 ASF 项目如何看待依赖项协议是否合规，可以参考这份材料。

注意有不符合 ASF 合规要求的依赖，只要写清楚了而且有后续修复方案，并不需要在进入孵化器前就一定解决。ASF 对孵化项目的 endorsement 其实是有限的，它会要求孵化项目发布时必须带 incuabting 字样和带有一份 DISCLAIMER 文件，来表示孵化项目并不一定完全符合 ASF 承诺的软件标准。

参考案例

• Fury
• HoraeDB
• Hudi
• Ignite
• Kvrocks
• OpenDAL
• Seata
• StreamPark

上一篇文章《Rust 社群何以走到今天？》发布之后，得益于 Rust 社群的繁荣和成员的分享惯例，我收到了不少关于 Rust 现状的评论。

大部分评论集中在 Rust 项目社群的治理上，即 BDFL 和基金会会对 Rust 项目社群产生什么影响，以及 Rust 项目社群是否需要 Leadership 组织。

我在上一篇文章中引用了 Graydon Hoare 和 @withoutboats 等人的博文，展示了“遗老”们对 Rust 项目社群目前的一些看法，这不免让人理解成赞同他们的观点，希望 Rust 社群出现一个强有力的领导人，甚至希望 Rust 语言像 Graydon 设计的那样演进。

其实，上一篇文章主要想说明的只有两个观点：

1. Rust 项目社群治理的核心特点是没有一个人（BDFL）或一个一致行动的团体（Apache Group）说了算。
2. Rust 项目社群未来的发展会极大受到各大公司组成的基金会的影响。

我并不认为有 BDFL 就一定是好事或是必须，至少我所在的每个 Apache 项目社群中都不存在 BDFL 角色，它们也发展得很好。

而且，以 Rust 项目社群如今的状况而言，几乎不可能出现一个新的 BDFL 或者 Graydon “复辟”的情况。因为拥有《大教堂与集市》中提到的，由“开垦”新项目带来的自然所有权的人，绝大多数已经长期淡出 Rust 项目社群，其他少数几个人也无意于社群管理。对于新人来说，由于没有明确地所有权转让程序，想要赢得 BDFL 的地位，就需要依靠自己的贡献。而以 Rust 项目社群目前的领域范畴来说，这对个人几乎是一个不可能完成的任务。所以，Rust 没有 BDFL 将会是一个长期的现状。

进一步地，作为 Rust 项目最初的赞助者，Mozilla 甚至不在 Rust 基金会的白金或黄金赞助商名单上。这就意味着在公司影响力上，哪怕是 Rust 基金会的创始会员也没有天生的主导权。

从机制上来说，Rust 基金会目前并不参与 Rust 项目的开发，基金会的目的是提供 Rust 项目存续的资金支持，以及相应的人才培养和品牌宣传。

上一篇文章中提到的 Leadership Council 并不隶属于基金会，而是 Rust 项目社群的一个治理机构，其成员由各个 Rust 项目顶级团队组成，基本职责是协调跨团队合作以及针对 Rust 项目社群治理本身的一些问题。

在这之前，Rust 项目社群在基金会和 Leadership Council 的领域内发生过几起争议事件：

1. Ashley Williams 曾经是 Rust Core Team 的成员，同时是 Rust 基金会筹建时的执行董事，但是后来前后从这两个组织中出局。
2. Rust Moderation Team 因为跟 Core Team 的冲突，以集体辞职表达不满。如今，Core Team 本身被解散，而 Moderation Team 则由两位深度参与 Rust 核心开发的成员支撑。

Rust 社群的这些故事，除去缺少 Linus 这样的 BDFL 维持项目本身的有序运转之外，跟 Rust 社群总是期待一个两全的解法，以及过度期望所谓“专业人士”来解决问题的惯例是有关系的。

前者在 @withoutboats 的博文中有所提及：

我担心 Rust 项目从这个经验中得出了错误的教训。正如 Graydon 在这篇文章中提到的，Rust 开发团队坚持只要有足够的构思和头脑风暴，就能找到每个争议的双赢解决方案，而不是接受有时必须做出艰难决策的事实。Rust 开发团队提出的解决这种无休止的争议所带来的 burn out 的方式，是转向内部讨论。设计决策现在主要以 Zulip 线程和 HackMD 文档等未索引的格式进行记录。在公开表达设计方面，主要是在相关开发者的个人博客上发布。如果你是一个开发团队以外的人，那么你几乎不可能理解 Rust 开发团队认为什么是优先事项，以及这些事项的当前状态如何。

而后者则是一种社会高度分工以后常见的认识误区：其他人比我更专业，只要相信他们就好了；有其他人承担这项分工，我只要给予信任或者进一步给予金钱等利益，就可以完全把这些工作委托出去。

实际上，其他人未必有身临其境的人了解事情的原委沿革，不一定站在项目的立场考虑问题，甚至未必专业。对项目负责的人只能是深度参与的核心成员自己，这也是 Leadership Council 在成立动机中所提到的：

根据核心团队（Core Team）的经验，发现问题和开展实际工作本身，对于一个团队来说都太过繁重。这导致了不理想的结果，在某些情况下，还导致了倦怠。虽然有少量工作需要立即采取紧急行动，但绝大多数工作都需要由专门的管理机构进行跟踪和处理。

此前的 Core Team 和 Moderation Team 不仅相互之间缺乏沟通，甚至本身成员也相对独立于其他顶级团队，这导致本应作为协同社群反馈和各个顶级团队之间合作的两个独立团队，跟其他顶级团队之间也可能缺乏互信基础和合作机制。新的 Leadership Council 成立并以九个顶级团队代表为成员，期望在维持先前 Core Team 所要解决的问题的基础上，提高团队之间的协同效率。

对于基金会，可以明显的看到在机制上它相当于 Linux Foundation 之于 Linux 或是 Python Foundation 之于 Python 的形式，前两者在运行过程中间并未出现如同 Rust 社群这样的戏剧性发展。其原因部分在于它们有一锤定音的 BDFL 主导技术开发和项目团队合作，另一方面也是在这样长期的运作方式下，项目团队成员发展出一套自己解决问题的办法，而不是被不满意的现状困扰，转而祈求外部力量奇迹般的解决问题。

Rust Foundation 的性质是 501(c)6 行业联盟，这跟 Linux Foundation 是一致的，它们存在的目的除了写下来的维持 Rust 的存续发展，从性质上说是要为商业联盟中的成员企业服务的。相反，Python Foundation 和 Perl Foundation 的性质是与 Apache Software Foundation 相同的 501(c)3 慈善组织，纯粹是为项目本身的发展和公众利益服务。与此相匹配地，就是慈善机构型基金会往往在募集资金上不如商业联盟型基金会。

如前所述，由于 Mozilla 无法或不愿入局，如今 Rust Foundation 的四个创始会员分别是 AWS、谷歌、华为和微软。它们并没有像 Oracle 在 JCP 执行委员会中那样继承自 Sum 并再次发展得到的垄断权，甚至 Rust Foundation 本身也没有 JCP 那样直接指导语言项目技术发展方向的权限。但是，既然 Core Team 可以改组，Rust 社群整体对于基金会干涉项目发展存有期望，那么在未来社群治理的发展或者至少每次讨论当中，基金会就有可能发挥出自己的影响力。

当然，现在的主要问题恐怕不是担心基金会如何“窃取” Rust 项目的领导权，而是期望基金会的创始会员和其他赞助商先加大投入，哪怕就是奔着主导权来的，至少先把 Rust 的产业应用和语言发展，投入资源搞起来。但这是另一个话题了。

在基金会之外的另一个角度，也有人在呼唤唯一有可能成为 BDFL 的 Graydon 加入战局“拯救” Rust 项目社群。如前所述，由于 Graydon 本人已经淡出 Rust 社群很久，这实际上是几乎不可能的。

Graydon 本人对此的认识倒是比较清晰，他先后写下两篇博文对此做出回应：

• Batten Down Fix Later
• The Rust I Wanted Had No Future

其中第二篇已经在我的上一篇文章里展开介绍过，下面我会翻译第一篇。

译文之前说一点题外话。

Graydon 在第二篇博文里提出的对 Rust 的期待，在我上一篇文章发布后收到了推特上网友的讽刺。从 Graydon 本人列举出来的设计方向看，除了错误处理他更喜欢 Swift 的做法，其他的诸如绿色线程、语言级别集成的容器和迭代器、结构化类型等等，确实都是 Golang 的招牌特性。可以说，Graydon “在位”的话，Rust 恐怕就会发展成弱化的 Golang 而不是今天的 Rust 了。

另外，虽然试图“拥立” Graydon 重回 Rust 项目社群的呼声是不理智的，但是这些呼声的存在，侧面印证了前文提到的 Rust 项目社群总是期待两全解法，并总是寄希望于未知的专业人士神奇的解决问题的惯例。

Rust 项目如何走出当前的境况，我参与得不多无法给出意见。不过，我倒是乐意从开源社群发展的研究角度，来分析 Graydon 这样在卸任之后还持续思考和发生的例子：这确实是不可多得的考察对象。

在不能持续维护项目的作者里，Graydon 的案例非常有参考性。他思考了很多，也分享了很多。但是他没有“成功”。这比那些被“成功”掩盖了问题的例子，还有简单一句 burn out 解释所有问题的例子要有意思的多。

以下 Batten Down Fix Later 译文，“我”指的是 Graydon Hoare 本人。

在社交网站上，有人问我：“你是否希望自己是 Rust 项目的 BDFL？如果 Rust 项目有一个 BDFL，现在这些戏剧性事件会不会少一些？”

这是一个很难回答的问题。如果只看它表面的提问，我的答案是“不希望”和“不会”。但我认为它还间接地问了另一个问题，即 Rust 项目社群治理中是否存在某种原罪，或是致命缺陷，例如缺少 BDFL 的角色，而这正是其频繁发生内部政治问题的罪魁祸首？

关于这个问题，我可以分享一些我的观点，希望能简明扼要，或者至少具体一点。我认为有几个根本原因和一个主要的模式。

主要模式

我已经有十年没有参与这个项目了，所以我认为我说的任何话都需要谨慎对待。但我确实时不时地关注 Rust 项目的进展：这些年来，有不少人离开了这个项目，而且其中许多人的离开是不愉快的。很多人对参与这个项目感到后悔和怨恨。这令人悲伤。

我认为这些事情通常是这样发展的：

1. 项目内部存在冲突。
2. 这个冲突没有得到很好的管理或解决，至少没有以专业或健康的方式处理。
3. 冲突并没有消失；相反，它以某种不专业或不健康的方式被表现出来：有时是一次性爆发，但更常见的是长期存在。
4. 可能在经历了第三阶段的一段时间后，冲突的一方就离开了项目，而所有人都试图假装冲突从未发生过。

这里所谓的不专业或不健康的处理方式，我至少见过四种具体的形式：

1. 利用非常规的力量：压力、社交影响力、小圈子。
2. 利用外部正式权力：找某人的上司。
3. 利用内部正式权力：与管理员进行交涉。
4. 通过花费时间争论消耗对手的精力。

离开阶段常常显得有点突然，因为其原因不透明，并且也有几种不同的形式，通常对应到上述处理的模式：

1. 因厌恶甚至为表抗议而辞职。
2. 上司处理或解雇。
3. 管理员处理或封禁。
4. 由于精疲力竭或倦怠而退出。

理解模式

所有这些阶段都有可以理解的缘由。我不是说它们是“好”的，但可以理解。我理解它们是如何发生的，甚至可能对形成这些模式起过推波助澜的作用。

以下是一些背景事实，有助于理解为什么会出现上面这些模式：

第一，很多人只是习惯性地避免冲突。这可能是由于成长背景、个人创伤经历、固有的天性或其他原因。我自己就是避免冲突的人！应对冲突是困难且疲惫的，尤其对于没有报酬的志愿者来说。避免冲突通常看起来更容易。冲突回避是一种为了当下舒服一点，将问题推迟至未来应对的方式。

第二，Rust 如今形成了一种非常高风险的品牌。它似乎非常不可思议，经常吸引大量的互联网关注。它一度似乎被普遍崇拜，又被普遍憎恨。它感觉随时可能失败，但又感觉总是处于胜利的边缘。这在许多人中产生了一种自卫心理，我相信助长了这种心态的蔓延（我是一个焦虑的偏执狂），我确信这种心态是让许多人全身心地投入其中的原因之一。这可能是有趣和令人满足的，但对于许多人来说，它变得更重要。这些人为了参与 Rust 相关的事业付出了全部，将自己的职业或目标感、身份投入其中。自己的工作和未来往往岌岌可危！而且很多人也因过度工作、过度努力而真正精疲力竭。那些没有精疲力竭的人往往保留着一种内在的承诺，这使得缓和冲突变得困难，妥协变得困难，甚至公开承认问题也变得困难。

第三，Rust 最奇怪的文化规范之一（我可能有助于形成它，如果是这样，我向你道歉），是许多人都相信所有的冲突都是“虚假的权衡需求”，即冲突显示需要权衡的地方，都可以像 Rust 声称解决速度与安全之间的权衡问题那样，不用权衡地取得双赢。所有事情都可以实现双赢，如果你找不到这样的解决方案，那就是你没有努力尝试。我的意思是，如果真的能双赢，那当然很好，但是有时事情只能在合理的权衡甚至一定的冲突中形成决定！有些事情是零和博弈的。

第四，Rust 项目社群在管理或解决冲突方面没什么正式机构，考虑到 Rust 项目社群的规模，这个问题尤为突出。Rust 项目社群是互联网上的志愿者构建的，并在一个自身没有强大的正式架构的组织中孵化（Mozilla）。我推荐你阅读《无架构的暴政》这篇文章。Rust 项目社群中只存在着非正式的架构，或者执行严格的最终手段的正式架构，例如 moderators 或者外部干涉。

最后，这些非正式架构当中，有一种普遍存在于 Rust 和许多开源项目当中，这就是时间承诺的规范。《无架构的暴政》中也提到了这一点。热情的贡献者通常愿意并且有能力在项目上投入大量时间。然而，并不是所有人都能够遵守这种时间承诺。付出时间往往被明确激励：“真正做事的人有权做决策”。但是，这些决策往往会影响到许多其他的利益相关者，而“拥有最多时间的人”可能无法很好地代表这些利益相关者，或者可能缺乏完成这项任务所需的技能或知识。而“比其他人花更多时间”的做法也是一种相当不健康的处理冲突的方式：与其直接面对冲突，不如跟对方比拼时间投入，互相消耗精力。即使在正式架构内部，如果有“每单位时间贡献多少输入”的余地，这种做法也可以被采用。有些人会出现在每个会议上，推动相同的议程。这种做法行之有效，你能够按照自己的方式推进事情，但从社群角度上看，这并不是最好的方案。

修复问题

我真的不知道如何解决这些问题。如果我知道，我肯定会提出建议。我之前说过，我对助长一些模式感到相当负责。不过当然，过去的已经过去了。对项目来说，最重要的是未来。

我想我的主要建议是一个“不要听我的建议”的建议：“雇佣并听取那些在相关领域接受过培训的专业人士”的建议，其中“相关领域”涵盖了“一群编译器极客们”通常不擅长的一切。从项目管理到政治科学、金融、传媒、调解、人事管理。Rust 项目现在是一个相当大，而且非常分散的组织，人们长期以来一直在研究如何运行这类组织，甚至不同的专家研究其中不同的细分领域。应当听取他们的意见，而不是试图从某个第一性原则开始解决每个问题，也不要假装因为你们是一群互联网上的编译器极客就可以回避一个正常组织的所有机制。

我不知道新的治理体系在多大程度上具有这些专业人士的痕迹，也不知道它是否会在很大程度上解决上面提到的问题模式，但我可能会对结果感到惊讶。我在这些领域没有专业技能！如果一定要说，我喜欢“权力明确划分”、“任期限制”和“角色轮换以避免倦怠”这样的概念，以及透明决策；我喜欢设置某种利益相关者的代表和限制时间投入的机制。

我不知道社群是否承认现实中存在冲突，以及是否必须明确解决冲突。我不知道当前的治理模式和治理机构，在使项目中的权力职位，包括非正式的权力职位，对其行为负责方面，或在公开宣传以树立信心方面，是否做得足够。最主要的是：我不知道现在的治理模式，是否能够让那些不想全身心投入项目的人过上舒适的生活。

就我个人而言，我根本没有足够的精力，这一切对我来说都太沉重了。对于那些参与其中的人，我祝你们一切顺利。祝好运。

追加讨论：基金会

我想明确一点：据我所知，Rust 项目社群中的治理问题并不是 Rust 基金会导致的。每当社群中发生一些争议，总有一群人会把矛头指向基金会，这通常是错误的。

再次强调，我只是一个从旁观者的角度观察和倾听的外人。基金会通常似乎是房间里的成年人，当它做出一些表面上看起来奇怪的举动时，通常是因为它试图解决项目交给它的一些不可能解决的困境。

我认为基金会实际上只是想支持这个项目的存续，而 Rust 项目一直不是一个很容易支持的对象。

追加讨论：企业赞助商

此外，虽然 Rust 项目在一定程度上是由志愿者推动的，但它也在一定程度上是由企业赞助的，并且不仅是基金会成员的赞助。尽管有时我认为企业赞助会对维护者产生不良影响，导致维护者没有动力做那些琐碎的维护工作，但我认为 Rust 不会出现人们最担心的情况：企业在冲突或不受欢迎的决策中“购买影响力”，或者以其他方式操纵这门语言的发展。

这是一个可能存在的问题，但基金会的架构在设计之初，就花费了很大的精力来最小化相关风险。到目前为止，我认为我们没有看到这种情况。

追加讨论：最初的问题（BDFL）

为了更加具体地解释本文开头的“不希望”和“不会”的回答：我不喜欢受到关注或压力，当我在 2009 年至 2013 年担任项目技术负责人时，我接近极限运作，我离开的一部分原因是达到了这些极限并且有些崩溃了（以及公司对我燃尽的事实的反应并不好：参见“每个人都是人”）。我在本文中描述的人性缺陷，在我身上同样存在！

此外，我没有理由相信我会建立起强大或健康的正式决策机制、冲突管理机制或委派和扩展机制。我没有受过有关这些主题的任何培训，我完全是在 Mozilla 的角色中凭直觉行事。Mozilla 本身似乎对这些主题也没什么经验。我曾经试图在 Rust 的设计上进行一次“正式决策”，我试图用投票结果确定关键词命名的选择，但是结果非常糟糕：每个人都讨厌结果。

追加讨论：Moderation

我不了解 Rust Moderation Team 的故事。我从 2013 年其就不在 Rust 项目社群中了，因此，我不希望对他们过去的行为做出任何的评价或暗示，尤其是今天的 Moderation Team 已经不是过去的那一个了。在我看来，这是一个需要知晓内幕的人在其他地方讨论的主题。我想说两件事：

1. 我写了最初的行为准则，且当时的行为准则更简短、更简单。我同意明确的社群规范和强制执行的能力通常是互联网社群所必须的。我不认为有管理员是一件坏事，也不认为管理员在谨慎和受监督的前提下行使权力是一件坏事。
2. 我承认版主也是人。他们可能自己违反行为准则，也可能在处理其他人的违反准则行为是不够诚实。我认为这通常很少见，抱怨这种可能性的人往往没有站得住脚的理由，不过这些情况确实可能存在。要求对管理者的行为进行更严格的审查来避免这种监守自盗的可能性也算合理。根据我的经验，大多数好的版主愿意记录他们的决策过程，并解释决策的理由。

追加讨论：小团体和缺乏透明度

拥有志同道合的朋友是很棒的！关起门来做事情，不必向网络上的陌生人解释你所思考或说的每一件小事也是很棒的！这些事情本身并没有问题。实际上，这通常是许多人感到安全、舒适和愿意参与的先决条件。成为一个被审视的公众人物往往令人筋疲力尽，并且可能会排除那些被天性或环境所限的人。但一定程度的透明度是做出对他人产生影响的负责任决策的必要部分，也是权力行使的一部分。