做为一个开源软件的做者是一种什么样的感觉？

• 原文地址：What it feels like to be an open-source maintainer
• 原文做者：Nolan Lawson
• 译文出自：做为一个开源软件的做者是一种什么样的感觉？
• 译者：根号三

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

你想帮助他们，可是如今你要关闭它们。或许你已经辛苦工做了一成天，或者你累了，或者你只是想和你的家人、朋友享受一个周末。

可是若是你访问 github.com/notificatio…，它会持续地提醒你有多少人正在等着你：

screenshot showing 403 unread GitHub notifications

当你设法找到一些空闲时间后，你打开门并接待了第一我的。他们很是善意。他们尝试使用你的项目，可是在 API 上遇到了一些困惑。他们将本身的代码粘贴到了 GitHub 评论区中，可是他们忘记或不知道怎样格式化它，因此他们的代码很是混乱，难以阅读。

你热心地将他们的代码放到一个代码块中，所以它们有一个很友好的格式。可是你仍然须要阅读不少代码。

而且他们对于问题的描述也很难理解。或许这我的不以英文为母语，或者他们有残疾使得他们很难经过写做进行沟通。你不肯定。总之，你很难理解他们发布的这一段话。

你很疲劳。你看了看排在他后面的数百个其余人。你能够花费半个小时来理解这我的的代码，或者你能够选择跳过他，只是给他一些教程和文档的连接，这些有助于帮助解决他们的问题。你也能够善意的建议他们尝试 Stack Overflow 或 Slack channel instead。

队伍里的下一我的脸上皱起了眉头。他们抱怨你的项目浪费了他们两个小时，由于某个明确的 API 并无像宣传的那样如期工做。他们刻薄的言推辞你感受很不舒服。

你不想在这我的上浪费太多的时间。你简单地回复了：“这是一个开源项目，并由志愿者志愿维护”。若是代码中有一些 bug，请提交一个可复现的测试代码或者一个 PR。

接下来的一我的遇到了一个很是广泛的错误，可是有一个很容易的解决方案。你知道你以前见过这个错误，可是就是想不起来解决方法写在了哪里了。Stack Overflow? wiki? 邮件？Google 了几分钟之后，你粘贴了一个连接并关闭了这个问题。

下一我的是一个长期贡献者。你从各类社区论坛和兄弟项目中认出他们的名字。他们遇到了一个很是深奥的问题，而且提出了一个 pull request 来解决它。不幸地是，这个问题太复杂了，以致于他们的 PR 包含了好几段文字来解释它。

你的眼睛再一次瞥了外面仍然在排队的几百人。你知道这我的在他们的解决方案上作了大量的工做。而且这多是一个合理的方案。Travis 的测试已经经过了。因此你想回复一个 "LGTM" (译者注：Looks Good To Me.) 而后合并它。

然而，在以前你曾吃过这样的亏。你曾经合并过一个 PR 可是并无完整的评估它。最后它让你很头痛由于你没有预料到它带来的问题。或许经过了测试，可是性能降低了十分之一。或者形成了内存泄漏。又或者由于致使了这个项目的 API 过于复杂以致于对新用户来讲容易困惑。

若是你如今合并了这个 PR，明天你可能会遇到更多的问题，由于你经过解决了这我的的（很是边缘的）问题打破了别人的工做流。所以你决定先将它滞后，稍后当你有更多时间时你会再处理它。

下一我的发现了一个新 bug，可是你知道它其实是一个兄弟项目中的 bug。他们说这个问题阻止他们运行应用。你知道这是一个大问题，可是只是许多问题中的一个。你如今没有时间来立刻修复它。

你回复到看起来这真的是一个问题，可是在另外一个 repo 里报告这个问题更合适。所以你关闭了这个问题，并把它复制到另外一个 repo 里面。而后添加一个评论建议应该从代码中的哪一个地方开始修复它。虽然你怀疑他们是否会这样作。（不多啦）。

接下来的一我的只是说了一句“这是什么状态？”。你不肯定他们到底在讨论什么，所以你查看上下文。他们关于一个项目中的长期 bug 的评论致使 GitHub 评论板很冗长。许多人不一样意这个问题本来的解决方案，因此它产生了不少讨论。

在这个问题上有 20 多条评论，你须要花费很长的时间才能阅读并理解全部的内容。因此你只是回复了一句：“对不起，这个问题已经打开了有一段时间了，可是到如今尚未人解决它。咱们仍在试着理解问题的范围。一个 pull request 或许是一个好的开始。”

下一我的仅仅是一个 GreenKeeper bot。这个处理起来很轻松。除了这个特定的仓库有着至关脆弱的测试，而且由于一个看起来并不真实的缘由而测试失败了，所以你为了可以经过测试必须从新启动它。你重启了测试并尝试提醒本身在稍后 Travis 能运行它时检查一下。

接下来的那我的打开了一个 pull request，可是是在一个至关活跃的仓库上，所以另外一个维护者已经提出了反馈。你瞥了一眼大体过程，你相信这个维护者可以处理这个问题。所以你将它标记为已读并继续下一步。

下一我的在运行时出现了一个你以前从未见过的大问题。但不幸的是他们没有提供一丁点关于问题实际发生时的细节。用了什么浏览器？Node 的哪个版本？项目的哪个版本？使用哪些代码能重现它？你要求他们从新提供一些细节并关闭了这个页面。

The constant stream

过了一段时间后，你已经处理了一二十个这样的状况。可是仍然还有几百我的在等待着。可是如今你已经感到精疲力尽了。每个人都有他本身的抱怨、问题、或者是新需求。

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

你的伴侣观察到你在作完这些事情以后老是脾气很坏。或许你发现本身在毫无缘由的嘲笑她，仅仅是由于你的心情很糟糕。“若是从事开源工做会让你如今生气，为何你还要作呢？”她问道。你也没有一个很好的答案。

你能够休息一下。事实上你能够已经尝试过了。以前有一次，你远离 GitHub 给本身放了一两周的假期，仅仅是为了本身的心理健康。可是你知道你结束这种状况的缘由是由于有数以百计的人们在耐心地等着你。

若是你保持关注并处理你的 GitHub 通知。或许天天只有 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 答案的回复和邮件里的问题。我基本上也再也不关注那些我以为别的维护者已经作得很好的 repo。

这种状况如此使人沮丧的缘由之一是，我愈来愈以为处理问题远比实际维护一个项目要花费时间。换句话说，我常常只有时间阅读一个问题而后说：“对不起，我如今没时间看这个。”仅仅是这样的回复就已经占用了我本来为开源预留的大部分时间。

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

我已经告诉个人伴侣，当咱们决定开始拥有一个孩子时，可能我仍是退出开源比较好。我不知道我怎样才能在撑起一个家庭和从事开源之间平衡时间。我预计最终这个将解决个人问题：核选择。我只是但愿它能以一个积极的形式到来，像是开启了个人生活新篇章同样，而不是一个消极的形式。

结尾词

若是你已经阅读到这里，而且对开源社区的问题和潜在的解决方案感兴趣，或许你会想看看 Nadia Eghbal 写的 “Roads and Bridges”，这多是对问题最清晰和最完全的分析。

我也乐于接受建议，可是请记住，我很是不肯意在个人开源项目中将钱和劳动成果混在一块儿（因为傻傻的理想主义的缘由）。可是我曾在 其余项目 中看到它处理的很好。

注意，尽管上边这些都是消极的，可是我仍然感受开源已经成为了对个人生活颇有价值的补充。但我但愿这是一个有用的窗口，它能够感觉到如何成为你本身的成功的受害者，而且没有完成就放下工做而感到压力。

若是说我在开源中学到了一件事，那就是：你作的工做越多，你就越须要工做。我知道这个问题无解。

本文根据 Nolan Lawson 的《What it feels like to be an open-source maintainer》所译，整个译文带有本身的理解与思想，若是译得很差或有不对之处还请同行朋友指点。如需转载此译文，需注明英文出处：nolanlawson.com/2017/03/05/…

---

查看更多文章，请保持关注：github.com/sqrthree/sq… 。