读开源项目成功之道10领导者的过渡.png

1. 领导者的过渡

1.1. 伟大的领袖未必是做大事的人，而是能够让别人做大事的人。

• 1.1.1. Ronald Reagan

1.2. 一个人的成就不是靠你自己的双手创造的，而是靠你对他人的影响和作用来建立的

1.3. 贡献者和用户不是员工，他们和项目社群没有财务上的约束，他们参与只是因为他们想要参与

1.4. 开源项目的成功很大一部分都是源自这些贡献者和用户，如果没有他们，开发资源很快就会匮乏，项目也就没有了受众

1.5. 要成为一名优秀的领导者，就必须确保这些贡献者和用户能够在项目中或利用项目产生的代码出色地完成工作

1.6. 开源项目的领导也是一份吃力不讨好的工作

1.7. 所有开源项目的代码都是在开源许可证下发布的，因此开源项目理论上是无限期的，但那些贡献者和维护者并不会永远存在

2. 为何要考虑领导者的过渡

2.1. 不是所有的项目都是永恒的，但代码一旦在开源许可证下发布，就会永远存在

2.2. 如果一个项目已然日薄西山，也完全可接受

2.3. 如果这个项目正有着很活跃的用户和社群，引入新的领导者对项目的可持续发展就非常重要

2.4. 原因

• 2.4.1. 职业变动

  • 2.4.1.1. 在我们之前的几代人中，终生从事同一职业的人往往比较常见，但在如今的世界，这是不现实的

  • 2.4.1.2. 开源项目通常会作为职业生涯的跳板

    2.4.1.2.1. 雇主一般都会非常积极地允许他们维护自己的项目，因为他们之所以被雇用，通常是由于该项目对雇主来说相当重要

  • 2.4.1.3. 随着时间的推移和新技术的不断涌现，趋势会发生变化，开发者很可能跟不上时代的步伐

• 2.4.2. 即将退休的项目领导者

  • 2.4.2.1. 职业变动是需要进行领导者过渡的一个方面，而退休更是我们所有人最大的职业变动

  • 2.4.2.2. 就像职业变动模式一样，你通常看到的模式是，现任领导者采用仁慈独裁者模式，然后要么过渡到新的领导者，要么采用技术委员会或供应商中立的基金会治理等模式

  • 2.4.2.3. 通常很难找到与现任的领导者一样充满热情并具备广泛技能的人

  • 2.4.2.4. 或者是项目已经被广泛使用了，一个领导者无法处理所有事务

  • 2.4.2.5. 像Ruby、Python和PHP这样的项目都是从仁慈独裁者模式过渡到了供应商中立的基金会治理模式

  • 2.4.2.6. 改变项目的治理模式可能会造成非常大的影响，所以专注于继任和长期资产管理是首要问题

• 2.4.3. 项目停滞不前

  • 2.4.3.1. 当你启动一个开源项目时，总会有很多令人兴奋的事情

    2.4.3.1.1. 代码开始源源不断地涌入，代码仓库被组织起来，人们开始下载代码并尝试使用

  • 2.4.3.2. 有超过2600万个GitHub仓库自2021年就没有更新过，而自2021年之后更新的仅有1200多万个

  • 2.4.3.3. 最后提交时间并不是一个很好的评价指标，再说，一个项目也可能被认为是功能完备或完成，所以不会有太多变动

  • 2.4.3.4. 尊重维护者是至关重要的，他们将自己的知识产权以开源许可证发布，并帮助你解决了问题，因此请与他们合作使代码变得更好，而不是在不向他们回传代码的情况下进行分支

3. 制定继任计划

3.1. 继任计划是许多组织（特别是大型和长期运营的组织）会花费大量时间制定的事务

3.2. 组织制定继任计划是因为有人依赖这个组织，他们可能是员工、客户或投资者，他们都对组织的成功持续运营有着切实的关注

3.3. 开源项目同样依赖于庞大的用户社群，因此也必须考虑继任计划。继任计划不是一个单一的过程，它涉及不同的环节，并可能需要花一些时间才能完全完成

3.4. 记录项目的运营

• 3.4.1. 不仅是为了让每个人都清楚事情是如何运作的，更重要的是，因为人们都很容易忘记项目的所有政策和流程，特别是当他们不经常使用的时候

• 3.4.2. 项目使用的所有服务（社交媒体、构建资源、代码仓库、扫描工具和任何其他协作工具）的凭证

• 3.4.3. 构建和测试基础设施的工作方式，包括所使用的服务和工具，以及它们如何互动和协同工作

  • 3.4.3.1. 如何安装或部署项目代码

  • 3.4.3.2. 发布计划和路线图

  • 3.4.3.3. 代码架构和设计

• 3.4.4. 文档记录是一个持续的过程，项目应尽早开始并持续维护

3.5. 新领导者的时间安排和培养

• 3.5.1. 完成文档编写的工作后，下一阶段就是开始实施领导者过渡的流程

• 3.5.2. 你永远不知道CEO何时会离开组织、去世或表现不佳，因此让潜在的继任者做好准备有助于加快领导者的过渡

• 3.5.3. 让组织有机会利用现任领导者的智慧和经验来指导和培养未来的领导者

• 3.5.4. 在现任维护者的指导下逐步有计划地培养新维护者是最好的方法

• 3.5.5. 现今的开源项目通常没有能力像商业公司一样有潜在的领导者能随时准备好被任命为新的项目领导者

  • 3.5.5.1. 找到愿意领导项目的人已经很难，更不用说是合格的人了

  • 3.5.5.2. 开源项目并没有分布全球的数千名员工，大多数都是单一维护者项目，只有少数项目拥有超过几十名维护者

  • 3.5.5.3. 开源项目维护者很少获得报酬，而且即使有，也远远低于市场水平

• 3.5.6. 开源项目可以从上市公司的继任计划中学到一些东西，提前规划总好过为时已晚的仓促应对

  • 3.5.6.1. 评估现任维护者/领导者预计在其岗位上工作多久

  • 3.5.6.2. 认为某个人可以取代现任维护者/领导者的想法可能不太现实，可能应该由多人分担这个角色

  • 3.5.6.3. 确定潜在的领导者，让他们承担部分职责，并跟随现任领导者

  • 3.5.6.4. 就领导结构的任何变化征求社群关键成员的意见

    3.5.6.4.1. 关键的是，你要为新的领导者和领导结构的顺利运作做好准备

  • 3.5.6.5. 公开宣布新的领导者和领导结构

    3.5.6.5.1. 确保给社群提问的机会，并让新老领导者都参与进来

    3.5.6.5.2. 在公开宣布时，透明度很关键，你必须为社群提供尽可能多的信息，以便使他们理解为什么会发生这种转变

• 3.5.7. 并不是所有的项目都有幸拥有足够多的维护者以提前计划领导者继任，规模较小的项目可能只有2～3名维护者

  • 3.5.7.1. 每个维护者都应该实事求是地考虑自己想在维护者岗位上投入多久，确定接替他们的最佳方式，然后找到并培养这些继任者

  • 3.5.7.2. 要有意识地思考并为未来制定计划

  • 3.5.7.3. 确保有一个计划来维持项目的长期发展就很重要

3.6. 从容地退居幕后

• 3.6.1. 最难的部分就是让现任领导者退居幕后

• 3.6.2. 即使制定了最佳的过渡计划，要“一刀切”地让现任领导者从项目中退居幕后仍然是一项挑战

• 3.6.3. 这个过程应该是循序渐进的，新的维护者和领导者逐步接管项目活动，同时减少对原计划中被替换的维护者的依赖

• 3.6.4. 许多维护者在逐步退出时都会采取谨慎的态度，因为他们对项目倾注了大量的精力和热情，渴望确保项目以后能够被妥善管理

• 3.6.5. 有些维护者可能已对项目感到精疲力尽，他们只是很高兴能找到人接手

• 3.6.6. 适当地做出后援

  • 3.6.6.1. 最重要的是确保前任领导者保持一定的存在感，而不是完全退出

  • 3.6.6.2. 担任开源项目领导者往往是孤独的，因此来自曾经处于该位置的人的支持和鼓励对新领导者来说至关重要

  • 3.6.6.3. 让前任领导者作为后援非常有益

  • 3.6.6.4. 虽然前任领导者的参与很重要，但他们并不总是掌握所有答案

• 3.6.7. 为新领导者背书

  • 3.6.7.1. 在实践中，当项目转入供应商中立的基金会后，新加入的成员通常会在关键决策上听从原贡献组织的意见

  • 3.6.7.2. 意味着新领导者虽然可能拥有名义上的“立法权”，但在实际操作中可能缺乏影响力

  • 3.6.7.3. 项目分支通常会导致注意力分散，最终结果要么是分支项目获胜，要么是主项目获胜

  • 3.6.7.4. 前任领导者需要谨慎行事，因为新领导者可能会做出他们不支持的决策或行动

• 3.6.8. 为新领导者建立广泛的支持网络

  • 3.6.8.1. 接纳并向同辈人学习也同样重要

  • 3.6.8.2. 参加开源会议：开源项目的领导者通常都会出席这些会议

  • 3.6.8.3. 持续对话：当你遇到一些你钦佩且易于交谈的项目领导者时，尽量保持沟通

    3.6.8.3.1. 可以与他们定期会面，倾听他们的意见，就像你希望他们倾听你的意见一样

  • 3.6.8.4. 撰写博客：考虑开设一个博客，分享你作为项目维护者的经验

  • 3.6.8.5. 拥有合适的支持，新领导者就可以成功起步

3.7. 制定继任计划对于项目来说是困难的，这不仅仅是因为需要做的工作很多，还因为我们必须面对终有一日会把这个工作和岗位交棒给下一个人继续推进的现实

3.8. 虽然对于领导者及其开源项目来说，过渡给新的领导者是一种解决方法，但有时候，项目已经完成其使命和生命周期，是时候关闭它了