高效参与开源的诀窍

【前言】本文是我在 2021 年供职于 PingCAP 作为开发者社群负责人期间的感悟。这几天连续讨论了开源的动机和可持续性相关的主题，让我觉得可以把这篇文章稍作修改后发在推特上分享。其中大部分观点经过五年的考验仍然有效，常看常新 🤣

---

大部分想参与开源社区的人都会面临的一个巨大挑战，那就是缺乏时间。本文试图提供一种方式，帮助想要参与开源社区的同学高效利用有限的时间。

在一个开源社区里，维护者（Maintainers）需要关注的范围比参与贡献者（Contributors）要大得多。本文分别讨论这两类人群适用的参与开源社区的技巧，以减少过程中的摩擦，并提高时间利用率。

Contributors

第一步要加入社区

参与开源社区的第一步就是加入社区。加入社区的方式有很多，可以订阅邮件列表，关注开发活动，参与技术或非技术讨论，等等。很多希望参与开源社区的人迟迟迈不出第一步就是忽略了自己首先要加入社区，跟社区建立起联系。

一个典型的错误做法是：完全不顾开源社区是开发开源项目的主体，一头钻进技术细节里，暗搓搓地做一个“大功能”，然后希望社区尽快合并这个补丁，让自己获得荣誉。

Linux 基金会在博文 Participating in Open Source Communities 里明确反对了这种做法。文中写到：

Some organizations make the mistake of developing big chunks of code in house and then dumping them into the open source project, which is almost never seen as a positive way to engage with the community. The reality is that open source projects can be complex, and what seems like an obvious change might have far reaching side effects in other parts of the project. Any significant change is likely to require some community discussion before it moves to implementation to make sure that there are no side effects and that the solution is aligned with the broader goals for the project. While you discuss it with the community, it can help to focus on the problem, rather than a specific solution, before you invest too much time in the creation of a body of code.

一个现实的例子，前几天有人问我，自己做了一个 Flink StateBackend 的实现，提交给社区是不是就能做项目管理委员会成员（PMC Member）了。这个问题属实把我整不会了：从来没有在社区当中亮相的人，突然出现并提出自己实现了一个“大功能”，在其他成员眼里跟民科没什么不同。绝大部分情况下，这种实现跟上游社区的开发节奏是脱节的，很难合回去。也就是说，闭门造车的形式自我感动地开发项目，即使花费了时间，大概率还是白忙一场。

刚开始接触 Flink 社区的时候，我就按照项目文档的提示订阅了 users 和 dev 两个邮件列表。实话说，最初的三个月，我基本看不懂他们在说什么。当时的我尽可能地读每一封邮件，从邮件里面引用的链接一个个点进去了解背景，混沌当中建立起对项目的初步印象。直到四个月后第一次提交代码，这个祛魅的过程才算完成。从此以后，我逐渐能够轻松地参与到技术讨论，也掌握了 review 的沟通习惯。

【批注】关于我参与 Flink 社群的故事，可以阅读《掉进兔子洞》一文了解详情。

嵌入推文（联网查看）

找到感兴趣的问题

要想利用有限的时间创造更多价值，最好的方法是找到一个感兴趣的问题，然后持续投入，直到问题得到解决。

一个典型的错误做法是强迫自己做自己不感兴趣的工作。这种情况下，由于内心是抗拒的，即使投入再多的时间，也几乎不会有产出。

可能有人会不理解，开源社区的 Contributor 都是自愿参与，如果不想做某个工作，不是不做就可以了吗？

其实不然，社区成员身处其中很容易感受到无形的社交压力。

一种情况是不懂得拒绝。知乎上有个问题《如何优雅地拒绝开源项目的 PR 邀请》讲的就是这种情况。我在回答里分享了一个自己拒绝 Flink 社区成员的 PR 邀请的案例。

另一种情况是错误估计难度，即自以为能搞定这个工作，做着做着发现不对，又不好意思改口说自己搞不定。应对这些情况的方法非常简单，直截了当地说明即可。这样就能解放自己，避免浪费时间。

另一个难题是，大部分开发者往往对有挑战性的工作更感兴趣，但从一个刚接触项目的 Contributor 到能够完成一个复杂任务之间有一道坎。

要跨过这道坎，同样需要积极采取行动，而不要独自纠结。首先可以从简单的工作入手，比如在阅读项目文档时发现的拼写错误。一个简单的贡献能带你走完整个 Contribution 流程。一回生二回熟，做其他有挑战性的工作也就不会在流程上踩坑。其次，这样做可以保持与项目维护者的交流，以了解现有逻辑的设计背景和演进过程。只有对工作涉及的逻辑有充分的了解，才能写出高质量的代码。高质量的代码也意味着更少的返工和不必要的争论，从而避免了时间的浪费。

【批注】在智能体编程（Agentic Coding）大行其道的今天，这一点既变得更简单，又变得更重要了。

说它简单，是因为上面说的所有这些事，都可以让 AI 带着你做。尤其是对一些简单工作的上手，只要你有心，比方我这几个月来在 Apache DataSketches Rust 和 Apache Asyncband (Incubating) 发的 Good First Issues 都可以让 AI 识别解决往上游推，也不用你手动解决 Git 设置和 Follow 仓库设置的规则等等事情。

说它重要，是因为大部分人就止步于 Autonomous Agents 能完成的部分，完全不在乎跟项目维护者建立联系。殊不知一直以来开源协同就是 Mentor/Partner 带进门，获得信任以后授予 Commit Bit 开始爆发产能的模式。

嵌入推文（联网查看）

建立与其他成员的联系

随着参与的深入，总有你一个人无法完成的工作。开源协同的价值在于跨越所属组织边界进行合作开发。合作的基础是成员之间的信任，也就是良好的关系。

开源社区是围绕开源软件建立起来的。但是并不只有软件本身带来技术价值，人与人的连结带来认同感和归属感，这些也能满足社区成员的需要。此外，相互信任的基础能很大程度提升价值创造的效率，例如减少浪费在同步和对齐上的时间。因此，建立并保持与其他项目成员的关系至关重要。

做到这一点的方式就是充分的沟通。同样，这需要以开放的心态对待平时的交流。不要把所有事情都憋在心里。不要纠结于想清楚所有细节再开始沟通，其他成员一时间内往往没办法追上你所想的所有细节。我的建议是，当你有一个初步的想法，也做了力所能及的调研，就可以整理一下，发布到社区当中征求意见。

沟通协作的过程里冲突在所难免。我在好几个项目里都别人讨论甚至争论过很多次技术问题，给别人的行为提过意见，也夸赞过好的做法。开源社区解决冲突的方式比较朴素，一般是有话直说，尽量客观地达成共识，按照流程约定做出决策。不用整那么多弯弯绕浪费时间。

举一个现实的例子：曾经有人跟我抱怨，提上去的 PR 被 Maintainer 挑战了，问我应该怎么回复。他怀疑 Maintainer 有偏见，抱怨很难跟 Maintainer 沟通。这样，大量时间和精力浪费在纠结这些臆想出来的问题上，自然会筋疲力竭，感觉在开源社区里寸步难行。很多时候，你可能直接问 Maintainer 是什么问题，甚至想办法用语音、视频，甚至面对面聊聊，很多问题都能迎刃而解。

【批注】当然，有些项目维护者就是很难沟通。这种时候要么是项目有其他维护者可以成为你的 Mentor 继续跟你合作推进工作，要不然也就到了 Fork 或者选择其他项目的时候了。

再有就是，我自己 Remote 工作五年，当前创业的公司全员 Full Remote 三年下来，我发现这个 Over Communitcate 的事情仍然是最重要事情之一，再怎么强调也不为过。

适合参与开源协同的工作

最后，相当一部分 Contributors 是某家公司的员工。这显然会影响到他们参与社区的动力和能力。

主要的挑战是：如果工作期间不允许参与开源社区，同时工作本身已经消耗了太多的时间精力，那么 Contributors 对参与开源社区也只能是心有余而力不足。

这其实是很长一段时间里，开源社区的参与在国内发展缓慢的原因：大量的开发者都已过度工作，下班只想躺平休息，没有动力再谈什么开源贡献。

不过，随着时间的发展，情况也在发生着变化。越来越多的公司采用更加灵活合理的工作时间，尤其是以研发为核心竞争力的公司。如果你所在的公司仍然要求超负荷工作，燃烧生命赚血汗钱，那么是时候找份新工作了。时代已经变了，就让这些公司被无情的淘汰吧。

另一个方向是考虑在工作期间参与开源社区。如果你确实喜欢某个开源项目，那么最佳策略就是找一份允许你全职投入这个项目的工作。这样的工作岗位如今并不少见。尤其是随着企业级解决方案越来越倾向于采用开源组件，企业对熟悉开源软件的人才的需求只会日益增加。如果找不到全职投入开源项目的工作，与之相关的工作也是备选方案。

不过，即使这份工作允许你全职投入开源项目，也并不意味着你能够参与开源社区。特别是当你的老板认为参与开源社区不能为公司创造价值的时候。面对这个问题，首先你可以问问你的老板，说不定他不这么觉得，那就省事儿了。如果你的老板确实难以理解，那你就得像兜售一个技术方案一样向他宣传参与开源社区的价值了。我在其他的文章里对这一点已经有不少讨论，你可以看看。

普适的时间管理手段这里就不展开介绍了，各种相关书籍和 GTD 方法论都很值得一看。

Maintainers

发展新成员

项目维护者相比参与者需要关注更多事情。

随着开源项目日渐复杂，开源社区逐渐成长，单靠一个人的力量很难处理好所有的事务。这个时候，就需要维护者适时地发展项目维护的队伍。

首先需要定义 Maintainer 头衔的含义。

实际上，大部分项目的维护是个苦力活，而维护者们就是一群承担这些工作的社区成员。Maintainers 可能会拥有合并 PR 的权限，在社区治理中能投票做决策，确定项目发展的方向。但是，这种权限并非特权。在一个健康的社区里，任何社区成员都可以做技术讨论，也可以就社区发展话题提出自己的观点。对于技术观点，客观上更加合理的方案理应被采纳。对于社区发展话题，维护者们一般也会吸纳建设性提议。

可能有不少人把成为 Maintainer 当成参与开源社区的目标，这是好的。如果你理解了 Maintainer 的职责，通过持续参与贡献积累了足够的信誉，成为维护者，为开源社区服务，这个头衔就是对你贡献水到渠成的认可。不过，大可不必过分纠结于这个头衔。这只是对你的贡献的一种认可形式，而不是唯一的形式。

Maintainers 的职责并不轻松，因此 Python 社区和 Apache 软件基金会下的项目社区都会有一个询问 Contributor 是否愿意成为 Maintainer 的流程。也存在 Contributor 拒绝邀请的情况，因为就像前面提到的，健康的开源社区里，只要提议是合理的，就能凭借其客观的优势胜出。成为 Maintainer 并不意味着在方案选择上有特权。

基于上述认识，我们引出下一个观点：维护者们在发展新的社区成员时必须有选择性。

这种选择性的主要依据是维护项目的需要，而不是追求数量或者过分在意 diversity 等等。这可以类比于开发软件的目的在于提供技术价值，而不是代码行数或所采用的编程语言的数量。

一个典型的错误案例是：公司员工被命令将公司掌控的某个开源社区的 Maintainers 的数量提升到某个目标。这种指标只关注数字而不关注具体的人，而且往往定得脱离实际。公司员工迫于指标压力很容易降低 Maintainers 的标准，逮到一个算一个的凑人头，或者为了 diversity 对不同背景的 Contributor 采取不同的标准。这样发展出来的 Maintainers 不仅不能分担项目维护的职责，还很有可能因为不胜任而引发新的问题。

【批注】早年间我跟某项目的 PMC Member 聊天时，对方提到某公司来的人频繁提名新的 Committer 导致代码可靠性下降，我当时的回复是：

It hurts when their contributions always need to revision especially trivial mistakes. If we elect a new committer while his/her contribution need more attention to avoid merged wrongly quickly, we lose the reason to invite the very person.

另一个典型的错误经常出现在个人项目上：当个人项目发展壮大，这位唯一的维护者想要发展新成员时，很容易陷入“要找一个自己的分身”的误区。 也就是说，新的 Maintainer 必须和自己一样能够关注到项目的方方面面。这是不对的。没有两个人完全相同。只要一个 Contributor 有足够的信誉，并且能在项目或社区的维护的某个方面上承担职责，他就是一个好的 Maintainer 人选。

不过，这里讲到的信誉是一个非常主观的概念，提名 Maintainer 的倾向每个项目也各有不同。

• Perl 社区最初由 Larry Wall 独裁。近年来，随着他逐渐淡出核心成员圈子，Perl 社区的治理实际上已经由 28 人组成的 Core Team 负责。

• PostgreSQL 社区由 7 人组成的 Core Team 和 28 位 Committers 共同处理所有工作。

• ASF 治下的项目有一套比较固定的治理模型。具体到每个项目，例如 Apache Pulsar 和 Apache Flink 会有自己具体的要求和倾向。

• Spring Project 社区的 Committers 都是 Pivotal 公司或 VMWare 公司的员工。但是它显然也是诞生于开源协同的作品。

• Linux Kernel 基本上还是由 Linus 独裁。同时，海量的驱动和架构支持由各自的 Maintainer 负责维护。可以参考 Linux Kernel Maintainers 页面。

• Netty 社区没有明确的规则。Trustin Lee 发起并独自维护了该项目三年。随后，Norman Maurer 和 Scott Mitchell 等少数几个人持续参与，成为 Maintainer 并共同维护 Netty 项目至今。

如果让我对 Maintainer 提一个基础要求，我会希望他通过在项目或社区中做出高质量的贡献来证明自己的能力，并且希望当前的 Maintainers 团队乐于和他一起工作。

结构化流程

除了增加项目维护人员外，另一个基本减少时间浪费的手段就是建立结构化流程。我们分点介绍其内涵。

第一点是直觉大于文档。

比如，对于托管在 GitHub 上的项目来说，help wanted 和 good first issue 标签是一个众所周知的约定。合理标记 Issue 能让 Contributor 按照过往的经验快速找到切入点。

我在修订 TiDB 社区的治理方案的时候，也是以跟 GitHub 开箱即用的功能亲和为主要目标之一。如果参与一个开源项目有太多新东西要学，那么 Maintainers 就有太多要解释的东西了。大部分人效率最高的路径是完全凭直觉做事，并取得好的结果。所以如无必要，请勿设立复杂的规则。

第二点是文档大于口述。直觉毕竟只能解决部分问题，对于特殊的或者需要强调的内容，明确记录下来作为文档绝对是个好主意。

不过文档的首要目的还不是记录流程，而是项目的目标，或者叫定位。这是每个对项目感兴趣的人都会问的问题，高水平的 Contributor 尤甚。他们不仅仅是想在开源社区里做简单的工作，更想成为一个伟大的或富有价值的项目的缔造者。如果你想为你的项目吸引到高水平的开发者，那么最好是确定一个清晰且令人振奋的目标，并将它展示在最显眼的地方。例如，Apache Flink 的定位是数据流上的有状态计算，其中有状态这点是开源世界里开创性的工作；PostgreSQL 的定位是世界最先进的开源关系型数据库；Elixir 语言的目标是构建可扩展和可维护的应用，等等。

其次是约定俗成的文档，包括 README.md 和 CONTRIBUTING.md 等等。其中一般包含项目简介，开始使用的方法，参与贡献的基本流程，以及指向更多文档的链接。大部分 Contributor 会尝试查找并阅读这些文档。如果他们能从其中解决自己的问题，就不需要 Maintainer 花时间说明了。至少，在有人提问的时候，直接发一个文档的链接，也能省不少事儿。

【批注】在 Agentic Coding 时代，这个论断仍然强成立。只不过 Agent 成了读这些文档的常客：它们被训练成 follow 这些最佳实践，并且比人更耐心的构建整理自己的上下文。

另一个值得强调的是行为准则（Code of Conduct）。提名新的 Maintainer 之前,最好确保被提名人知悉并理解社区行为准则。行为准则通常是一些涉及平等、尊重和避免冒犯的原则。虽然大多数开源社区很少遇到严重违反行为准则的情况，但是 Maintainers 应该对此保持敏感。这类问题一旦处理不当，很容易演变成政治斗争，甚至导致社区分裂或项目停摆。

最后是设计文档。Contributors 要深度参与技术贡献，需要了解相关代码的设计背景和演进过程；设计文档是最好的参考材料。良好的代码质量有助于避免 Contributor 在阅读源码时受挫，但项目固有的复杂度仍需要设计文档来辅助解释。如果代码质量和设计文档都缺位，想要深度参与技术贡献的 Contributor 就不得不指望 Maintainer 花费大量时间来解释和指导了。这点对于 Maintainer 也是一样的。当你想要做一个新的功能，如果没有好的技术文档，你也得懵圈，也得拉人反复对齐。

【批注】现在有 Agent 降低编码的成本，其实我们在 ScopeDB 及其依赖的开源项目里都贯彻了代码即文档的方针，几乎不需要什么复杂的设计文档。

这是因为设计都落实到具体的模块组织和命名上。此前，人来调整好这些结构和想命名是很费劲的，但是 Agent 并不觉得累。而设计历史完全可以让 Agent 从 PR 历史里翻出来，本地对话和集体讨论的结果也可以让 Agent 以 PR Description 等方式直接 Attach 上去，这样后面再去翻当时的决策会简单很多。

反而是固定的设计文档 Markdown 文件会快速腐化，成为错误上下文的来源。

第三点是避免私下讨论。有关项目和社区的讨论，唯一的信源应来自公开渠道。例如，ASF 治下的项目要求所有有效的讨论都应该发生在邮件列表上。例如，大部分托管在 GitHub 上的项目隐含了讨论应该发生在 GitHub 平台上。社区成员可能还会通过其他的沟通渠道辅助交流，例如微信等即时通信软件。但是，这些辅助渠道的讨论需要被抄送到唯一信源上，才会被认为实际生效。这样，Contributor 才能在无需了解诸多渠道的前提下获取所有有价值的信息。

这些公开讨论的内容以及表现出来的做事方式，就是社区当中的“活文档”。模仿是人类的天性，如果你希望别人遵循某种做事方式以减少冲突，那么最好以身作则，再带动更多的人跟随。前面讨论 Contributor 参与技巧时说过，加入社区并首先观察别人是怎么做的，是一种避免浪费时间的好方法。那么与之相对的，Maintainer 也要在项目维护和日常交流方面为此提供方便。

Open Communications: as a virtual organization, the ASF requires all communications related to code and decision-making to be publicly accessible to ensure asynchronous collaboration, as necessitated by a globally-distributed community.

**Apache Software Foundation (@TheASF) - **BRIEFING: THE APACHE WAY

第四点是考虑自动化。结构化的流程更容易自动化。当你的流程越来越结构化时，是时候考虑自动化它了。显然，无需 Maintainer 亲自动手的自动化流程能够减轻项目维护的压力。

同样，最好的自动化是符合直觉的。GitHub 平台提供了一系列自动化的支持。尤其是 GitHub Actions 发布以后，自动化的灵活性得到了进一步的提升。利用项目代码托管的平台提供的开箱即用的能力做自动化，能够最大程度的避免各种冲突。

自动化还应该建立在现有的成熟流程上，而不是凭空生造流程。好的案例包括：提交文档变更后自动部署文档页面，利用 merge bot 提高 pull requests 的 review 和 merge 效率等。

其中，后者的采用是有两面性的。许多代码提交极其活跃的开源社区也仍然不需要引入自动化流程。当然，测试基本是自动化的，至少有脚本。不过 review 和 merge 还是可以人工完成的。我比较认同的 merge bot 应该实现排队合并功能以及 roll up 打包测试功能。这两个功能在保证合入主分支的代码基于最新的主分支测试过的同时，减少了需要测试的次数和人为协调的负担。但是，有些 merge bot 强制要求 review 和 merge 走非常严格的审批流程，把这个过程变得复杂不堪，这是我非常反对的。所以在引入 merge bot 之前，请确保你清楚地知道它如何改善协作效率，并保留回滚的能力。

另一个典型的错误案例是 stale bot 的自动关闭功能。真的，没人喜欢这个功能。开发者来到社区是为了与他人建立联系，共同开发出好的软件，而不是为了被机器人支配。应对 Issue 或 PR 的积压问题，首先应该尽可能及时处理。其次，大部分积压的 Issue 都是无效内容，例如愿望清单和模糊的想法，这些只需要快速关闭即可。对于低优先级的 Bug Reports 的积压，既然问题是实际存在的，也不是 won't fix 的情形，凭什么关掉呢？如果当前的 Maintainers 积极主动地处理 Issue 和 PR 还是处理不过来，那么是时候寻找一个新的 Maintainer 了。

Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.

Collective Code Construction Contract - Development Process

流程自动化的标杆案例包括 Kubernetes 社区和 Rust 社区。在学习这两个社区的做法的时候，需要强调的是

1. 请关注这两个社区为流程自动化投入了多少人力。

2. 请关注这两个社区是在什么时候引入了何种自动化逻辑。

3. 请关注这两个社区的成员如何利用自动化流程。

4. 请关注这两个社区在流程自动化方面的异同。

5. 请关注这两个社区在推行流程自动化时的讨论，尤其是争议。

6. 请勿货物崇拜，直接照抄它们的方案。否则你会死得很惨。

既然 Rust 社区都不抄 Kubernetes 社区的方案，你为啥贸然就要抄？

日常事务

前面讲的是一些整体的做法，回到每个 Maintainer 身上，实际项目维护工作的大头其实是日常事务。

最常见的问题是开发的风险控制。开源项目通常会有自己的版本发布周期。有时候你希望下个版本能交付某几个关键功能或改进，而这些工作并不都是由你一个人完成。尤其是，你之所以想交付这些变更，是因为公司的要求，而开发团队包括并非公司员工的成员。这个时候就需要你做好项目的风险控制。

从公司员工的角度，我介绍过开源项目和商业公司独立运营的协同模型。运用这个模型，可以把商业上紧急的需求实现在 fork 仓库上，交付 hotfix 应对紧急情况。稍后，把改动 contribute back 到开源项目当中。这样就可以把商业要求和软件开发的工程要求隔离开来，避免向开源社区倾倒粗糙的补丁。

如果评估出来更合适的做法是把改动直接做在上游，那么我会建议在需要严格控制风险的情况下，直接由公司员工组成开发团队。当然，这些员工得靠自己的努力在开源社区当中赢得信誉，而不是只根据职位就被允许直接提交代码。如果同样的需求已经有其他团队在做，那么沟通就是必要的。如果信得过这个团队，保持关注并提供帮助即可。否则，可以尝试接管项目开发。Flink 社区的 FLIP-85 提案是我和 Uber 的工程师分别独立提出的。经过几轮邮件列表上的讨论，最终由阿里的工程师主导实现。我参与了 review 并提供了部分参考实现。

上面讲的是一个好的案例。其实对于一个活跃的开源社区来说，PR 冲突的情况不会太少，种类也很多。

TiDB 社区发生过一起有名的 Xuanwo 事件。完全相同的两个补丁，后提交的反而先被合入，导致先提交的被迫关闭。尤其是这个事件发生在并不繁忙的仓库上，并且两个补丁提交的时间相差一个月。这是一种非常典型的情况，需要 Maintainers 持续关注项目范围内发生的活动。

【批注】其实后来 @xuanwo 自己 Xuanwo 过别人提交的 PR https://github.com/apache/opendal/pull/8326

我自己没有印象做过这样的事情，但是我也对 Contributor 说过比较重的话，大部分时候是遇上心情不好的时候，也有可能就是被菜哭了。如果我有对你说过重话或者做过什么你觉得不对的事情，请直接告诉我。

但是我也经常 take over 别人的改动，但是一般是 follow-up commits 保留原作者的信息，也就是直接改 PR 或者自己起一个，但是保留你的 commit 然后最后 co-authored-by 把自己也贴上去一起负责。

Flink 社区有不少经典的乐子。FLINK-10052 作为我从 2019 年就和 @lamberken 配合修复完成并经过生产环境验证的高严重性问题，在过去的三年里提交的三个补丁都因为缺乏响应最终没有合并。这也导致不少用户被迫手动安装补丁。FLINK-11937 是另一个例子。两家员工提供了不同的方案，其中一方缺少社区话语权，无力单独推进合并；另一方有能力推进，但无意推进，也不允许他人推进。同样的案例还有 FLIP-44 和 Queryable State 等等。

Flink 的例子其实证明了商业公司需要通过 fork 仓库来响应商业需求。另外，也可以看到这些讨论的发起人是如何被 stale bot 再次伤害的。

从开源协同的角度，Contributor 不是程序，而是真实的人。上面提到的沟通手段，去掉公司员工的背景也同样适用。商业公司要做风险控制，开源社区也是一个组织，也可以做风险控制。只不过，开源社区是一个开放式组织。在这个环境下控制风险的手段不是管控，而是协同。前面讲到的文档和结构化的流程在这里同样可以起作用。信息在 Contributor 之间自由流通，就不会有 FUD 产生的伤害。平时保持和其他 Contributor 的联系，就能知道当前的工作最应该找谁一起做。

大部分情况下，Contributor 能够自我驱动和自我激励。他们爆发出的创造力不可小觑。单就时间上的风险而言，如果你在开发文档里明确写下开发周期和发布模型，Contributor 总是乐于见到自己参与或主导开发的工作随新版本一起发布。越是自我驱动参与开源社区的 Contributor 越重视积累信誉。在这个过程中，如果你作为 Mentor 指导或参与其中，只需要切实关注并解决开发团队成员遇到的困难，并在需要时帮助他们管理好进度。

其他的沟通技巧和 Maintainer 的最佳实践这里不再展开。Open Source Guides 提供了对这个话题非常有益的补充，推荐延伸阅读。

• Best Practices for Maintainers

• Leadership and Governance

• Building Welcoming Communities

Have fun

不论是作为贡献者还是维护者，你都已通过参与开源社区为社会创造了价值。时不时想想你为什么要参与或维护这个项目，回顾项目已经取得的成就。你已经做得很好了。

软件都有自己的生命周期，开源软件也不例外。开源社区的工作也不是你生活的全部。如果你找到了新的乐趣，完全可以把项目交给其他人维护，或者直接归档。如果开源项目的维护已经超出你的能力范围或者消耗了太多的时间精力，也可以休息一段时间，甚至放弃对项目的维护。作为开源社区成员的你没有义务非得维护这个项目或响应别人的请求。你把自己的工作成果提供给其他人自由使用，客观已经创造了非常的价值。