关键词：
导读：
作者 Brett Cannon 是 Python 的核心开发人员，从2002 年开始，14 年来自愿用业余时间为 Python 语言添砖加瓦。但这种活雷锋行为并没有得到开发者们的理解，很多人甚至用命令的口吻要求活雷锋们再苦再累也得免费为自己劳动。
很多人会命令开源项目维护者赶紧修复这个或那个 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修复工作，而专注于补丁审核。
独自坚持17年，aardio作者：“因妻子患癌，再无精力维护项目”
...17年不断迭代、始终积极更新的aardio，皆由作者一人坚持开发并维护。专注于桌面软件开发的aardio，体积仅有6.5MB，却提供了惊人数量的开源标准库、扩展库——所有库由纯aardio代码实现，基本都由作者一鹤一人编... 查看详情
spring官方为什么放弃springsocial项目及替代方案
原文地址：spring官方为什么放弃springsocial项目及替代方案 springsocial1.6之后官方不在维护该项目,springboot2.x之后也不在提供springsocial的Autoconfiguration.原因: https://spring.io/blog/2018/07/03/spring-social-end-of-life-announceme 查看详情
rn从上手到“放弃”(代码片段)
...新技术，2015年Facebook开源，到现在已经45个年头，一直在维护当中，但是至今未发布v1版本，目前已经更新到0.59。该技术目标：跨平台实现原生应用。GitHubstart数目：77602（2019-5-29）。正文1、项目预览现在已完成的功能展示：入... 查看详情
docker从入门到放弃(代码片段)
Docker介绍Docker容器技术于2013年作为开源Docker引擎推出。是一个开源的应用容器引擎，基于Go语言并遵从Apache2.0协议开源。基于Linux内置的Namespace和CGroup等系统内隔离机制而抽象出来的一种轻虚拟化技术。为什么用Dockerl更快速的交... 查看详情
维护开源项目太难？redis之父支招：做你想做的
前不久，开源软件管理解决方案供应商Tidelift对开源项目维护者展开调查，结果显示开源维护者大多做着一项钱少事多压力大的工作：几乎一半的代码维护者没有工资；工作量繁重；需要承担很大压力，甚至吃力不讨好；超过一... 查看详情
开源框架概述
为什么要使用开源框架1.提高开发速度2.提高开发质量选择开源框架的原则1.聚合性框架一定要放弃.例如Afinal，xUtils *大而全的框架容易导致牵一发而动全身.可读性差,耦合高,难扩展.2.lastcommit超过一年以上或者issues一大堆没有... 查看详情
移动app开发框架盘点2：web移动前端框架大全
...架，这一次虽然有大量项目停止维护，但是也有很多项目坚持了下来，而且还涌现出了一批新项目。大厂占了主导，因为这些年大厂在移动开发上的需求，远高于其它方面。个人项目要坚持确实不易。本 查看详情
近期（2017年04月14日22:45:27）遇到的问题
...app服务端（即将完成第一版）、短信平台（开发初期）、维护中的项目:供应商余额查询、微信公众号、流量平台（协助）、流量后台（部分参与）。除了协助与部分参与的，其他的项目都是我独立开发后端的，一有问题就要找... 查看详情
wpf的开源项目都有哪些
...骨子里的爱那是离不开s 参考技术C我依然邀约幽篁之风我自愿放弃治疗我报名当图书保管员无声无息哼唱着歌 查看详情
操作系统的“冷板凳”要坐多久？万字长文解读16年开源老兵的坚持
想知道内核研发是怎样的体验？操作系统的“冷板凳”得坐多久才有春天？本文对话龙蜥社区理事长马涛，畅所欲言聊开源，一起来看看那些开源润物细无声背后的故事以及龙蜥社区运营的道法术。高门槛的Linux... 查看详情
送给迷茫的昨天（2019年底至2020年初）
...了。想得到别人得不到了，就得做到别人做不到的。2020坚持锻炼身体，坚持学习。 查看详情
git简史
...核开源项目有着为数众广的参与者。绝大多数的Linux内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到2002年，整个项目组开始启用分布式版本控制系统BitKeeper来管理和维护代码。到了2005年，开发BitKee... 查看详情
git详解
...核开源项目有着为数众多的参与者。绝大多数的Linux内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到2002年，整个项目组开始启用一个专有的分布式版本控制系统BitKeeper来管理和维护代码。到了2005年... 查看详情
dataease开源项目githubstar数量超过1000！
截至2021年7月30日14:40，FIT2CLOUD飞致云旗下开源项目——DataEase开源数据可视化分析平台GitHubStar数超过1000个！ 查看详情
dataease开源项目githubstar数突破8000！
截至2022年11月14日9:00，FIT2CLOUD飞致云旗下开源项目——DataEase开源数据可视化分析平台GitHubStar数超过8000个！ 查看详情
两年摸爬滚打springboot，总结了这16条最佳实践(代码片段)
...次列出了最佳实践，排名不分先后。1、使用自定义BOM来维护第三方依赖这条实践是我根据实际项目中的经历总结出的。SpringBoot项目本身使用和集成了大量的开源项目，它帮助我们维护了这些第三方依赖。但是也有一部分在实际... 查看详情
两年摸爬滚打springboot，总结了这16条最佳实践(代码片段)
...次列出了最佳实践，排名不分先后。1、使用自定义BOM来维护第三方依赖这条实践是我根据实际项目中的经历总结出的。SpringBoot项目本身使用和集成了大量的开源项目，它帮助我们维护了这些第三方依赖。但是也有一部分在实际... 查看详情
obs-studio开源项目从入门到放弃obs-studio项目简介和架构
...threadsglad总结技术参考前言obs-studio是一款跨平台、免费且开源的用于视频录制以及直播串流的软件。国内绝大多数的直播推流客户端多是基于obs的二次开发的，对于流媒体开发工程师是一个非常不错的值得学习的开源项目。... 查看详情