我在开源社区的 4 年运营经验

我的开源故事开始于 2014 年，当时我从参加 Hacker Hours 之类的免费技术聚会中受益匪浅，很多开发者聚在一起，在编程问题上互相帮助，这种知识共享文化对一名刚从校园毕业，且没有大型协作经验的毕业生来说是非常有趣的。

虽然这种技术聚会很好，但我发现这种方式比较容易分散注意力。偶然间，我发现与其他开发者通过 Google Hangouts 屏幕共享是解决分散注意力问题的绝妙方法。我发现许多初学者很容易陷入编程的细节中，但是与其他人结伴是更快调试这些问题的有效方法。此外，通过网络连接，随时随地都可进行“远程聚会”，这将有助于因日程安排或地理问题而无法参加技术聚会的人。

接触开源

最初，Google Hangouts 由一系列 Google Group 邮件列表组织而成，形成了一个很小的数百人的社区。几个月后，我们发现需要一个合适的平台来主持远程学习课程。因此，我为该项目启动了一个基于 MeteorJS 构建的 GitHub 存储库。

现在，CodeBuddies 已有 5 年历史，并且已经成长为国际社区，仍然本着自愿且非营利的原则。开源是我做的最好的事情。尽管它不是传统的开源库或工具，但我所经历的许多学习和挑战与其他开源维护者完全一样。

接下来，我将分享维护此开源项目汲取的十个经验。

第 1 课：向贡献者学习

做开源，可以从其他贡献者那里学到很多。我清楚地记得两个核心贡献者（distalx 和 d3vild06）在项目早期就教了我两个基本准则：

• 不要让贡献者直接 push 到 master，而是 fork 项目，然后提 PR；
• 务必评审代码，然后再合并。

过往，我是没有这种意识的，但我接受了上述反馈，并继续向每个新人学习更多的课程，将他们的观点、问题和技术知识的多样性带入项目。

我从贡献者那里学到的很多东西甚至都与软件无关，而与项目工作流程或社区相关。 项目最开始的一个贡献者（olii）大大改善了早期的 CONTRIBUTING.MD 文档。 我学会了如何设置 CircleCI，以及如何使用 Invision 等设计工具。

提示：不确定如何检出 PR 的 git 分支？ 请遵循以下命令：

我通过在 codebuddies.org/hangouts 上安排视频群聊来为自己的项目提供技术协助，该视频群聊主要是通过代码库吸引新的贡献者。 由于以下原因，我建议其他开源项目维护者也做同样的事情。因为这为新贡献者提供了一个提问的渠道，确实可以帮助 git 和 GitHub 新用户。此外，我发现对话可以帮助加强联系。许多参加过代码演练的人已经成为目前主要的贡献者和朋友。

第 3 课：充分利用 GitHub 的功能

我将分享一些有关使用 GitHub 的快速技巧，比如利用 GitHub 的问题和 PR 模板；保护 master 分支；使用 CI 集成，以便在合并新提交的 PR 之前对它们进行检查；认真考虑在 GitHub 提交的问题中添加易于搜索的标签。在 CodeBuddies 上，贡献者（billglover）亲自负责清理标签，并引入了一种更有效的问题标签系统。

确保贡献者就正在处理的问题进行交流。例如，在 Hacktoberfest 业务繁忙的时期，多个人可以很容易地为同一问题提交 PR，最终导致彼此冲突。在 CodeBuddies，这是我们为减少问题冲突而制定的政策：

• 如果贡献者发现错误或尚未提交功能请求，请要求他们提交。
• 请和贡献者就分配问题进行沟通。
• 维护者将重新标记该问题，从标签开始。
• 如果提出问题的人在两天内没有更新，则维护者会将问题重新标记为再次需要帮助标签。

第 4 课：贡献不一定全部是代码

贡献不必全部都是代码。 在 CodeBuddies 上，我们使用“所有贡献者”插件，该插件可识别贡献者为项目提供的替代贡献，例如设计、文档帮助、项目管理、内容、贡献者演练、请求审查以及有关 Github 上问题的讨论。

如果没有 adachiu，那么 CodeBuddies 就不会有今天，因为 adachiu 设计了 CodeBuddies 的徽标和网站的许多部分。

通常，我还尝试为贡献者提供他们想要的方式添加到项目中。 例如：由 billglover 创建的 Buddybot，可让 Slack 社区中的用户将消息标记到私有管理员频道；由 bethanyg 在 stain88 和 angelocordon 的帮助下创建 Greetbot 向 Slack 上的新成员发送欢迎消息，并允许用户向该机器人请求编程资源；Gaurav 编写了一个 Slack 集成，使成员可以从 Slack 内部安排有关 CodeBuddies 的视频群聊。

最终，如果没有无数人的参与，他们将不会成为今天的社区，这些人提供反馈，在 Slack 上互相帮助解决编程问题，并发起群聊，邀请世界各地的开发者一起讨论。

我记得一个周末，我随机参加了一个学习群聊。事实证明，参与者来自澳大利亚、尼日利亚、芬兰、中国和印度。 每个人都在不同时区随机地在同一小时自由活动，并且在增进对技术概念的理解方面有着共同的兴趣，这是因为有人在网站上安排了时间和空间，这些贡献者也提供了帮助。

第 5 课：API 发生变化

开源项目所依赖的依赖项在整个项目过程中可能会发生很大的变化。这个过程还要密切关注 Github 安全警报，这些通知通常会在存储库顶部告警，其他工具可以帮助及时了解安全警告和依赖项升级：

• Snyk
• Greenkeeper
• Dependabot

第 6 课：公共工作

从本质上讲，从事开源工作是公开的，但也可通过其他方式公开工作。例如：

• 撰写博客文章（如 Tumblr）；
• 写 ReleaseNote；
• 视频采访社区成员和核心贡献者；
• 在处理代码库时发布到到 Twitch；
• 在 Slack 或 Discord 社区中创建开放渠道，以邀请成员并讨论项目更新。

上述所有，可以帮助社区更好地了解项目路线图，更好地招募新的贡献者，并阐明迄今所取得的进展。

第 7 课：金钱不是感谢贡献者的唯一奖励

我在 2017 年和 2018 年参加的 SustainOSS（我在 2017 年和 2018 年参加的开源会议）上的一个话题是如何为开源项目提供财务支持，Nadia Erghbal 在 2016 年为此撰写了出色的指南。

值得分享的是，如果项目没有很多钱，可以通过多种方式奖励贡献者。首先要记住，金钱并不是人们在贡献时一定会期望得到的回报。做出贡献的常见原因包括：

• 培养技术技能或探索新技术的机会
• 相信项目的总体目标
• 与他人合作的机会
• 在未来的工作面试中有机会谈论他们的工作

关于非金钱奖励的主要提示是：在发行说明中感谢贡献者，查找愿意捐赠非货币性物品的赞助商，例如网站托管（感谢 DigitalOcean，MongoDB Atlas 和 Netlify），课程促销代码（感谢 egghead.io 和 Tyler McGinnis），也可以抽奖给贡献者。如果碰巧拥有少量预算，那么可以使用一些钱来购买 logo 贴纸感谢核心贡献者。

第 8 课：社区管理和项目管理技能也很有价值

作为开源项目维护者，您可能会戴上许多头衔：

• 项目经理 (project manager)
• 产品经理 (product manager)
• 工程经理 (engineering manager)
• 社区管理员 (community manager)
• 代码贡献者（code contributor）

开源本质上是陌生人一起工作和众筹代码。作为维护者，可能会遇到一些需要调解的冲突，例如人们在技术指导上存在分歧，以及主要通过文本交流的人们之间的误解。这就需要制定路线图，传达愿景，确定问题的优先级，加入新的贡献者，学会委派并激发新兴的领导者。

老实说，我没有打算参加所有这些工作。过去几年，随着社区的发展，以及从关心该项目的成员提供的想法和反馈中学到的知识，让我感到满意。因此，在某种程度上，社区给了我学习的机会。

第 9 课：倦怠

事实上，倦怠是真实存在的，尤其是维护开源项目并不是你的全职工作时。对于一般的辅助型项目，建议弄清楚要从中获得什么，是因为正在努力学习还是因为喜欢新任务，喜欢与为该项目做出贡献的开发者合作等。

第 10 课：永无止境

我花了一段时间才能接受的一点是，CodeBuddies 永远不会“完成”。最终，每个开源项目都面临这个问题，类似#sustainnoss 这样的社区正在探索的关键问题是如何使开源项目更具可持续性。