顶级开源社区都能吵起来?

共 2881字,需浏览 6分钟

 ·

2024-04-12 00:37

起因

因为订阅了 Pulsar 的开发者邮件,前段时间看到一封标题为《(Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika》的邮件。

乍一看以为是欢迎 Asaf Mesika 成为 Committer,但仔细一看不太对劲,这内容也太多了,以往的欢迎都是简单的 Congratulations! 作为回复,这篇内容明显有点多了,于是便仔细看了下。

争论

大概的意思是这封邮件的作者 Kalwit 对成为 Committer 的标准产生了疑问:

他觉得本次提名成为 Committer 的大部分贡献都是一些文档相关的内容,还有少部分是与监控相关的提案。他们团队使用 Pulsar 有一段时间了,但目前还未发现稳定的 Pulsar 版本;大部分的 Review 都是来自同一公司(streamnative)。看起来是整个 Pulsar 项目由某一家公司控制了,他们当初选择从 Kafka 切换到 Pulsar 就是因为 Kafka 由 Confluent 控制,才选择一个更加开放的社区。

这样的一封有着“讨伐”意味的邮件一经发出,自然是一石激起千层浪,社区里很多成员都发表了回复。

这里我挑选了几个代表性的回复:大概意思就是 Pulsar 是一个开放性项目,任何人都可以参加,每两周也有 Zoom 会议,也是每个人都可以参加。

在远程的社区异步沟通过程中,很有可能你的请求没有得到及时的响应,这很正常。

Pulsar 是由社区开发负责维护的,没有公司对此负责,因此没有得到响应时是没有公司可以责怪的;需要大家一起来解决问题,并不一定是需要 PMC(项目管理委员会成员)还是 committer才能提出意见,任何人都可以发表自己的看法。

但这个过程中大家的身份都是志愿者,需要大家自发的去做这些事情。

后续 Kalwit 又继续回复了一些邮件,总体内容就是对社区治理存在疑惑;特别是担心社区背后由某一家公司作为主导,从而导致社区和公司的利益进行绑定。

当然社区的观点依然是,Pulsar 社区不受某一具体公司掌控,并举了具体数据:在 41 个 PMC 成员中,只有 9 位是 StreamNative 的员工,41 位 committer 中有 13 位是 StreamNative 的员工。

其实以我目前在社区的观感,确实是 streamnative 公司社区维护者更加活跃,其他的一些 committer 可能由于工作变动啥的很少再贡献项目了。

提案被否

Kalwit 举了一些例子认为这些 PIP 提案没有获得通过,但是 SN 团队提出的提案大部分都能通过。

我觉得这确实是一种客观现象,但可能更多的原因并不是 SN 公司想要主导 Pulsar 社区的进展,而是他们在社区之外(不管是线上还是线下)进行过额外的沟通,也许在提交草案之前就已经达成了初步一致了,所以在提案审核阶段只需要做一些具体的调整就很容易被通过。

我自己也提过一些提案,大概提交了三个只有一个通过了;我个人的感受是这个过程中响应时间确实不可控(毕竟是异步沟通),但并不会存在某个团队想要控制哪些提案可以通过,哪些提案不行的这种说法。

都是在就事论事的讨论事情,而且不通过的话也会由相关的回复和建议,确实大部分情况也是我考虑不周。

我也看过 asafm 的贡献,其中关于 Pulsar 集成 OpenTelemetry 的提案确实是下了功夫的(一万多字的内容),从头讲解了 OpenTelemetry 的概念,以及 Pulsar 需要做哪些事情来集成。

个人感受

厂商绑定

看完之后我个人的感受是 Kalwit 或者他的团队在参与社区的时候应该是进展不顺利,一些提案或者改动没有得到支持,但看到 SN 公司提交的内容更快得到响应,所以得出了以上的结论:Pulsar 社区由 SN 公司进行了主导。

他的顾虑也不是没有道理,就像他说的 Kafka 社区由 confluence 公司主导,类似的还有 Dubbo 社区由阿里主导、Golang 由 google 主导。

但项目如果加入了 Apache 那他原本的公司其实已经失去了对项目的所有权,只是刚开始的一些 PMC/committer 大部分会是这个公司的员工,毕竟他们是项目的发起者,也更加熟悉整个系统。

如果社区发展的健康,后续应该会补充一些其他开发者,这些开发者不受雇于之前发起的项目的公司,甚至是以个人身份加入;只有这样社区就会更加多样化,出现“一言堂”的几率就会大大降低。

我觉得造成这种现象的原因和一开始该项目是由某一个特定公司发起有有很大的原因,比如 Dubbo、Golang,所以他们公司在社区的声浪更大,自己公司的需求优先级也会更高,毕竟会有来自同一公司的更多的人来审核这些需求。

虽说如前面邮件里回复的:社区是由志愿者自愿维护的,但不可否认的是在这些做开源项目商业化的公司内有一批人就在专门维护社区工作。

他们会把自己商业化过程中遇到的一些问题,或者是新的 feature 也提交给社区,但这里的区别是他们是拿工资的,积极性肯定要比在社区用爱发电的开发者更积极。

这样就会导致社区中最活跃的那批人大概率是靠社区养活自己的人,但这也不是什么坏事;如果你个人或者公司强依赖于某一个开源项目,那也可以想办法多做贡献,成为 committer,这样在一些需要投票的环节也能有一席之位。

厂商无关

当然也有对应的不是由某一个厂商发起的项目,比如我最近参与较多的 OpenTelemetry 社区。

按照官方说法有着 1000 多位独立的开发者,代表了超过 180 家公司,在维护者的列表中也可以看到大多数都是来自于不同的公司:

所以自然也就没有某一厂商主导的说法,所以想要避免这类事情再次发生,最好的方法还是吸纳更多的开发者加入,只有社区成员丰富起来社区才好良性发展。

参考链接:

  • https://lists.apache.org/thread/gzx4j9q0xdtcvrfvvq72t9tm2rt9h3r7
  • https://github.com/apache/pulsar/pull/21080
  • https://opentelemetry.io/blog/2024/opentelemetry-announced-support-for-profiling/ππ


浏览 12
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报