Redis 作者 antirez：开源维护者的挣扎
|
这两天，一篇名为《开源维护者的挣扎》的文章被敏捷顶至 Hacker News 首页，这是 Redis 作者 antirez 宣布的最新博客。 几个月前，一名开源项目标维护者向 antirez 发邮件，倾吐本身苦心维持项目多年，这或多或少带来了一些生理上的承担，因此特来寻求提议。antirez 暗示谈不上给出提议，但可以写一篇博客文章来分享对此事的观点。颠末重复的思考和自我说明，他坦承“维护一个开源项目会带来爱好”，但“也有悲观的一面”。接着，antirez 从以下几方面临此睁开描写，下边直接回收第一人称： 泛滥效应当我在项目标早期收到关于 Redis 的电子邮件时，如故有足够的时刻，可以或许专注于对方在动静里试图表达的内容，并在细心思量后回覆本身的真实设法。 然而，当一个项目到达像 Redis 这样的风行水平，而且人与人之间的交换由于新的交际器材而变得更为轻易时，作者收到的动静、issue、PR 和提议的数目也将呈指数增添。随之呈现一个广泛性题目，至少从 Redis 的环境来看是这样，即没有足够多及格的人去查察并处理赏罚社区中的这些信息。 大大都人试图以错误的方法办理它：原帖宣布两周后若无回覆就封锁 issue、封锁全部不明晰的 issue，以及其他相同直接把邮件列表所有标志为已读的做法。
究竟上，处理赏罚社区反馈必必要耗费足够的时刻，不然只能“冒充”项目没有未办理的题目。为开源项目标每个子体系配备全职事恋职员是奏效的，但很难实现。 那么接下来会产生什么？你将开始思量哪些该被优先处理赏罚而哪些不是，你将由于本身忽略了太多事物和人而感想不安，孝顺者也会以为你是一个隔山观虎斗的人。这种气象其实是很伟大。 凡是来说，应该首要先办理要害题目，忽视全部新的对象，由于新的对象还未能进入焦点，谁想拥有一个陪伴着更多 PR 和 issue 的代码库呢？ 脚色转换Redis 风行起来后，我的事变更多地转变为了查察 PR 和 issue。这个中确实有些人会比我做得好，但大大都人的孝顺仅处于均匀程度，只是办理给定题目而已。 当我计划 Redis 时，我倾向于将它视为一个整体，事实这么多年来一向在写这个对象。以是实际是，善于的对象每每不再偶然刻去做。 我的办理要领是，给本身几周时刻遏制查察 PR 和 issue，转而去编程可能计划，这才是我真正喜欢和享受的。但这反过来又给我带来了更大的生理压力，只在做本身喜好的工作时做得很好，令人感受很糟糕。
时刻长时刻在一个项目上事变有两个题目，至少对我而言是这样。 第一个题目是，在 Redis 之前，我从未有过在每个事变日都事变的履历。我老是干一周，停两周，接着再干一个月，然后消散两个月。做缔造性事变必要充电，以得到新的能量和设法。 但开始收到在 Redis 事变的酬金后，道德类型我不能再依照已往的模式，以是我强制本身凭证正常的时刻表事变。这对我来说无比挣扎，并且我确信本身做得比现实能做到的要少。今朝仍未找到办理要领，跟公司申请回到原先的事变模式是不管用的，由于社区的运作方法云云。 另一个题目是，从精力上讲，在统一个项目中举办大量事变也是一件伟大的工作。我已往经常每六个月换一次项目，而现在十年来都在做统一个项目。我试图通过在 Redis 中陈设子项目来留存缔造力，先后做了 Cluster、HyerLogLogs 和一个已放弃的磁盘存储项目，此刻在做第四个。 不外，最终照旧要回到 issue 和 PR 页面，天天一再同样的事变。 惊骇我天天都在畏惧本身失去对 Redis 的技能率领力，不是由于我以为本身在计划和成长 Redis 方面做得不足好，而是由于我的方法与大大都用户想要的，以及大大都 IT 职员对软件的信奉纷歧致。 因此，我不得不在我以为的优越计划、成果集、开拓速率、项目局限，以及大大都用户所祈望的内容之间保持均衡。 荣幸的是，有必然比例的 Redis 用户完全领略 Redis 的方法，以是我至少时不时会获得一些慰藉。
摩擦尽量我以为措施员中的大好人占比多过其他规模，但总照旧有一些混账。作为一个受接待的开源项目标率领者，将不得不面临这些人，这也许是我在 Redis 开拓进程中碰着的最求助的工作之一。 徒劳我信托软件固然很棒，但不会像一本存活了几个世纪的书一样巨大，这毫不是由于它自己欠好，而是由于个中的副浸染，而且，它终将被更有效的软件替代掉。因此偶然我会认为本身做的统统终将都是徒劳的。 只逗留在软件编写自己，而不思索软件“大创意”的人，真的能缔造新的符号吗？
【编辑保举】
点赞 0 （编辑：河北网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
