普通视图

发现新文章,点击刷新页面。
昨天以前首页

应当在 ASF 孵化器中帮助项目

作者 tison
2024年4月28日 08:00

由于 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 长期存在且保持影响力的重要贡献者。这样,才能基于平等的同侪对话共同创造价值。

❌
❌