发布于 2016-11-18 00:23:02 | 280 次阅读 | 评论: 0 | 来源: 网友投递
Python编程语言
Python 是一种面向对象、解释型计算机程序设计语言，由Guido van Rossum于1989年底发明，第一个公开发行版发行于1991年。Python语法简洁而清晰，具有丰富和强大的类库。它常被昵称为胶水语言，它能够把用其他语言制作的各种模块（尤其是C/C++）很轻松地联结在一起。
很多人会命令开源项目维护者赶紧修复这个或那个 bug、逼迫维护者们要满足自己不合理的功能请求、稍有不顺就要对开源项目维护者们进行人身攻击。要求别人为自己免费劳动，就是在剥夺别人的时间，就是谋财害命啊。作者休息一个月，在本文中思考了开源社区人与人的协作关系、基本礼貌等问题。
为何我暂停了维护 Python 社区的志愿者工作
2016年10月1日，我决定中止对 Python 社区的维护工作，到现在已经有1个月了。从2002年6月我参加 python-dev 以来，我几乎将所有的精力都用在了维护 Python 开源项目上，即使是节假日，我们也会通过 Email 来工作。到目前为止持续14年了，这对我来说是一次重大的突破。
为什么我会暂停维护社区的工作？
之所以在坚持了14年之后，做出这样一个艰难的决定，源于7-8月期间发生的一些事情，让我开始思考是否还需要继续下去。
刚开始维护 Python 社区时，用户只是让我帮助修复 bug。但如果我没有及时修复，就会连续不断地收到 Email ，传达他们因我没有及时给予解决的不满情绪，认为给了我足够的时间与期望，但我还不愿意帮助他们解决问题。
记得那时 Python 3.5.2 版本存在的一个 Bug 还没来得及修复，新版本 3.6 就发布了，导致在新发布中也存在则这个 Bug。于是，就有非核心开发人员说，应该设置一个发布限制条件 [译者注：即前一个版本的bug没有修复，则后续版本不能发布]。也有用户评论，修复一个 Bug 只是举手之劳，而我却不愿意去处理。要知道，不是所有的 Bug 都是很容易就修复的，尤其是当它跨越多个版本的修复的时候。
当我试图解释 Python 修复 Bug 的复杂性时，立马就有人开始指责我在找借口。两个月后，我在Twitter上也看到了同样的抱怨：所有这些都因为某个用于非主流 shell 的 venv 激活脚本出现了一个bug（换句话说，这并不影响Python的执行，系统不会因为这个问题出现异常）。而他们始终都没有试着去了解保持 Python 功能正常的困难度有多大。
紧接着我收到了有关问题追踪器的反馈——为什么它要提议对语义进行修复？在某个星期六的早上，我在回复中解释了为什么要这么做，以防有人认为这是bug，然后浪费一整个周末去修复。但事与愿违，我的好心解释被误以为是我在试图阻止他们为社区做贡献。（后来这些用户在了解真相后向我道歉了）。
作为 Python 语言的开发者及社区的管理者，我觉得，基于 Python 语言的一些线程使用的比较多。却很少用户向我反馈这方面的使用情况。在维护过程中，每当我看到社区用户之间用言论呼吸攻击的时候，我都非常沮丧，觉得自己没有将社区维护好。
当我看了Nadia Eghbal's Road and Bridges 关于福特基金会的 OSS 维护报告，我才认识到这十多年默默无闻的付出和忍受是种浪费。（我觉得每个开源的项目使用者都应该读读这份报告）。报告清晰的阐述了社区用户之所以毫无时间概念的向我提出工作要求，只因我一直自愿加班为他们解决问题而且不求回报。久而久之，他们认为这是理所当然的，我就应该及时解决他们反馈的任何问题。报告也就这一现象做出了说明，大多数人希望我在业余时间能够帮助他们，实际上就是找一些理由让我处理与Python专业相关的问题。（自我加入Microsoft以来，我接触了各种形式的业务内容，Python是我工作的一部分，我这么一干就是14年）。
开源工作的类比解释
对于我们这些项目维护者的工作境遇，有很多人知道后一定觉得不可思议。（说是所有的维护者也不夸张。目前为止，我还没有见过那个维护者没有受到虐待的。）为了便于理解，我试图做个类比来解释。
设想一下，你还是童年时期，有一天想到了一个新的非常有趣的游戏（可能是棋盘游戏，也可能是游乐场玩的其他游戏）。于是你将这个游戏的形式和规则告诉了小伙伴们。小伙伴们觉得特别有趣都玩了起来。而这时，又有一群新的小伙伴想要加入，于是你重新介绍了一遍游戏……随后，越来越多的的小伙伴想要加入，而每次你都要介绍一遍游戏。为了省事，同时也为了让更多的小伙伴可以参与进来，你决定花时间和经费做一个使用手册，里面包含游戏内容和规则。这样，只要有小伙伴想要加入，直接看手册就可以学会这个游戏的玩法。
随后，就有人开始建议将游戏进行改进，增加一些内容或规则。你觉得很有道理，于是采纳了建议，更新规则后重新制作了手册，再发给有需要的人。后来，一直有改进的要求提出，你需要不断去完善，修改，重新制作手册。为了将游戏做得更完善，你丝毫不介意这些建议增加了你的工作量。
然而，又来了一批不认识的小伙伴，要求你必须增加一条“打人”的规则。你对这种命令式的态度非常不满，而更为重要的是，你并不想在游戏中增加暴力元素。你很委婉地拒绝了这个建议，于是对方就开始对你进行攻击，攻击完后还随手拿走了游戏手册。看到自己的劳动成果被如此粗暴的对待，你心里当然很难过。
面对刁难，如何调整心绪？
现在假设，Python 就是这个游戏，而要求改变规则的是一些软件开发者。这些开发者不停地向你提各种各样的需求：“这需要改变，”或“你应该改改这个。”他们不认可你的作法，也不听任何的解释。一旦他们不再坚持了就会直接离开，但这并不代表他们认为你是对的。因此，当有人和你说“你为什么要这么做”的时候，最好的回应就是不做任何回应。。
除了不停质疑我并且不断向我反馈的用户以外，同样让我感到心累的是，还有些 Python 用户总觉得我应该理所当然地免费为他们提供服务。而他们的损失再不济也就是自己动手下载并安装这个程序。（如果你用的是Linux的话，就不必费这个力气，因为 Python 已经安装好了，所以只要往终端中敲入“ python ”这 6 个字母启动解释器就行了）。
我花了大量的时间开发 Python 供用户免费使用，却总有一些用户的态度感觉像是他们买了这个商品，我必须给他们提供“售后服务”。他们认为使用我的 Python 是帮助我提升名制度，我要知恩图报。而事实是，我花时间和精力开发出这些代码，供他们免费使用，就是我送给他们的一份礼物。但在这些用户眼里，似乎我还需要搭上往后更多的时间和精力无偿帮助他们。
我的看法
当我参加一些 Python 相关的会议的时候，我从来不会觉得人们对我的设计思路不满或者对 Python 感到厌恶。当然，我也会遇到一些极端的人，当他们知道我是谁后，会对我说些难听的话。但我完全可以将他们无视，而接触那些热于工作并支持 Python 的人。
一年当中，大概有两个星期的时间，我能得到一些正面的评价，但剩下几十个星期就不是这样了。虽然PyCon 上的也有用户会说“谢谢我对工作的付出”，但大多数时候，当我花时间帮他们解决问题后，只能得到轻描淡写的“谢谢”。在线上，不管是从核心开发人员还是常规参与者那里，我听得最多的就是，我能不能满足他们对xx或xx的需求，当然也有一些日常问候，但这在少数。有人说，10 个善意的举动才能抵消 1 个恶意举动带来的伤害，但我认为善与恶的分量不是通过 10:1 能体现的。
开源工作的群体关系
接下来我该怎么办呢？我并不想停止对Python的贡献。我在社区结识了不少朋友，每当我宅在家里的时候，我们就会在线上交流一些有趣的事情。可现在，有些事情必须要改变。但在知道我需要改变的是什么之前，我必须端正考虑问题的方式才能避免事情出现偏差。
首先，我将开源软件视为开放式的开发，即在分享软件的同时，也应分享维护该软件的责任。这意味着，我不会像其他免费软件一样将源码开放视为必要的条件，而是以此为方式促成与软件使用者的合作，使软件更易维护。而这一切的成功取决于认真履行义务的项目维护者与其他用户之间的关系。
让我们看看这种关系涉及的不同类型的用户。最大的群体是那些甚至不使用这一项目的人，他们通常会问我们，这个项目他们的系统能用吗？一旦他们发现这个项目不适合他们的时候，他们可能会说：“我根本就没法用，垃圾！”而不会意识到这款软件本来就不是为所有人打造的。每当这时候，项目维护者都不能进行回击，否则情况会更糟。
第二类群体就是项目的真正使用者，他们通常会向项目维护者咨询一些解决问题的方法。所以，他们的存在可以推动项目更好地进行。然而，当他们要求项目维护者代替他们解决问题时，他们可能会失望。就像我们前面说到的，开源需要人们相互合作以维护项目。这就意味着用户可以向项目维护者提出改进的建议，但他们不能要求维护者必须一定得这么做。换句话说，你可以问：“你有考虑添加这一功能吗?”但是不能说：“你必须添加这项功能”，因为项目维护者都是志愿者，他们分文不收地贡献了这个项目，但这不代表他们要听命于你。
第三类群体是bug的提供者，他们会将在使用过程遇到的问题反馈给维护者。所以，bug提供者通常都会希望，社区能有一个专门的区域用以反馈bug问题，最好还能对bug进行分类。而项目维护者希望的就是，bug提供者不要要求他们必须将所有bug都修复。然而，当一个bug被反馈很多次的时候，还是要引起重视，因为问题可能很严重。对于bug提供者，有关键的两点我想告诉你们：第一，每天都有很多bug被反馈，你的反馈只是万千中的一个，不要太拿你的bug当回事；第二，bug的出现可能会影响你的使用情况，但修复它并不是一件容易的事，所以你要耐心等待。
第四类群体是补丁修复者。对他们的管理是最为困难的，因为补丁修复的工作只有在项目维护者允许时才能实现，而在这之前，补丁修复者需要做很多工作来检查安全隐患。对于项目维护者来说，他们一定要给补丁修复者更多耐心，因为审核所有的补丁并不容易，而且不是每项补丁都能被修复。我承认这一层关系是Python项目需要改进的，因此，我正努力将项目转移到GitHub上，使补丁的审核工作更加顺利。
其实，项目维护者之间也存在着联系。作为一个项目的直接代表，我们之间相互依赖，相互监督，同时也要支持其他用户试图维护项目的行为。而我们之间最棘手的问题就是达成共识，因为每个人的想法都会不一样。
对未来的期望
离开志愿者服务一个月后，我希望能对社区做些改变，以便下次我请假离开是为了去度假，而不是因为职业倦怠。接下来，我会把工作重心放在增加我与社区的合作上。
在与用户之间的关系问题上，我认为不用刻意去改变，顺其自然就好。我仍然会在空闲时间查阅用户发给我的电子邮件，以便最快地解答他们的问题。（我通常选择晚上和周末码代码，不过也得看心情。）
而我与bug提供者的关系，之后将会出现很大的改变，因为我打算停止修复bug。虽然我很感激他们愿意花那么多时间来找bug，但修复bug是件很基础的工作，却需要花大量的时间。所以我决定把它留给那些技术初学者去做，当是实践学习，然后把我的时间花在更重要的事情上，比如维护社区内的另一种关系。
而这另一种关系就是我与补丁修复者之间的关系，我不断地改进Python软件工程实践，以便其他人也能有机会学习Python源代码（这也是我要将项目转移到GitHub上的原因）。所以，如果我把时间花在了修bug上，我就没时间做项目，也没有时间进行 Python 的协作和维护工作。因此，放弃bug修复，而专注于维护与补丁修复者之间的关系，不仅给了用户学习与实践的机会，也给了Python项目提升与发展的机会。
至于我与项目维护者之间的关系，我认为不会有什么变化。除了就某个技术问题进行讨论时，可能会出现场面失控的情况，其他时候，我们的关系还是很融洽的。
这一个月的思考：
我清楚地认识到开源就是对一个项目进行合作，然后相互分担维护的工作；
如果有人向我提出来了不合理的需求，我没有义务必须对他进行回应，因为他不是我的雇主；
为更好地分摊项目维护工作，我需要停止bug修复工作，而专注于补丁审核。
原文：Why I took October off from OSS volunteering