几百个人排成一个队伍,候在你家门外。他们耐心等待你去解答问题、听他们的抱怨、回复 Pull Request 和 Feature Request 。
你想去帮他们所有人,但你一直拖到现在。也许你辛苦工作了一整天,或者你累了,再或者你只是想跟家人和朋友享受周末。
但你如果登陆 github.com/notifications,Notification 会不断提醒有多少人在等着你:
当你设法找到一些空闲时间,你开门迎接第一个人(即处理第一个问题,其中可能包含不止一个人,下同)。他们足够善意;他们想使用你的项目,但在 API 上陷入一些困惑。他们把代码粘贴到 GitHub 评论上,但是忘记了或者不知道怎么格式化代码,结果代码一团糟。
还好,你编辑了他们的评论以添加代码块,把代码格式化了。但仍有许多代码需要读。
另外,他们对问题的描述有些让人难以理解。也许英语不是他们的母语,或者他们在书面表达上能力不足。不管怎样,你努力去理解他们提交的文本段落。
你疲倦地看了一眼,排在队伍后面等待的另外几百个人。你可以花半个小时去理解这第一个人的代码,或者你可以只是浏览一遍然后给出一些教程或者文档的链接,说不定可以帮助他们解决问题。你还愉快地建议他们尝试 Stack Overflow 或者 Slack 。
第二个人皱着眉头,脸上露出不悦的神情。他们不断抱怨你的项目如何浪费了他们生命中的两小时,因为某个 API 没有宣传中的效果。他说的话很刻薄,让你很不舒服。
你没有在这个人身上浪费太多时间。你简单地说道,“这是一个开源项目,且由志愿者维护。如果代码中有 Bug,请提交一个可复现的测试案例或者 PR 。”
第三个人遇到的是一个很常见的错误,解决方法很简单。你之前看到过几次这个错误,但是一时想不起解决方法在哪。Stack Overflow?维基?邮件列表?在谷歌搜索了几分钟后,你粘贴上了一个链接然后关闭了这个 Issue 。
第四个人是一个定期的贡献者。你从多个社区讨论会和兄弟项目( sibling project )中识出了他们的名字。他们陷在一个十分晦涩的 Issue ,并提交了一个 Pull Request 来解决它。很不幸这个 Issue 很复杂,所以他们的 PR 中包含许多枯燥的段落,来解释问题。
再一次地,你瞥了一眼还在排队等待的几百号人,你知道这第四个人在他们的解决方案上花了很多工夫,并且可能这个解决方案是合理的。Travis 测试通过,所以你打算只评论句“LGTM”,然后合并掉这个 Pull Request 。
然而,你之前被这类情况伤过。在过去,你合并了一个 PR 但没有经过充分的评价,最终因为一些你没有预见到的问题,它导致了新的麻烦。也许是测试通过了,但性能下降了 10% 。或者它引发了一个内存泄漏。或者可能这个 PR 让新用户对项目感到困惑,因为它使得 API 看起来过于复杂。
如果现在你合并了这个 PR,以后可能会有更多的问题,因为你为解决这个人的问题而打断了另一个人的工作流程。所以你把它放在次要位置,等有了更多时间再去处理它。
第五个人发现了一个新 Bug,但你知道实际上它是兄弟项目中的一个 Bug 。他们说这阻碍了他们启动 App 。你知道这是个大问题,但只是众多问题中的一个,所以你此刻没有时间去修复它。
你回应道,这看起来是一个真实的问题,但是它更适合在另一个 Repo 中打开。所以你关闭了他们的 Issue,把它复制到了另一个 Repo,然后你添加一个评论提示,在代码中从哪里开始修复它。尽管你怀疑他们实际上会这个做。很少人会。
第六个人只说道“现在是什么情况/状态?”你不知道他们在谈论什么,所以你看一下上下文。关于项目中的一个长期存在的 Bug,他们在冗长的 GitHub 线程上进行了评论。许多人不同意这个问题目前的解决方案,所以产生了许多讨论。
在这个特定 Issue 下有超过 20 条评论,要读完并记住,需要花费你很长的时间。所以你仅仅回应道,“对不起,这个 Issue 开放了一段时间了,但还没有人解决它。我们仍试着去理解问题的范围,最好是开一个 Pull Request !”
第七个人只是个 GreenKeeper 网站机器人。他们的问题很简单,除了这个特殊的 Repo 中有相当碎片化的测试,且这个测试由于看起来像是谬误的原因失败了,所以你不得不重新测试看是否通过。你重启了这个测试,并试图让自己记住在 Travis 有机会运行后再去观察一下。
第八个人开了一个 Pull Request,但所在的 Repo 相当活跃,另一个维护者已经做出反馈。你看了一眼线程,你相信其他维护者会处理好,所以你标记它为已读,然后走开继续。
第九个人遇到的似乎是个 Bug,而你之前也没见过。但不幸的是,他们对“这个问题实际是如何发生的”没有提供足够的细节。是什么浏览器下出现的?哪个 Node 版本?哪个版本的项目?他们用什么代码来复现它?你让他们做出澄清,然后关掉这个标签。
问题不断涌进
不一会儿,你接待了 10 到 20 个这样的人。仍有 100 多个在排队等待。但此刻你感到精疲力尽;每个人不是抱怨,就是有问题要解答或者是有增强的请求。
在某种程度上,这些 GitHub 通知就是不断涌出你项目中差的一面。当他们满意你的工作时,就不会有人建立一个 Issue 或 Pull Request。只有当他们发现有所缺失,才会如此。即使你只花了一点时间阅读这些通知,在精神和情感上都是消耗。
你妻子观察到在例行完这些公事之后你总是暴躁易怒。也许你发现自己总是没缘由地对她厉声呵斥,仅仅是心情不好。她问你:“如果开源工作这么让你愤怒,为什么你还要做它?”你找不到一个好的答案。
你可以暂停;事实上目前你可能已经有所体会了。在过去,你曾从 GitHub 休假过一两个星期,只为了精神健康。但最后因为有几百个人在耐心等待(你去处理问题),不得不停止休假。
如果你过去持续跟进 GitHub 通知,你可能每天要处理 20-30 条。相反,你让它们堆积,所以现在攒了几百条。你感到内疚。
在过去,由于这样或那样的原因,你确实让这些 Issue 堆积。你或许看到一条数个月都没人应答的 Issue 。通常,当你返回找到那个Issue,提出这个 Issue 的人从不回应。或者他们这么回应,“我们放弃了你的项目而用了另一个,这样我的问题就解决了。” 这让你感觉很糟,但你明白他们的挫败感。
你从经验中得知,对于这些陈旧的 Issue,最实用的回应往往是只说句,“我要关闭这些旧的 Issue,如果这对你仍是个问题,或者你能提供更多的细节,请重新开一个 Issue 。”通常没有人回应。有时候有,也仅是一个愤怒的评论,抱怨怎么让他们等这么久。
所以现在你想更勤快地处理你的通知收件箱。几百条太多。你渴望这个数字缩减到一百,几十,或者甚至是神话般地清空。所以你奋力前行。
吸引新的贡献者
在处理完足够多这样的 Issue 后,即使你的收件箱最终被清空,最后可能仍会积压大量的 Bug 和 Pull Request 。标签可以起到作用——例如,你可以把 Issue 标记为“需要复现”或“有测试用例”或者“很赞的首个补丁”。“很赞的首个补丁”尤其有帮助,因为他们常常可以吸引到新的贡献者。
然而,你发送能吸引到新贡献者的那一类 Issue ,往往是处理起来非常简单的那一类,这一类 Issue 由新的志愿者去记录,比你亲自去做更有价值。你创建了一些这类的 Issue,因为你知道它的价值所在,让新人参与到开源,当这条 Pull Request 的作者告诉你“这是我在开源社区做的第一个贡献。” 你感觉很棒。
但你知道他们回来的希望很渺茫;通常这些朋友不会成为定期贡献者或维护者。你怀疑是不是你哪里做错了,你在哪方面改进,才能吸引住新的贡献者来帮你减轻负担。
你有一个项目几乎就是靠自身维持的。你多年没碰了,但有一帮维护者会回应每一个 Issue 和 PR ,所以你不必亲自去。你非常感激这些维护者。但你不知道你做了什么才使得这么多贡献者投入这个项目,而其他项目最后都是你,且只有你自己负责。
向前看吧
你不愿去创建新项目,因为你知道它只会增加你的维护负担。事实上,这里有一种反效应,你做得越成功,在 GitHub 通知上得到的“惩罚”就越多。
你仍能回想起这种创建的快感,从零开始写一个新项目以及解决一个之前未解决问题的喜悦。但是现在你开始衡量这种喜悦,因为任何新项目必定会从旧项目中夺走时间。你不知道是否是时候该正式摒弃你的一个旧 Repo,或者把它标记为 Unmaintained。
你不知道在你倦怠之前,这样的情况还要持续多久。你曾考虑将开源工作作为你的白天工作,但是自从你和真正从事开源为生的朋友交流后,你知道这通常意味着,让一个特定的开源项目作为你的白天工作。这对你无益,因为你有几十个跨越多个领域的项目,这些都在争夺你的时间。
你最想要的是更多的项目可以自身独立维持,你尝试去遵守所有的最佳实践:你有 CONTRIBUTING.md 和行为指导,你热情地交出拥有的特权,给任何提交高质量 PR 的人。然而每个项目都这么做,也很耗费精力,所有你没有你期望的那样勤奋。
你也为此感到内疚,因为你知道开源常常被看做是有特权的白人男性(比如你自己)的专属俱乐部。所以你担心你做的还不够,去解决那样的问题。
更重要的是,你感到内疚:内疚来自于你知道你本可以帮助有些人解决他们的问题,但你让他们的 Issue 在关闭前被无视了好几个月,或者有人在你的 Repo 开了他们第一条 Pull Request,但你没有时间去回应,这可能因此让他们沮丧到永远不想再参与开源。你的内疚是因为你已做的事情,也是因为你没做过的事情,以及因为你没能招募到更多的人分享你的不幸而有负罪感的经历。
集中到一起
以上我说的一切都是基于我自己的经验。我不能声称自己代表所有开源软件工作者,这是我自己的感觉。
我从事开源工作已经有很长一段时间了(大约 7 年),我一直不愿去抱怨任何这些牢骚,因为我担心会被理解为是本应了解更多的前辈在这里夸张地发牢骚。毕竟,这种处境不是我自己造成的吗?我可以随时离开 GitHub;我没有跟任何人签合约。
还有,我不该感激吗?我从事的开源工作帮助我在社区树立了地位。我获得了在会议做演讲的邀请。在 Twitter 上我有几千号粉丝,他们倾听我的想法,并对我的意见给予很高的评价。可以说,我得到微软的工作是因为我的开源经历。我还有什么可抱怨的?
然而,我知道许多其他处在与我同样位置的人都已倦怠。伙伴们也都曾热情地合并 Pull Request ,处理 Issue,写博客展示他们的项目,之后就消失得无影无踪。对于其中有些人,我甚至不愿在他们的 Repo 中开 Issue 。因为我知道他们不会回应,我不反对他们,但我担心自己会变成他们一样。
我已经采取了大量的自我保护措施。我不再使用 Github 通知接口——我使用电子邮件过滤器,这样我可以基于项(Unmaintained 这一类可以忽略)或者通知的类别(提到过的或者我评论过的线程通常会有优先权)来分类通知。因为是电子邮件,这也有助于我离线工作和在同一处管理事务。
我常常会出乎意料地收到在项目上请求支持的邮件,而这个项目我停止维护已经很久了(例如这个项目,我仍至少每月会收到一封),而通常我都是不回应。我还选择忽视我博文下的评论,不回应 Stack Overflow 的回答和邮件列表下的问题。我还积极地取消关注了那些我认为其他人维护得足够好的 Repo 。
这种情况如此令人沮丧的另一个原因是,你越来越发现处理 Issue 从项目实际维护中夺去太多时间,换句话说,我通常只有足够读取Issue,然后说“对不起,我此刻没有时间看”的时间。仅仅是回应的行为,就会占据我为开源预留的大部分时间。
Issue templates、GreenKeeper、Travis、travis_retry、Coveralls、Sauce Labs… 有太多技术工具可以处理开源维护问题,我很感激有这些工具。如果没有这些自动化工具,我就不可能保持头脑清醒。但在某些时候,你会遇到很多 Issue,它们里面涉及的社会性问题比技术性问题更多。一个人不足以说明。我甚至没有进到前100位 npm 维护者榜单,我就已经累觉不爱了;我无法想象那 100 个人是什么体会。
我已经告诉我妻子,如果当我们打算开始要孩子,我还是放弃开源工作为好,我觉得自己没有能力兼顾抚养家庭和维护开源项目,我预料到,放弃开源才是我核心问题的解决方案。我只希望它会以一种积极的形式到来,就如开始我人生新的篇章,而不是以一种消极的形式,比如毫不客气地倦怠。
最后的一点思考
如果读到这里,你对困扰开源社区的问题和潜在的解决方案感兴趣,你可能会想研究下 Nadia Eghbal 的《Roads and Bridges》。它可能是对该问题最清晰最深入的分析。
我也乐于接受建议,尽管我在心中牢记我不愿在开源项目中把金钱和劳动混在一起(也许是出于天真的理想主义)。但我曾在其他项目中看到它是有效的。
请注意,尽管上文表达了开源消极的一面,但我仍觉得它是我生活里一个有价值的补充,我没有任何后悔。但我希望这篇文章对大家有帮助,让你们看到成为自身成功的牺牲者是什么感受,以及你会因为未完成的工作而感到沉重。
我从参与开源的经历中学到的一点就是:你参与越多,对你的要求就越多。我意识到这样的问题,并没有解决方法。
-
工程师
+关注
关注
59文章
1559浏览量
68221
发布评论请先 登录
相关推荐
寻求专业工程师帮助设计USB多口充电器
![](https://file1.elecfans.com/web2/M00/EB/14/wKgaomZXAd-AWEwjAAuV2RdwuSM130.png)
嵌入式软件工程师和硬件工程师的区别?
![](https://file1.elecfans.com/web2/M00/E5/09/wKgZomZB1aqAfoLMAALwKMk88bw153.jpg)
![](https://file1.elecfans.com/web2/M00/DE/DE/wKgZomYwuQ-AegjsAAISSibiD4I286.jpg)
为何国外工程师偏爱使用for(;;)来实现MCU死循环?
![为何<b class='flag-5'>国外</b><b class='flag-5'>工程师</b>偏爱使用for(;;)来实现MCU死循环?](https://file1.elecfans.com/web2/M00/C7/64/wKgaomYKKiOAK5wZAAARYlyfX1A944.png)
![](https://file1.elecfans.com/web2/M00/C5/1E/wKgaomXxdsmAENR6AAKEdyutPEU736.jpg)
![](https://file1.elecfans.com/web2/M00/C1/46/wKgaomXUeXuAXDwNAAJ_XqvplMU996.jpg)
优秀电源工程师的必备技能大揭秘!
![优秀电源<b class='flag-5'>工程师</b>的必备技能大揭秘!](https://file.elecfans.com/web2/M00/44/4C/poYBAGKEjmeADbeIAAAzd_WGD8I942.png)
![](https://file1.elecfans.com/web2/M00/B7/7A/wKgZomV8LgGAKD-NAArU-xVYe90454.png)
![](https://file1.elecfans.com/web2/M00/B0/C1/wKgZomVXnJuAcozaABJWWN5ArbY888.jpg)
评论