Redis 作者 antirez：开源维护者的挣扎

这两天，一篇名为《开源维护者的挣扎》的文章被迅速顶至 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 开发过程中遇到的最紧张的事情之一。

徒劳

我相信软件虽然很棒，但不会像一本存活了几个世纪的书一样伟大，这绝不是因为它本身不好，而是因为其中的副作用，并且，它终将被更有用的软件替换掉。因此有时我会觉得自己做的一切终将都是徒劳的。

只停留在软件编写本身，而不思考软件“大创意”的人，真的能创造新的标志吗？

总的来说，我能够从事自己真正热爱的事情多年，并且它给我带来了朋友、认可和金钱，所以这算不上是糟糕的交易。

然而，我完全理解，一旦项目开始流行，人们就会为了维持生计而挣扎。这篇文章专门写给你们。