湾区日报·第857期

作为一名开源项目的维护者是一种什么样的体验
原文链接
by zzq
数百人站在你家门口，耐心地等你去解决他们地问题，抱怨，合并代码请求，新功能请求。

你想去帮助他们所有人，但是你现在正在推迟。可能你今天工作不顺利，或者你累了，或者你只是想和家人朋友享受一个周末。

如果你去看一眼github上的通知，它总会提醒你有多少人在等。

当你安排出一些空闲时间，开门迎接第一位等待的人。这些人都是很好心的，他们尝试使用你的项目但对API有些困惑，他们已经把代码帖在Github评论里，但他们忘了或者是不知道怎么去格式化代码，所以他们的代码真的是一团乱，难以阅读。

幸运的是，你编辑他们的评论来添加一个代码块，代码很好的格式化了，但仍然有一大堆代码要去读。

然而，他们对问题的描述难以理解。可能这个人的母语不是英语，或者他们不擅长通过文字进行交流，你也不确定是什么原因。无论如何，你艰难地去理解他们所写的段落。

看到后面还有上百人在排队等候，你有些不耐烦了。你可以花费半小时去理解这个人的代码，或者你可以仅仅浏览以下然后给出一些教程和文档的链接，这很可能无法解决他们的问题。你也可以兴奋的告诉他们去尝试以下StackOverflow或者Slack的Channel。

下一个人皱着眉头。说出一大堆的抱怨话，他们觉得由于你的某个API没有按照公布的方式工作而浪费了他们生命中的两个小时。他们的风凉话让你想你心里不爽。

你没有在这个人身上浪费很多时间。你说：“这是一个开源项目，都是志愿者在维护。如果代码里有bug，请提交一个可再现的测试用例或者一个pull request。

下一个人遇到了一个很常见的错误。你知道之前已经见过这种错误好几次了，但是想不起来解决方法在哪里。StackOverflow？wiki？邮件列表？Google了一番之后，你贴出了个链接，关闭了这个问题。

下一位是一个普通的代码贡献者。你是通过各种社区论坛和兄弟项目认出他们的名字的。他们遇到了一个难解的问题，发送了一个代码合并的请求来解决这个问题。不幸的是这个问题很复杂，他们的Pull Request用了不少篇幅来解释这个问题。

你再一次瞄了一眼排队等候的人。你知道这个人在他们的解决方法里做了很多工作，可能是一个合理的解决方案把。测试用例通过了，所以你冒险合并了这段代码。

然而，你之前曾上过这样的当。当时你没有仔细评估就合并了一个Pull Request，最后由于一些你没有考虑到的问题而引发一个小灾难。通过了测试，但可能导致性能下降十分之一。或许它可能导致内存泄露。可能这个Pull Request使得API看起来更加复杂从而对新使用者造成很多困扰。

如果现在合并这个PR(Pull Request)，明天可能会遇到更多的问题，因为你可能为了解决某一个人的问题而破坏了别人的工作流。把这个问题先搁置在这，以后有时间了再解决。

下一个排队的人发现了一个新BUG，你知道这BUG在另一个兄弟项目中页存在。他们说这个BUG阻止了他们发布APP。你知道这是个大问题，但只是其中的一个，所以你现在没有时间解决它。

你回答说这开起来确实是一个问题，也许开辟一个新仓库更合适。所以你关闭了这个问题并把它拷贝到另一个仓库里，添加了一条评论告诉他们应该仔细检查哪部分代码来修复bug。你不确定他们是否真的会按照你说的做。然而，大部分都没有这么做。

下一个人仅仅问了“现在是什么情况？”。你不知道他们到底在说什么，所以仔细看了以下上下文。他们在github上的一个项目中评论了一个长期存在的Bug，很多人不同意这个问题的解决方案，因此引发了很多讨论。

在这个特殊的问题上有超过20条评论，看完所有评论会消耗很多时间，所以你仅仅回复了“对不起，这个问题存在有一段时间了，但还没有人解决它。我们正在努力解决问题，要是有人解决了给我们发个代码合并请求会是一个好的开始。

下一位的问题比较简单。除了这个仓库有一些古怪的测试数据。这些测试失败的原因看起来很不真实，所以你必须重新运行来测试以下。你提醒自己等数据测试完成后再回过头来仔细看看。

下一个人往那个很活跃的仓库上提出了代码合并请求，另一个维护者正在写反馈，你大概浏览了一下，由于对另一位维护者比较信任，所以把这个问题设置为已读，继续往下看。

下一个人似乎遇到一个BUG，这个BUG你以前没见过。不幸的是，他们提供的数据不充足：用的什么浏览器？Node的版本是哪个？用的项目的哪个版本？他们在开发中使用了哪些代码？你要求他们明确以下这些信息并关闭了这个标签页。

** The constant stream **
过了一会儿，你大概浏览了一二十个这样的人。后面仍然有超过一百人。但是现在你觉得累了，每个人要么是发抱怨，提问题，要么是要求完善该项目。

从某种意义上来说，Github的通知功能展示的永远都是你项目的消极的一面。当他们对你的工作感到满意的时候就不会新建一个issue或者request。他们只有在发现不足之处的时候才会这么做。即使你只花一点实践来浏览这些通知，它也可能是你心理上和感情上感到疲惫。

你的伴侣注意到每当做完这些工作的时候都会变得脾气暴躁。你可能发现自己毫无理由的冲她发火，仅仅是因为你自己心情不好。“如果做这些开源项目使你生气，为什么还要做呢？”她问。这时候你无法回答。

你可以休息以下了。事实上这使你自找的。过去，你为了自己的身心健康会从Github销声匿迹一两周。但是你知道那样做的结果就是现在的状况：好几百人排队等候。

如果你仅仅保留Github通知里的最上面那些通知，可能就会只有20-30个issue需要处理了。然而你却让他们积累了起来，导致现在已经有好几百个了，你觉得很有愧疚感。

过去，出于这样或那样的原因，你从来不让issue累积起来。可能偶尔会见到一个issue被放置了几个月都没处理。你再次去处理的时候提出issue的那个不再回复你了，或者他们说他们用其他项目替代了你的项目从而解决了问题。那种感觉让你觉得很糟，但是你也理解他们的难处。

你从经验中得知对付陈旧的issue最实用的方法是告诉他们“我把旧的issue关了，如果你还没有解决这个问题请再开一个issue或者提供更详细的信息”。通常他们不再回复。有时候会回复也只是很生气的表达他们等了这么长时间。

所以现在你处理Github的通知更加勤奋了，数百人在排队等候，你渴望有一天排队的人减少到100以内，或者一打，甚至是神话般的0。所以你奋力前进。

吸引新的代码贡献者
就这样处理了足够多的issue，即使你真的到达了那个“零点”(即要处理的通知为零个)，你仍然还有一堆Bug没有解决，还有很多代码合并请求。加标签可以有些帮助，比如给issue加上“需要新的版本”、“有测试案例”或者“添加第一个补丁”。“添加第一个补丁”这个标签很有用，因为它经常会吸引新的贡献者。

然而，你注意到吸引新贡献者的那些issue都是简单的问题，处理这些问题并且解释它耗费的时间比你自己去解决所花费的时间更多。你明知是这样却还添加那些标签，因为当你听到别人说这是他第一次为开源项目做贡献时你的心里十分高兴。

你知道他们很可能会提供反馈信息。一般这些人不会成为长期贡献者或代码维护者。你不知道这样做是否正确，或许这样做会吸引到一些真正的维护者来减轻你的负担。

你有一个项目是可以自维护的。你已经好几年没碰它的，但仍然有一群维护者来处理issue和PR。你非常感谢那些代码维护者。但你找不到方法在这个项目上吸引到代码维护者， whereas other projects wind up as your responsibility and yours alone(怎么理解？)

向前看
你不愿意去创建新的项目了，因为你知道这只会增加你维护代码的负担。事实上，这里有一个有悖常情的现象，你越成功，就会受到github通知的更多惩罚。

你仍然可以回忆起创造的兴奋，东拼西凑写个项目并解决了之前没有被解决的问题时的喜悦之情。但是现在你根据经验知道任何一个新的项目都会偷走你维护旧项目的时间。你有时候页考虑是否把某个旧项目正式标记为“不推荐使用”或者“不再维护”。

你不知道在自己崩溃之前还能撑多久。从跟那些以做开源项目为全职工作朋友聊天中，你知道把开源项目作为全职工作会允许你在某个项目上投入更多时间，你也考虑了这件事，但是这并不会给你很多帮助，因为你有几十个开源项目竞争你的时间。

你最渴望的是有更多项目可以自维护。你尽量按照规范：详细的配置说明，代码风格，对那些提交优质PR的贡献者更多的权限。为每个项目做这些事情是挺累人的，也许是我不够勤奋吧。

你知道开源更多的被认为是特权白人的排他性俱乐部，你对这感到遗憾，担心自己在解决这件问题上做的不够。

更重要的是，你感到愧疚：你明知道自己可以帮助一些人解决问题，但是你却让问题搁置数月然后关闭了它。你知道有些人是第一次对开源项目做贡献但是你却没有回复他，这样你可能就会打击了他对开源的热情，这也让你感到愧疚。你对自己做的事感到愧疚，没做的事也感到愧疚，因为你没有招募新人来分享你这愧疚的体验。

** 总结以下吧 **
我以上所述都是基于我个人的真实经历。我说的并不代表所有从事开源软件事业的人的心声，但代表了和我有相同感受的人。

我从事开源事业大概七年了，也不愿意这样抱怨，因为我担心这会被认为是夸张的抱怨。毕竟这些都是我自找的，我本可以随时离开Github，我对别人没有任何该履行的义务。

或许我还应该感到愉快呢？我在开源软件方面的工作给了我现在在社区的地位。我获得了在大会上发言的机会。Twitter上有数千粉丝，他们赞同并捍卫我的的观点。可以说我之所以能在微软公司有一份工作，都要归功于我在开源方面的工作。我到底是在抱怨谁呢？

然而，我只要一些和我有相似感受的人都已经爆发了。之前他们都是热心的合并代码，解决问题，在博客上写关于他们项目的文章，但是有一天他们突然消失了，你再也找不到他们了。对于这些人，我甚至懒得去在他们的代码仓库里新建一个issue，因为我知道他们肯定不会回复。我不是在指责他们，我只是担心自己有天也会和他们一样离开github。

我已经采取一些对我友好的措施了。我不使用Github通知的接口而是用邮件过滤器，所以能对这些通知根据项目(不维护的项目被忽略)或通知的类型(我曾发表过评论的具有较高的优先级)进行分类。邮件也能支持离线工作和把所有东西集中起来。

对那些我已经停止维护的项目的问题的邮件我都标记为蓝色(但是一般我仍然会每一个查看一次)，并且不予回复。我忽略博客的评论，StackOverflow的上回答的回复以及邮件列表里的问题。我甚至对那些我觉得其他人已经维护的不错的项目取消关注。

让我感到沮丧的一个原因是解决这些issue消耗了我维护项目的时间。换句话说，虽然我经常仅仅回复“对不起我现在没时间处理这个问题”，但这些回复也消耗掉我放在开源项目上的时间。

issue模板，GreenKeeper， travis_retry, Sauce Labs, 有这么多针对开源项目的技术解决方案，我很感谢他们。如果没有这些自动化工具我不能专心工作。从某种意义上来说你对一个issue提出反对，它造成的更多的是社交问题而不是技术问题。一个人这么做还不会怎么样。我甚至还不是npm前100维护者就已经感觉到自己被压榨。不能想象那些前100维护者的感受。

我甚至告诉我的妻子，等我们有了孩子，我从开源界退出。我不能想像自己如何能边做开源边抚养家庭。我猜测这最终会解决我的问题：唯一的选择。我希望它能以一种正面的方式到来，就像开启人生的新篇章，而不是以一种消极的方式，比如突然粗鲁的爆发了。

** 结束语 **

如果你已经读到这里了并且对困扰开源社区的问题和解决方案感兴趣，你可能会更想读一下Nadia Eghbal所写的一篇文章Roads and Bridges。这可能是最这个问题最透彻的分析了。

我乐于接受大家的建议，虽然我知道我很不情愿在我的开源项目中把金钱和劳动力混为一谈(可能是一些愚蠢的理想主义的原因)。但是我发现在其它项目中这方法很有用。

希望大家理解，虽然我上面表达了很多负面情绪，我仍然觉得开源是我人生中有价值的加分，我一点都不后悔。但我仍然希望这篇文章能让大家知道成为自己成功的受害者的感受，以及被所有未完成工作拖累的感受。

如果我能从开源中学到一点东西的话，那就是：你做的工作越多，你得到的工作就越多。我觉得这个问题现在还没有解决方案。

** 全文完(2017.3.16) **
不完善之处日后抽空修改，翻译不得当的地方请指正并多多海涵