几个月前，一位系统软件领域的开源项目维护者给我写了一封邮件，他的项目拥有一个相当庞大而活跃的社区。他在信中说，维护这个项目这么多年后，他已经感到难以为继，因为这份工作在心理上太过消耗。他想向我寻求一些建议，我也不确定自己是否有资格给别人建议，不过我告诉他，我会就这个问题写一篇博客，谈谈自己的看法。几周过去了，我好几次提笔又停下，因为一直没有足够的时间去慢慢梳理这些想法。现在我想，我已经能够通过剖析自己的软弱、挣扎以及对自由的渴望来找到一些答案——当一个人长时间从事一件本身也包含负面因素的工作时，这些感受总会不可避免地侵入内心。维护一个开源项目同样充满了快乐和乐趣，过去这十年无疑是我职业生涯中值得铭记的十年，即便不是最美好的十年（毕竟创业那段时光我还是更开心）。不过在这里，我将着重谈论那些负面的部分；只是请别误会，维护开源项目并非只有这些，它同样有很多美好的地方。

洪水效应

我不信奉快速行动、快速思考、靠抢时间赢得竞争那一套。我不喜欢我们所生活的这个世界——社交网络、聊天、邮件、排得满满的日程，让人永远无法专注。所以在 Redis 项目的早期，当我还有大把时间的时候，每收到一封关于 Redis 的邮件，我都能专注于发件人真正想表达的东西。然后回想起我们正在讨论的那部分 Redis 代码，最后经过慎重考虑，用自己真实的想法去回复。我认为无论从事什么工作，大多数人都应该这样工作。

当一个软件项目达到 Redis 这样的知名度，同时借助新的社交工具，人与人之间的沟通变得如此简单，再加上你秉持着要“随时在场”回应用户的态度，那么作者收到的消息、issue、pull request 和建议的数量就会呈指数级增长。与此同时，至少在 Redis 的情况是这样，但我相信这是个普遍问题——能够真正胜任并处理这些社区输入的资深人员数量增长却非常缓慢。这就造成了明显的拥堵。大多数人试图用错误的方式来解决它：实用主义。比如，提问后如果原发帖人两周没有回复就关闭 issue；关闭所有描述不够清晰的 issue；以及其他各种“收件箱清零”式的办法。现实是，要真正高质量地处理社区反馈，就必须投入所需的时间，否则你只是在假装你的项目只有少量未解决的 issue。如果有充足的资源为每个 Redis 子系统聘请核心级别的专家全职从事开源工作，问题倒是能解决，但这并不现实。

结果会怎样？就是你开始越来越挑剔地决定看什么、不看什么。而你会因为忽略了那么多事情、那么多人而觉得自己一无是处，同时贡献者也会觉得你根本不在乎别人付出的一切。这是一种复杂的处境。通常最终的结果是，你会养成一种态度：只处理关键问题，而对所有新东西置之不理，因为新东西毕竟还没进入核心，谁又想让代码库变得更大、带来更多的 PR 和 issue 呢？何况这些贡献的代码或许比你习惯的编程风格要晦涩得多，意味着更高的复杂度，等到那里出现严重 bug 需要追踪根源时，就只能自求多福了。

角色转变

作为上述“洪水效应”问题的结果，你突然间也换了份工作。Redis 之所以受欢迎，据说是因为我擅长设计和编写软件。而现在我大部分的工作却是查看 issue 和 pull request，而且我常常觉得，很多收到的贡献我自己能做得更好。当然，其中有些贡献的质量比我能做到的还要好，因为为 Redis 贡献的人里也有比我更优秀的程序员，但就大数定律而言，*大多数*贡献只是普通的、为了解决提交者当下遇到的特定问题而写的代码。而我在为 Redis 做设计时，往往会从整体去考虑它，因为这个东西我已经写了这么多年。所以，你原本擅长的事情，反而没时间去做了。这也就意味着，源自内部、有机的重大新功能会越来越少。我的解决办法是什么？有时候我会连续几周完全不看 issue 和 PR，只是去写代码或做设计：那才是我真正热爱和享受的工作。然而这在心理上又会给我带来更大的压力。为了做我热爱且擅长的事，我得先让自己感到内疚难受。

时间

至少对我而言，长时间从事同一个项目会带来两个问题。

第一，在做 Redis 之前，我*从未*在生命中的每个工作日都工作。我可能工作一周，休息两周，再工作一个月，然后又消失两个月。一直如此。人们需要充电，需要获得新的能量和灵感，才能从事创造性工作。而高水平的编程就是一份他妈的创造性工作。Redis 本身在最初两年就是这样被创造出来的，那也正是项目演进最快的时期。因为我只在想工作时才工作的总产出，远高于被迫每天按部就班工作时的产出。

然而，当我独自经营自己的公司时，我的工作操守还允许我保持这种非常不连续的日程。一旦我开始拿钱全职做 Redis，我的职业操守就不再允许我延续过去的模式，于是我开始强迫自己按照正常的日程工作。对我来说，这么多年来这一直是巨大的挣扎。而且我确信正因为如此，我的产出反而比本可以做到的要少，但事情就是这样运转的。我从未找到解决这个问题的办法。我可以跟 Redis Labs 说我想回到以前的日程，但那行不通，因为到了这个阶段，我真正要“负责”的对象是社区，而不是公司。

另一个问题是，从心理层面来说，长时间投入同一个项目本身就是一件复杂的事。过去我每六个月就会换一个项目。而现在十年里我都在做同一件事。在这方面，我曾试图通过在 Redis 内部开展子项目来保持理智。有时我做 Cluster，有时做 disk-storage（现已废弃），有时又是 HyperLogLog，诸如此类。基本上这些都是能为项目带来价值，但孤立来看又像是全新事物的东西。但最终你还是得回到 issue 和 PR 页面，每天面对同样的问题。“副本因为超时断开了连接”之类的。来吧，再查一遍。

恐惧

我一直有些害怕失去对项目的技术领导力。不是因为我觉得自己在设计和演进 Redis 方面不够好，而是因为我知道我的方式与以下两点并不一致：1）相当一部分用户想要的东西。2）IT 界大多数人对软件的认知。所以我不得不一直在我认为好的设计、功能集合、开发速度（慢）、项目体量（精简）与广大用户群体期望我交付的东西之间不断权衡。幸运的是，有一部分 Redis 用户完全理解 Redis 之道，所以至少时不时我还能得到一些安慰。

摩擦

有些人就是彻头彻尾的混蛋。他们无处不在，这很自然，而且要我说，我甚至觉得编程领域的好人比其他领域要多得多。但你总会碰到一定比例的混蛋。作为一个热门开源项目的负责人，不管以何种方式，你都得去面对这些人，而这或许是我在开发 Redis 过程中做过的最让人倍感压力的事情之一。

虚无感

有时候我觉得，软件虽然很棒，却永远无法像一本能流传数百年的书那样伟大。不是因为软件本身不够伟大，而是恰恰因为它有用……而一旦有更有用的东西出现，它就会被取代。我也想有时间去做些别的事情。所以有时候我觉得，自己所做的一切终究是徒劳的。我们设计并编写系统，然后新的系统又会出现；但如果一个人只是停留在“写软件”层面，而不是“软件背后的宏大思想”层面，他还能留下什么印记呢？我时不时会想，或许我本有能力去钻研那些宏大的思想，但因为我专注于写软件而不是思考软件，所以没能发挥那方面的潜力。这基本上与冒名顶替综合征相反，所以我想我对自己的评价可能过高了：抱歉，我应该更谦虚一些。

话虽如此，我能够多年来从事自己真正热爱的事情，并因此获得朋友、认可和收入，所以我并不想说这是一笔糟糕的交易。但我完全理解那些在项目走红后艰难支撑的人们的挣扎。这篇博客就献给他们。