作开源软件的荣耀与辛苦

开源软件| 2017-03-17

你的门外有几百号人在排队。他们在耐心地等待着你回答他们的问题、抱怨、pull requests 和功能请求。

你很想帮助他们，但是现在你决定把门关紧。或许是因为已经辛苦工作了一整天，你累了，又或许你只是想和你的家人、朋友好好享受一个周末。

但如果你去访问 github.com/notifications，它会一直不断地提醒你有多少人正在等着你：

图0：作开源软件的荣耀与辛苦

好不容易找到一些空闲时间，你打开门并接待了第一个人。他很友善，正尝试使用你的项目，但是在 API 上遇到了一些困惑。他把自己的代码粘贴到了评论区中，但是却忘记或根本不知道怎么格式化，所以提交过来的代码非常混乱，难以阅读。你热心地将这些代码进行格式化处理，但即便如此，你仍然需要阅读很多代码。而且可能是因为语言或沟通上的问题，他对问题的描述很难理解。

你看了看排在后面的数百个人，纠结是该花半小时来理解这个人的代码，还是跳过他，只是给他一些有助于解决问题的教程和文档链接。

这时，队伍里的下一个人开始不耐烦了，抱怨你的项目浪费了他两个小时，因为某个明确的 API 并没有像之前说的的那样如期工作。尖酸刻薄的言辞会让你感觉很不舒服。因此，你不想在这个人上浪费太多的时间。你简单地回复一句：“这是一个开源项目，由志愿者维护。如果代码有 bug，请提交可重现的测试代码或提交 PR ”。

接下来的一个人遇到了一个非常常见的错误，你记得之前有处理过类似的错误，但是突然想不起来解决方法写在哪了。到处翻找了一遍后，你粘贴了一个链接并送客。

下一位是一名长期贡献者，你记得他的名字。他遇到了一个非常深奥的问题，并且提出了一个 pull 请求修复。不幸地是，问题很复杂，他的 PR 中包含好几段解释文字。想想外面的长队，你觉得这个人在解决方案上已经做了大量的工作，并且这可能是一个合理的方案，已经通过 Travis 测试。所以想回复一个 “LGTM” ，然后合并它。但是，你又想起之前有吃过类似的亏。合并过一个 PR 但没有完整的评估它，以致于后面出现问题让你非常头疼。如果你现在合并这个 PR，明天也可能会遇到更多的问题，因此决定先将它滞后，等有更多时间时再去处理它。

下一个人报告了一个阻止他们运行应用的新 bug，但你知道它实际上是兄弟项目中的一个 bug。问题很重要，但你现在没有时间马上去修复。因此你回复到：这确实是个问题，但在另一个 repo 里报告会更合适。然后你关闭这个问题，并把它复制到另一个 repo 里面，并附上一段关于修复该问题的解决方法的评论。

再下一个人只是说了一句“这是什么状态？”。你不确定他到底在讨论什么，因此要去查看上下文。结果发现是一个长期的 bug ，许多人不同意原本的解决方案，因此在进行争议。你需要花很长的时间看完所有的评论去理顺他们讨论的事情。所以你只好回复一句：“对不起，这个问题已经有一段时间了，但是目前还没有人解决它。如果有好的想法，一个 pull request 或许是一个好的开始。”

下一个人在运行时遇到了一个之前从未见过的大问题，但不幸的是他没有提供一丁点关于问题实际发生时的细节。项目用的哪个版本？哪个浏览器？要怎么重现？你只能要求他重新提供一些细节并关闭了这个页面。

……

流水线

一段时间后，你已经接待了一二十个这样的人，但仍然还有几百个人在外面等着。每一个人都有他自己的问题和述求，这很容易让人感到精疲力尽。

从某种意义上来说，这些通知就是一个关于你的项目的不间断的消极流。没有人会因为对你的行为感到满意时打开一个 issue 或者是 pull request，他们只会在发现缺少某些东西时才会这样做。尽管你可能只用花费很少的时间来阅读这些信息，但是仍然能让你在精神上和情绪上感到疲惫。

家人观察到你在做完这些事情之后总是脾气很坏，会问你“如果从事开源工作会让你这么生气，为什么你还要做呢？”。你想了想，没有一个很好的答案。

为了自己的身心健康，你尝试去休息，给自己放一两周的假。但是你会不时想到有数以百计的人在耐心地等着你。而且每天处理 20-30 消息，总比堆积上百个在那里要强得多。而且当你回过头处理这些堆积的问题时，他们可能已经不再关注你或者转移到另外一个项目了。你很失望，但你也理解他们对你的失望。所以，你决定继续回答问题，于是，一切又像开头那样重新开始。

招募新的贡献者

像上面这样处理过很多问题之后，即使你最终清空了收件箱，仍然会发现积压了大量的 bug 和 pull request。这时，标签可以帮到你 —— 例如，将问题标记为“需要重现”、“存在测试用例”或者 “good first patch”。“good first patch” 这条尤其有用，因为常常能吸引到新的贡献者。

等一段时间你会发现，通常吸引新贡献者解决的那些问题都是非常容易的问题。针对那些问题，记录下来并且解释如何修复它比你自己修复它还要重要。你甚至可以特意去创建一些这样的问题，因为让新人参与到你的开源项目中是值得的，当 pull request 的提交者告诉你“这是我第一次向开源项目做出贡献”时，你会觉得很开心。

但通常这些人不会成为长期贡献者或维护者，你会怀疑自己是不是做错了，是不是能想点办法做一些力所能及的，但却可以吸引新贡献者并且可以长期减轻负担的事情。如果你之前有过一个自我维持的项目，一直有一个维护小组在帮你回复每一个问题和 PR，在极其感激这些维护者的同时，会去反思是因为做了什么事情才有如此多的维护者参与这个项目中，而其他的项目却只能独自负责。

展望未来

想到维护的负担，你不太愿意再去创建新项目了。这是一个对立的现象：你的项目越成功，你从 GitHub 的通知那里得到的“惩罚”就越多。

你偶尔会回忆起创作的激情，从头开始写一个新项目，解决之前未解决的问题时的那种喜悦。但是现在你不喜欢这种喜悦，因为任何新项目都会从旧项目中窃取你的时间。你会思考，是不是已经到了正式放弃一些旧项目或者标记它们为不再维护的时候了。

你最想要的是有更多的项目可以自我维护。你尝试按照最佳实践：一个 CONTRIBUTING.md 和一个行为准则，并热情地向所有提交高质量 PR 的人发出邀请，给予所有者权限。

为每一个项目都做这些事情是非常辛苦的，所以，你并没有对自己想象中的那样勤奋，但同时又因为没有付出足够的努力来修复问题而焦虑。你想到自己明明可以帮助某人解决他们的问题但是反而让他们的问题放在那烂了几个月然后关闭它而内疚，或者明明看到某个人在仓库发起了他们的第一个 pull request 但是没有时间去回复而内疚，因此这可能导致他们对开源感到失望。你因自己的所作所为感到内疚，因没能做到的事情感到内疚，并且不想招募更多的人来分担你的内疚。

Putting it all together

上面所说的都是基于我自己的经验，这不代表了所有从事开源软件事业的人，但是这的确是我个人的感受。

我已经从事开源很长一段时间了（大概 7 年），我一直不愿意去对外抱怨这些事情，因为我担心这会被理解为无意义的发牢骚。毕竟，这种情况不是我自己导致的么？只要愿意我可以随时离开 GitHub，我没有义务对任何人负责。

还有人会觉得，我不应该感激吗？我在开源方面的工作让我获得了名声，被邀请在一些会议上演讲，在推特有成千上万的粉丝在听我说的话并且高度尊重我的意见。可以说我之所以得到了微软的工作也是因为我在开源方面的经历。我该抱怨谁？

我知道已经有很多跟我类似的人选择了放弃，那些曾经积极合并 pull request、修复问题的人消失的无影无踪。对于其中一些人，我甚至都不会在他们的 repo 上打开 issue，因为我知道他们不会回复。我不会抱怨这些事情，但是我担心我也会走他们的老路。

我现在已经采取了很多自我保护措施。我不再使用 GitHub 的通知界面，使用邮件进行过滤。因此我可以基于项目或通知类型进行分类。而且使用邮件，也有助于我离线工作，并且在一个地方处理掉所有的事情。

我经常会收到蓝色级别的邮件让我去支持一个我已经停止维护的项目，通常情况下我不会回复他们。还倾向于忽略博客文章里面的评论、Stack Overflow 答案的回复和邮件里的问题。造成这种情况的原因之一是，我越来越觉得处理问题远比实际维护一个项目要费时间。换句话说，我经常只有时间阅读一个问题然后说：“对不起，我现在没时间看这个”，仅仅是这样的回复就已经占用了我原本为开源预留的大部分时间。

Issue templates、GreenKeeper、Travis、travis_retry、Coveralls、 Sauce Labs… 有这么多针对开源的技术解决方案。我非常感激它们，因为如果没有这么多自动化工具，我将无法保持专注。但在某些时候，相比技术问题，你遇到的更多的是社交问题。一个人成不了规模。我甚至不在前 100 个 npm 贡献者之列，就已经感觉到了如此压力。简直不敢想象那一百个人会是什么感觉。

我已经告诉我的妻子，当我们决定开始拥有一个孩子时，可能还是退出开源比较好。我不知道怎样才能平衡撑起一个家庭和从事开源之间的时间。我希望彻底“核毁灭”能带来一种积极的生活方式，开启生活新篇章。