James Long 是 Mozilla 的工程师。他在这篇文章讨论了开源项目的两种角色 发起人与 维护者。没有报酬的情况下,有多少开源项目的维护者能持之以恒?
发起人与维护者
现在是周五的深夜,妻子已经睡着了,我终于能够抽空看看那些拉取请求,这些拉取请求来自我去年放上 GitHub 的一个旧项目。女儿早上七点半要起床,所以我最好不要熬夜太晚。
自我上次查看之后,新增了 9 个问题,以及 2 个拉取请求。好消息是大部分问题都可以关闭,而且拉取请求也无关紧要。呃,不好,有一些重大的更改。我不得不重新考虑这些更改,并将(带着礼貌的态度)参与一场长时间的讨论。这是一个突破性的更改,但他们并没有更新文档,所以我们必须弄清楚,如何通知每位用户去升级。
我应该给项目建立一个更好的(推送)方式,来通知我有新的问题和拉取请求。但是仔细一想,骗谁呢,这只会让我更加精疲力竭。我根本没有这么多时间来回应这些(问题和拉取请求)。至少现在,当我在焦头烂额忙着其它事情的时候,我可以假装它并不存在。
我为什么要这么逼迫自己呢?
诚然,我的代码已经帮助了很多人,但随之而来的维护负担却也十分严重,尽管它本身只是一个小项目。如果它变得更加流行(尽管我放在 GitHub 上的个人博客比较冷门,还不怎么使用,都已有超过 1000 颗星了,天啊?!),有更多的用户来使用它?那么要做的事情就更多了。从此它会变成一个每周 10 小时的工作。
我非常佩服那些将大量时间免费贡献给开源软件(OSS)项目的人。我不敢想象有多少无趣的免费工作正在进行。人们非常乐于喜欢帮助别人和社区,这件事情本身很棒。
我也喜欢这样做,但是有了妻子和女儿(而且马上要有第二个女儿),再加上一个本已高强度的工作,基本不可能办到这一点。而我在 Mozilla 的工作也基本上就是完全的 OSS 工作。
我认为自己能坚持下去的唯一理由,是因为我喜欢发起一件事。
每个人都喜欢做发起人,但我想做出点影响力,做出点贡献。将作品放到 GitHub 上很容易,而且如果没有人使用它,你都可以不用管它了,但这样做不会产生任何影响力。我想让人们看看我做出的东西,能够从中学到些什么,甚至能够使用它。通过编写可以应用到生产环境的库,我帮助人们学习 React、React-Router、传感器、清洁宏、动画等大量东西。
但这也会带来负担。
一旦人们在生产中使用你的代码,你还要继续维护它吗?
你可以说不,这是你的权力。但大多数时候,你想要看到你的想法不断成长、进化。问题是,要维持这样的动力,背后需要付出大量的工作。
任何一个项目都要有两个角色:发起人和维护者。人们可能在生活中同时扮演着这两个角色,但出于某种原因,我发现对于单一的项目而言,这两个角色一般对应不同的人。发起人擅长在不一样的角度(方向)迈出重要的一大步,而维护者擅长保持代码存活。
另一个很大的区别是,项目发起人往往只有一个,而最终会有多个项目维护者,这是因为单独一人无法支撑起整个项目。随着它越来越受欢迎,会出现越来越多的问题、拉取请求以及其他各种请求,两者之间呈线性递增的关系。当项目人气到达了新的阶段,就必须增加新的维护者,而理想的情况是来自现有的重度用户。
正是因为一个人无法支撑起整个项目,所以发起人自一开始就容易陷入一个令人绝望的循环:他/她拥有所有这些好的想法,但随着一些想法逐渐得到实现,会受到越来越多(来自他人的)噪音干扰,这使得未来的想法难以实现。关键是,你要不忘记现有的项目,要不为它们找到维护者,而后者通常不是一个能够很快实现的任务。
我本人绝对是一个发起人。我对万事万物都存有兴趣(好奇心),并不专注于几个集中的领域。我维护这个库的时间已经长达数年,但赶着在周五晚上处理积压留存的问题,总是让我怀有巨大的愧疚感。
从现在起,我准备明示,由于我放上 GitHub 的代码是实验性的,我将不会回应任何的问题或拉取请求。如果我确实发布了一个可以应用到生产环境的库,说明我已经想到了要请谁来维护。我不想再让自己背上第二份工作了。:)
这是我想对所有维护者说的话:正是他们在幕后从事各种费力不讨好的工作来保持代码存活,包括编写文档、编辑版本、注册域名等等。
哎,今晚要补救的问题还挺多的,也许我只要将废弃声明( DEPRECATED )添加到 README 中就能解决一切了。
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/tech/linux/55588.html