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