这两天,一篇名为《开源维护者的挣扎》的文章被迅速顶至 Hacker News 首页,这是 Redis 作者 antirez 发布的最新博客。
几个月前,一名开源项目的维护者向 antirez 发邮件,倾诉自己苦心维护项目多年,这或多或少带来了一些心理上的负担,因此特来寻求建议。
antirez 表示谈不上给出建议,但可以写一篇博客文章来分享对此事的看法。经过反复的思索和自我分析,他坦承“维护一个开源项目会带来乐趣”,但“也有消极的一面”。
接着,antirez 从以下几方面对此展开描述,下边直接采用第一人称:
泛滥效应
当我在项目的早期收到关于 Redis 的电子邮件时,仍然有足够的时间,能够专注于对方在消息里试图表达的内容,并在仔细考虑后回复自己的真实想法。
然而,当一个项目达到像 Redis 这样的流行程度,并且人与人之间的交流因为新的社交工具而变得更为容易时,作者收到的消息、issue、PR 和建议的数量也将呈指数增长。
随之出现一个普遍性问题,至少从 Rsdis 的情况来看是这样,即没有足够多合格的人去查看并处理社区中的这些信息。
大多数人试图以错误的方式解决它:原帖发布两周后若无回复就关闭 issue、关闭所有不明确的 issue,以及其它类似直接把邮件列表全部标记为已读的做法。
事实上,处理社区反馈必须要花费足够的时间,否则只能“假装”项目没有未解决的问题。为开源项目的每个子系统配备全职工作人员是奏效的,但很难实现。
那么接下来会发生什么?你将开始考虑哪些该被优先处理而哪些不是,你将因为自己忽略了太多事物和人而感到不安,贡献者也会认为你是一个漠不关心的人。这种情形实在是很复杂。
通常来说,应该主要先解决关键问题,忽视所有新的东西,因为新的东西还未能进入核心,谁想拥有一个伴随着更多 PR 和 issue 的代码库呢?
角色转换
Redis 流行起来后,我的工作更多地转变为了查看 PR 和 issue。这其中确实有些人会比我做得好,但大多数人的贡献仅处于平均水平,只是解决给定问题罢了。
当我设计 Redis 时,我倾向于将它视为一个整体,毕竟这么多年来一直在写这个东西。所以现实是,擅长的东西往往不再有时间去做。
我的解决方法是,给自己几周时间停止查看 PR 和 issue,转而去编程或者设计,这才是我真正喜爱和享受的。但这反过来又给我带来了更大的心理压力,只在做自己喜欢的事情时做得很好,令人感觉很糟糕。
时间
长时间在一个项目上工作有两个问题,至少对我而言是这样。
第一个问题是,在 Redis 之前,我从未有过在每个工作日都工作的经验。我总是干一周,停两周,接着再干一个月,然后消失两个月。做创造性工作需要充电,以获得新的能量和想法。
但开始收到在 Redis 工作的报酬后,道德规范我不能再依照过去的模式,所以我强迫自己按照正常的时间表工作。这对我来说无比挣扎,而且我确信自己做得比实际能做到的要少。
目前仍未找到解决方法,跟公司申请回到原先的工作模式是不管用的,因为社区的运作方式如此。
另一个问题是,从精神上讲,在同一个项目中进行大量工作也是一件复杂的事情。我过去常常每六个月换一次项目,而如今十年来都在做同一个项目。
我试图通过在 Redis 中部署子项目来留存创造力,先后做了 Cluster、HyerLogLogs 和一个已放弃的磁盘存储项目,现在在做第四个。
不过,最终还是要回到 issue 和 PR 页面,每天重复同样的工作。
恐惧
我每天都在害怕自己失去对 Redis 的技术领导力,不是因为我认为自己在设计和发展 Redis 方面做得不够好,而是因为我的方式与大多数用户想要的,以及大多数 IT 人员对软件的信仰不一致。
因此,我不得不在我认为的优秀设计、功能集、开发速度、项目规模,以及大多数用户所期望的内容之间保持平衡。
幸运的是,有一定比例的 Redis 用户完全理解 Redis 的方式,所以我至少时不时会得到一些安慰。
摩擦
尽管我认为程序员中的好人占比多过其他领域,但总还是有一些混账。作为一个受欢迎的开源项目的领导者,将不得不面对这些人,这可能是我在 Redis 开发过程中遇到的最紧张的事情之一。
徒劳
我相信软件虽然很棒,但不会像一本存活了几个世纪的书一样伟大,这绝不是因为它本身不好,而是因为其中的副作用,并且,它终将被更有用的软件替换掉。因此有时我会觉得自己做的一切终将都是徒劳的。
只停留在软件编写本身,而不思考软件“大创意”的人,真的能创造新的标志吗?
总的来说,我能够从事自己真正热爱的事情多年,并且它给我带来了朋友、认可和金钱,所以这算不上是糟糕的交易。
然而,我完全理解,一旦项目开始流行,人们就会为了维持生计而挣扎。这篇文章专门写给你们。
最新评论