最近知名 Rust 框架 actix-web 的作者宣布不再做开源，在 Rust 社区内外都引发了不少关注。我个人并不使用 Rust，但同为开源维护者，对于这件事有很多感同身受的地方。我对于事情的孰是孰非不想多做评论，对前因后果感兴趣的读者可以自行搜索，这里主要借这个事件谈谈独立开源维护者的心理建设问题。
大部分开发者开始做独立开源（非公司项目）的时候，都是出于很单纯的动机：我写了一个很有用/有意思/没人做过的东西，分享出来给大家看看，要是有人点几个 star 那就美滋滋了。一些负责维护公司项目的同学可能也因为对项目投入了很多，对于项目有着超乎工作责任之外的感情。这些项目里有一部分会获得超出作者预期的增长，然而随之而来的也是超出预期的维护责任：突然你发现自己每天要面对一堆只增不减的 issue，千奇百怪的用户需求，处理不完的用户提问，人们开始拿你的项目跟其他项目比来比去，对你的代码甚至是言论指指点点，甚至为此撕逼... 你工作外的时间基本上都给了开源，然而与此同时，你的项目并没有给你带来什么除了自豪感之外的实质利益，你慢慢开始怀疑自己到底值不值得继续为这个项目投入这么多精力。有时候你觉得，支撑你继续下去的唯一动力仅仅是不敢面对辜负社区的罪恶感...
如果你看到这里有感同身受的感觉，那你急需一些心理上的调整来帮助你摆脱现在的状态。这曾经也是我在过去某个阶段切身的感受，所幸在慢慢摸索之后，我找到了一些让自己能够健康地面对开源的策略，希望能对其他独立开源维护者有所帮助。
认清自身定位
不同的人做开源的初衷不一样。如果你一开始做这个项目完全是玩票的，没有想过要承担那么多责任，那么干脆放手把项目交给他人维护不失为一个好选择。如果你觉得放不下，那么大抵是因为你觉得这个项目对你来说还是有潜在的价值。这个时候不妨问问自己，你希望从这个项目里得到什么？举例来说：
- 单纯满足自身的技术兴趣（比如 “我就是要写一个最快的 XXX 实现”）
- 建立个人技术知名度，创造更多机会。在面试的时候有一个拿得出手的开源项目会带来很大优势，而且优势和项目的质量成正比。
- 通过赞助、广告、卖 license 等等方式将项目打造成一个被动收入来源。
- 围绕项目找到一个公司愿意付钱的服务，进行商业化运作。
这些都是完全合理的目标，没有高低之分。只要符合 license，用开源赚钱完全没有问题，没有理由因为所谓的 “开源精神” 所以不能谈钱这样的说法。但你需要明确你想要达成的目标是哪一个，以及你愿意为这个目标投入多少。如果你觉得你愿意为那个目标付出现在所投入的精力，那么就努力继续下去；如果你觉得不值得，那么就果断放手。或者，你可以通过一些手段来减少自己需要投入的精力，从而让这件事情重新变得 “值得” 起来。
明确用户预期
在认清了自己做项目的目标的前提下，更重要的是要对用户明确这一点。很多时候，维护者和用户之间摩擦都是源于双方的预期不一致。维护者觉得自己出于兴趣的作品免费给你用已经很好了，你还想怎样？一些用户则觉得你网站做这么 fancy，还到处宣传，简直就是求我来用的嘛，现在出问题了居然又甩手不管？
以 actix-web 的作者为例，他的动机其实主要是满足自身的技术兴趣（我要用 Rust 写出一个最快的框架），所以他其实并没有做好在社区互动和生产级别的稳定性支持这块投入大量精力的心理准备。而一些用户认为既然 actix 想要被用在生产环境中，那就有责任避免滥用 unsafe 来提高稳定性。作者内心可能根本就没有以 “被大量用于生产环境” 为目标，但在推广项目的过程中却给人留下了这样的印象，这种期望值的错位是导致矛盾的根本原因。
要避免这种情况，最好在项目的 README 里清清楚楚写明白这个项目的初衷。另一方面，维护者也需要对自己诚实一点：玩票就写明是玩票，实验就写明是实验，除非你真的做好了为项目的成功付出汗水的准备。甚至于 “本代码仅供交流学习，不提供维护承诺“ 也是完全 OK 的。但如果是个 KPI 项目却吹得天花乱坠... 那也怪不得社区喷你。
限制信息摄入
做开源维护最有负担的一点就是仿佛变成了全天候客服，尤其是当你的用户遍布世界各地的时候，一天 24 小时都可能收到 issue。当 issue 的频率到了一定程度以后，就会开始影响你的正常工作生活节奏，甚至让你觉得你的生活在被 GitHub 的 email 牵着鼻子走。解决这个问题可以从两方面入手：
- 从源头减少无用信息。我们在 Vue 的主要仓库上都在 issue template 中写明了必须用我们的 issue reporting app 来提交 bug report，强制要求提供重现，不符合规范的 issue 都会被 bot 直接关闭。在提交的过程中我们也尽可能引导用户一次性提供足够的信息，从而避免来回索要细节和重现这种极其浪费时间精力的工作。你可以视项目 issue 数量相对放宽松要求。
- 从被动接受变为主动抓取。关掉新 issue 的推送通知，这是让你重新掌握生活节奏的关键。给自己定个时间，在安排好的时间批量处理 issue，你会发现这样效率比零碎地来一个处理一个效率高得多。你可以在邮箱里设个 filter，自动把 issue 邮件归类，或者干脆 unwatch 仓库，只有在要处理 issue 的时候才上 GitHub。另外，不建议整天泡在项目的聊天群里。聊天群是比 issue 更碎片化的信息来源，而且信息的重要度通常更低，应该作为没事的时候才刷的最低优先级。
从我个人的经验来说，让生活完全围绕着开源是非常不健康的。你需要给自己创造 “完全不用去想自己的项目” 的时间，去做和开源无关的事情。如果你发现自己做不到这一点，那你的精神健康长期下来一定会受到影响。一开始这样做的时候你可能会有一些戒断症状，总是担心项目出了什么状况你后知后觉，但实际上... 绝大部分的项目没那么重要，没有什么问题是不能等一等的。如果真的有不能等的问题，会有人 at 你的。
事情没你想象的那么糟
开源维护者接受的信息中，正面/负面的比例是非常失真的。绝大多数 issue 都意味着你的代码出了什么问题，但很少会有用户没事主动跑来跟你说谢谢。很可能现实中 99% 的用户都用得好好的，但你却天天跟那 1% 遇到问题的在打交道。在做 Vue 的早期，我一度觉得很郁闷，因为几乎每天都有人在报 bug，有时候一天 bug 修下来会对自己的代码自信程度降到一个谷底，觉得自己怎么制造了这么多问题，甚至一度陷入了 burn out，快两个月几乎没有写任何代码。但是当我重新开始维护的时候，发现世界也没有塌下来：issue 是多了不少，但团队和社区帮忙做了很多原来我自己急着做掉的事情，捋一遍真正算 bug 的也就那么几个，大部分也都已经有了 workaround；用户数依然稳步增长，还多了几个赞助商。我发现其实我不用把自己逼这么紧，这个项目也可以活下来，甚至也能发展得很好。关键的是要找到一个合适的节奏，才能让自己跑得更远。
从另一个角度来说，一个用户多的开源项目一定是为世界创造了正面的价值才会吸引这么多用户，bug 是正面价值上的小瑕疵，而不是负面影响。修 bug 是在让你的创造变得更完美，而不是在弥补过失。多提醒自己保持这样的心态，也可以减轻不少压力。
别跟喷/黑子一般见识
用户一多，总会有些嘴巴臭的。如果喷回去，会潜移默化地给社区的风格定下基调，导致社区火药味越来越重，也会吓跑一些潜在的贡献者。所以如果可以，还是尽量不卑不亢地处理：先对事不对人把技术问题搞清楚，然后警告对方注意用词，再犯就拉黑（GitHub 也是有 block 功能的，organization 账号也有）。一般会因为技术问题出言不逊的人，要么是现实生活不太顺需要在网上发泄，要么是情商有问题不会好好说话。这类人咱们可怜一下就行了，喷赢他并不会给你带来什么好处。你并不差这么一个用户，实际上少一个这样的用户更好。
至于非用户在知乎这样的地方黑你... 想明白一点就好：如果没人黑你，说明你还不够火。做好自己的事，让他们酸去吧。
