更多深度文章，请关注云计算频道：https://yq.aliyun.com/cloud
在物理世界，路与桥等基础设施的建设，人们都非常重视。在思想观念上，比如说“要想富，先修路”，已深入人心。在资金保障上，人们也毫不吝啬，比如说，亚投行的建立、“一带一路”战略的确立，都是把基础设施的重视，提升到非常显赫的高度。
可是，在数字世界呢？
支撑整个数字世界“纵横捭阖”的各类“基础设施”——软件，特别是占据大半壁*的开源软件，比如，大到你常用的Linux、Android，中到大数据常玩的Hadoop、Spark、HBase，小到Accumulo、ACE、Bahir、Bigtop、Coveralls、Travis、Sauce Labs、Kafka、Knox、Lens、Libcloud、Logging、ZooKeeper等等，数以万计的、你可能都叫不上名字的开源软件，是它们，正以“润物细无声”地方式，让你每天可以愉快地“玩耍”着手机，浏览着新闻、刷着朋友圈、逛着淘宝网……，这些数字基础设施的背后劳作，你曾经重视过吗？
天上不会无缘无故地“掉下来个林妹妹”！那么，又是谁，在背后默默无闻地维系着这些数字基础设施的运转呢？
当然是那些“意气风发”、“技高八斗”、“乐于助人”的开源项目参与者：Contributor（对开源项目提交过部分有用代码的贡献者）和Committer（对开源项目核心模块和系统架构开发有较大代码贡献的技术大咖）。
但“意气风发”、“技高八斗”、“乐于助人”等，这些都是光鲜的表象。作为社会人，这些开源项目维护者，他们和普通人，一样有七情六欲、一样有喜怒哀乐，一样有五味杂陈！
Nolan Lawson，就是这样的人！
他是微软的资深员工，空闲时维护几个开源项目（前后大致有7年光景），还打理着自己的个人网站。近日，他在自己的个人网站，吐槽了自己在维护开源项目时的“酸甜苦辣”。
一把辛酸泪，谁解其中味啊？
每次登录GitHub时，Nolan总能看到一大堆令人头大的、数以百计的维护通知（notifications），等待自己处理，此情此景，都好似有一万匹*，在胸中奔腾。
善良如你，Nolan也想提供帮忙，可是白天上了一天班，已经累得像狗一样好不好，晚上回到家，心有余而力不足啊。好不容易熬到周末，本想和自己的狐朋狗友，去郊外踏踏青、吹吹牛，扯扯淡，享受一下生活，可眼下费时费力的忙，到底帮还是不帮？内心好纠结。
这，就是一个开源项目维护者，时常面临的尴尬！
在维护开源软件时，Nolan还会遇到各位形形色色的人群，具体说来如下几类：
第一类人，他们用你的项目，可能由于某些API（应用程序接口）语焉不详，他们比较困惑，于是来GitHub询问。可令人恼火的是，他们贴出来的代码，连个规整的格式都没有。有没有“同志”有这样的同感：别人写的代码，是天下最难懂的“阅读理解”！特别是没有注释的情况下！
还有就是，可能是由于语言沟通的问题，导致很多问题的描述，理解起来异常困难。
How are you（怎么是你）？How old are you(怎么老是你)？
一番折腾，你可能还是不懂对方的问题是什么？无奈的你，只能甩给他某个文档或某个教程给他，或者建议他去Stack Overflow和 Slack去试一试。
第二类人，他们在提问时，已经是怒气冲冲了。他们会说，你丫咋还不回复他的问题。由于你提供的API有问题，已经浪费他生命中宝贵的两个小时了！
最最让人火大的就是TM这种人！这时的你，唯一能脱口而出的话就是：你大爷的，老子上辈子欠你钱，是伐？
然而，对这种人，你不必浪费时间，要压下怒火，然后礼貌但绝不想再次搭理的回复：“这是一个开源项目，由自愿者维护，如果代码有问题，请提交一个可验证的测试用例或提交一个PR（Pull Request）。
小编注：在这里，简单解释一下，“Pull Request”直译就是“拉回请求”，即如果你想向某个开源代码库RepoA贡献代码，首先你要请求将RepoA克隆一份，开辟（fork）一个新的分支RepoB，然后在RepoB上修正你认为有问题的代码，然后提交给GitHub平台。如果原始代码库管理者A，认为你修改的代码是有价值的，就会审核通过，然后将分支代码RepoB，重新“拉回”到主干RepoA上去（即合并你的代码，作为主干代码），在了解这个流程后，将“Pull Request”翻译成“请求代码合并”是不是更合理呢？当然，在知乎上，也有大神将其翻译为“老司机，带带我！”，是不是也很传神呢？你的翻译是啥，不妨也说说呗！
言归正传，维护开源项目时，还会遇到第三类人。他们在使用开源项目时，可能会遇到一个非常常见的错误。其实，只需翻翻文档中的常见问答（Q&A），或查看一下以往的邮件列表，或花几分钟时间谷歌一下，度娘一下，一切都能轻易搞定。可他们偏偏任性不这样，宁愿做一个廉价的“伸手党”！问你，问你，不停地问你！问你妹啊！
相比于“伸手党”，第四类人就要好很多，他们就是普通的代码贡献者（contributor）。他们呢，小有名气，犹如大侠，技艺高超，侠肝义胆，常常出没于在各种论坛之中。有时，他们会就某个只有内行才懂的议题，发起一个PR，并对其中的某个问题进行修复，然而由于这个议题过于复杂，以至于在他们的PR中，不得不用很大的篇幅来解释他们的所作所为。
当你有点“稀里糊涂”地认可这个PR之后，并回复LGTM（Look Good To Me），然后将其合并到主代码库。
但是，问题来了！
当你没有充分评估某个PR，而将其合并到代码主库，最终会带来很多不可预见的新问题。比如说，虽然测试用例通过，但项目的整体性能却降低了10个数量级，这时你会抓狂的。再比如说，一旦合并某个PR后，也会对老用户造成无尽的困扰。因为更新版的API发生了变化，老用户依据这个开源项目解决问题的工作流程，可能也会发生变化。这种持续不断地变化，会让老用户的体验非常不好！
还有一类人，也属于代码贡献者（Contributor），他们发现了项目中一个新的缺陷（bug），并做了修复。但实际上，这个bug其实你是知道的，它存在于该项目的某个子项目之中，然后当你告知他们，希望他们能在子项目里去PR修复这个问题时，他们时常会“一骑红尘”，再也不搭理你。
现在，在GitHub中，你看出了Contributor和Committer二者的区别了吧：Contributor是对开源项目做出过贡献的人，他们有技术，有激情，但大多数Contributor的激情，常常会在一两次贡献之后，就“一泻千里”。而Committer则不同，他们是Contributor的升级版，有技术，也有激情，最重要的是，他们激情长青，会持续不断地输出贡献
……
还有一类人，他们一开始就兴致勃勃的开启一个PR，但实际上，他们修正的问题，其实早已有其它维护者完美解决了，但他们现在还一片闹腾，也是醉了！
还有一些人，他们的抱怨，的确是可以理解的。
你是知道的，由于开源项目维护者的精力，实在有限，有些问题，有可能几个月过去了，都还没有来得及去处理，所以他们的抱怨是：“3个月前，我咨询你的问题，现在我自己搞定了。其实，解决的方案其实很简单，那就是——哥不再用你的项目了。你的项目，俺用不起，还躲不起吗？”
哇，哇，哇，一腔老血，夺口喷出……
此外，还有很多形形色色的开源项目使用者，他们的问题、他们的抱怨，他们的PR，源源不断地来，解决一批，来一批，“此恨绵绵无绝期”。
这种场景常常令人非常沮丧，每次在维护一边开源项目后，Lawson感觉“整个人都被掏空”了。在诸如GitHub这样的开源平台上，存在这样一个悖论，那就是：越成功，越受罚！
这是因为，如果你的开源项目越成功，别人关注、使用并反馈的问题，也就越多，你为此就会遭受“惩罚”——付出更多的时间、更大的精力，来维护这个项目！
如果简单粗暴地不搭理这些问题吧，Lawson就会感到有很强的负罪感：可能自己的举手之劳，就对别人有很大帮助呢？可自己再怎么“举手”，也只有两只啊？数以百计的问题，扑面而来，如果都是春风细雨般的处理，等不到“夏天”，自己的人生就可能“挂掉”。
但如果总是由“负罪感”驱动来完成某件事，你觉得自己的人生，还会洒满阳光吗？
到后来，Lawson开发了两种策略，简单说来，就是：
1）自卫，展开说就是“自我防卫”。不看（或者说不敢看）GitHub上的维护通知，而是通过邮件过滤、分类处理大部分通知，做到离线（offline）维护，一切等到有空再说。这是因为，在上班时间，你还要为老板每天给你发的薪水负责。在空闲时间，你还有媳妇要陪！
然后，尽量吸引更多的贡献者（Contributor）参与其中，经过考核后，然后将部分Contributor提升为Committer。你知道吗？日理万机，其实是个贬义词，那说明你笨，不懂得管理！
2）自慰，展开来说就是“自我安慰”。天下没有白做的工。做了开源项目，自己不也受益匪浅嘛？首先来说，自己积累了不少社区声望，由此，还登上大会上作报告，并在推特（Twitter）上，有数以万计的粉丝，一呼百应。到后来，由于有了开源项目的经验，还在微软找到了工作，这一切，不都是拜开源所赐吗？
嗯，其实吧，做开源，也挺好！
黑夜中，点燃了一支烟，深深地吸了一口，然后缓缓吐出，吹烟袅袅升起……
Lawson并不知道，维护开源，自卫和自慰，到底哪一个先来？
本文由北邮@爱可可-爱生活 老师推荐，阿里云云栖社区组织翻译。
文章原标题《What it feels like to be an open-source maintainer》，作者：Rachel Thomas，译者：张玉宏（著有《品味大数据》一书），审校：我是主题曲哥哥。