应当在 ASF 孵化器中帮助项目
由于 Apache 软件基金会（ASF）过去十年在国内的文化传播，许多开源软件的创作者都有一个将自己的软件捐赠到 ASF 并最终成为顶级项目的梦想。我所接触到的 Apache Fury / Apache OpenDAL / Apache StreamPark 都有这样的背景。
按照目前 ASF 的章程和惯例，开源项目要想成为 ASF 顶级项目，绝大多数情况下需要经过 ASF 孵化器孵化。
这个 ASF 孵化器本身是一个 ASF 的顶级项目，与其他项目一样由项目管理委员会指导，通常称为 IPMC 即孵化器（Incubator）项目管理委员会（Project Management Committee）。IPMC 成员规模应当是所有 ASF 项目中最多的，截至今天 IPMC 共有 285 人，项目 Committer 有 3927 人（所有新的孵化项目，孵化期间产生的 Committer 都会自动成为 Incubator Committer）。
本文主要分享我最近在孵化器邮件列表上发布的一封倡议，以及近期帮助孵化项目所做的一些工作。
首先放一下倡议原文，可以从 https://lists.apache.org/thread/h7tblpghtyhlsfolt14jnpylj1cygmxf 公开访问和进行回复。
这封倡议主要是面向 IPMC 成员也就是孵化器导师们的。但是，我认为这样的讨论应该公开进行，因为不涉及安全问题或个人评价，而是孵化器的共识和行为准则。
一言以蔽之，我建议在孵化项目积极回应或解决 IPMC 成员提出的问题或挑战之后，IPMC 成员应当给予积极反馈，认可孵化项目做出的努力，并鼓励项目主动了解和践行 ASF 文化和规则。
一个基本的前提是，在 ASF 的社群模型和定义里，所有成员都是志愿者。这意味着他们不是被雇佣参与开源社群贡献和创造的，也没有上下级关系，而是因志同道合聚集在一起的平等的同侪。
平心而论，大部分孵化器导师不是孵化项目的第一作者，也很少参与到孵化项目的开发贡献当中，甚至对项目的历史和当前社群成员组成都不甚了解。在孵化器导师看来，某个孵化项目出现显而易见的问题，大概率存在其历史原因，或是项目团队其实正在想办法解决。
我对隔着网线能造成的误解深有体会，因此总是尝试假设对方是一个正常人而不是一个弱智，做某件事情肯定有其原因而不是故意破坏，只要能把事情说明白总能取得进展而不是对面就是个恶棍。这些听起来都很平常，但是如果你仔细观察网络空间当中的文字交流，你会发现但凡冲突出现且无法收敛的地方，很多是一方或双方都有前面提到的预设立场。
目前孵化器当中由于沟通能力产生的问题并不鲜见。其中直接触动我的，是一个孵化失败的项目退出孵化器时写下的一段话：
The incubator spends more energy on failing us than helping us.
它说：在孵化过程中，孵化器像是在努力阻止我们成功毕业，而不是帮助我们融入到 ASF 的文化和规则当中。
这很像开发者在一开始 Review PR 的时候，总是执着于找到 PR 当中的错处，把理论上协同开发、合作贡献的流程搞成了大家来找茬。IPMC 成员在审查孵化项目的问题时还有一个额外的问题，就是前面提到的 IPMC 成员往往很少参与项目本身的发展，因此甚至从《大教堂与集市》中提到的 Loken 所有权理论出发，都不那么有权利来评判孵化项目的好坏。
诚然，IPMC 成员大多是经验丰富的老 ASF 玩家。我相信并且从看到的情况看也确实是，每个 IPMC 成员提出挑战的时候，其动机都是为了保证孵化项目符合 ASF 的文化和各种政策要求。但是，我也确实看到 IPMC 成员由于种种原因，草率地给出挑战，或是以一种上级对下级的口吻颐指气使。当挑战的内容本身是个误报，甚至从开发者的角度来说就是无厘头的折腾的时候，IPMC 成员和孵化项目之间的摩擦就会急剧上升。在《全票通过？同侪社群无须整齐划一》里我列举过几个具体的例子。
这些提出挑战的 IPMC 成员往往不是被挑战的孵化项目的导师。因此，他们对这个项目而言更是一个志愿者。我非常尊重这些成员有如此多的时间，来检查大量孵化项目可能存在的问题，而且现在的我也能看清楚他们志愿者的身份，心平气和地按照事情本身的是非曲直来沟通。
不过，对于很多孵化项目来说，遇到直觉上应当经验老到的 IPMC 成员的挑战，还是会很有心里压力。尤其是当孵化项目的导师不能及时处理摩擦（项目导师也是志愿者，时常出现不能及时响应的情况），项目成员很容易感受到孵化器在阻止自己成功，而不是帮助自己更好地成长。
因此，我鼓励 IPMC 成员 follow 其他项目已经广泛验证的经验，在孵化项目做出改进时积极给予肯定，如有可能，自己上手解决发现的问题，或者提供解决问题的具体解决办法。这样，孵化项目能够认识到 IPMC 是帮助自己在孵化器中成长，最终成为 ASF 顶级项目，我相信大部分有志于经历 ASF 孵化的项目，都是有动力配合 IPMC 的指导改进的，只要这些说辞站得住脚。
两个典型的例子。
第一个，@sebb 最近狂盯孵化项目下载页面的合规问题，包括发版投票时候邮件的格式和链接是否指向可靠的地址等等。他提出问题都是非常具体可以解决的，而且在项目解决之后往往会感谢孵化项目及时处理。同时，他还维护了用于 ASF 项目管理的 Whimsy 工具，把这些检查和常见的管理操作尽可能自动化发现和自动化处理。这种从根本上改进流程，又针对每个具体问题提出可以操作的解决方案的做法，为他赢得了相当的声誉。
不过 @sebb 上次跟我扯 ASF 网站模板组织形式的时候，因为被 GitHub UI 显示误导，跟我 battle 了一周，最后发现是他看错了，搞得我也心很累。
第二个，我把自己发现的 StreamPark 距离毕业最大的阻碍，文档的正确、合规和流畅等问题，提出来之后，不仅是 StreamPark 社群的活跃成员积极响应开始改进，还有一位身为专业文字工作者的 IPMC 成员 Andrew Wetmore 伸出援手，仔细改进文档不符合英文表述习惯的地方。这无疑为他赢得了项目成员的尊敬。如果他再对项目的内容提出挑战和改进意见，项目成员也更容易接受。
最后这点我想再强调出来，它代表的是一种同情心或同理心。很多 IPMC 成员对自己辅导的项目都是非常宽容的，经常能够找到通融、网开一面的制度支撑，从根本上是了解体谅项目团队遇到的问题跟当前阶段的困难。相反，当审视其他项目时，往往由于缺乏同情心，容易光是挑战项目的各方各面，而不愿意花时间好好沟通。
比如，孵化器主席 Justin Mclean 在过去几个月里就让我几度血压飙升。
在 HoraeDB 进入孵化器评审的时候，因为原创 CeresDB 团队用新名称捐赠核心代码，Justin 就怀疑人家图谋不轨，搞到最后原来是说代码里很多 CeresDB 的文本还没改过来。如果他一开始就说这些遗留的 CeresDB 文本是问题，马上项目团队就可以开始改，然后我作为 champion 把提案改改，误会就说清了。
在 OpenDAL 进行毕业投票的时候，项目成员没有顺着他的意去处理几个很小的品牌问题，而是就合理性做了一些反问，他就从根本上质疑团队在品牌保护问题上的严谨性，拿放大镜挑各种各样的刺（《Apache OpenDAL 毕业随感》）。最后我找到 ASF 品牌办公室的事务官帮忙评估，才收敛到若干个可实操的改进措施。而即使 OpenDAL 项目成员解决了一系列此前没有细究的品牌问题，在 API Docs 上的品牌合规水平秒杀 90% 的 ASF 项目，Justin 还是不依不挠，沿着预设立场认为你人品有问题。这真是没话说。
在 Fury 刚刚进行的上一轮投票，Justin 稍微表现的正常一点，虽然还是出现了以下经典画面，但是我再三追问之下还是把自己使用的检查工具说出来了，一下子项目成员就能自检出……全都是误报。其中有两个误报只要稍微看一眼就知道是误报，但是 Justin 有功夫回邮件 battle 也不乐意去验证报告的成色。这我只能说是傲慢作祟。至于另外两个，作者能不能多次捐赠代码，Java ArrayAsList Wrapper 这种朴素代码有没有抄袭可能，这搞不清楚只能说是人水平不行。
应当说，Justin 自认作为孵化器主席，有责任充当守门员来保证毕业项目质量，同时也会在前几天某个毕业项目出现品牌问题时，被其他人追责孵化期间怎么没有发现，而上火着急自我辩解，肯定还是对 ASF 的角色有认同。而且 Justin 乐意花这么多时间检查这些确实重要的合规问题，客观来说是非常不容易的。
但是他的表达、语气和措辞真的很容易产生摩擦。@sebb 挑战项目的次数跟他不相上下，孵化项目体感上完全不同。而且 Justin 真的特别闲，所以过往孵化器里想争论道理的人，也没有那么多时间跟他吵这些说白了就是官僚主义的东西。加上 Justin 是 ASF 董事会成员，而董事会成员只有他全力关注孵化器，可能再加上姜宁老师和 Craig 偶尔看看，就导致 Justin 实质上成为孵化器里几乎唯一强势的声音。
中国人是最务实的，现在国内项目要进孵化器，第一时间就是找 Justin 来当导师，然后你总不能自己输出自己，把这个“难关”直接自己消解掉。对于我来说，现在我发现我之前也落入到情绪主导思考的坑里，只要自己别着急上火，冷静按照事情本身的是非曲直来讨论，无理的意见就忽略掉，不自己把任何一个社群成员特殊化，沟通还是可以进行下去的。
回到项目孵化的话题上。
虽然 ASF 一直强调社群重于代码（Community Over Code），但是我的理解一直都是活跃的社群才能一直演进代码，死代码不会自己向前走，而不是说“社群优于代码”，或者“社群才重要，代码不重要”。
因为 ASF 的组织目标明确写了：
The Apache Software Foundation (ASF) exists to provide software for the public good.
然后才是：
We believe in the power of community over code, known as The Apache Way.
所以 ASF 存在的意义是向公众提供好的开源软件，Community Over Code 是手段。
而在孵化器当中，IPMC 成员和项目导师往往不怎么参与到软件研发本身去，大多是帮助项目了解 ASF 文化和制度，成为社群形式上合格的 ASF 顶级项目。实际上，项目的价值还是由软件解决的问题本身所定义的。如今 ASF 代码仓库最热门的六个项目，都是充分解决了某个领域的问题，而不是因为它们合规。
所以，作为孵化器导师，我个人做得多的是参与到项目发展中去，这样才能真正站在项目成员的立场上看待问题，而不至于缺少关键评判视角。对于每位 IPMC 成员来说，至少应该对努力创造软件价值的人保持同情心或同理心，认识到他们是 ASF 长期存在且保持影响力的重要贡献者。这样，才能基于平等的同侪对话共同创造价值。