读开源项目成功之道06让项目受欢迎

1.1. “欢迎马车”的想法是帮助新邻居克服结识新朋友的尴尬

1.2. 倦怠是开源项目面临的头号挑战

1.3. 为新人设置项目

• 1.3.1. 拥有一个受欢迎的项目的第一步，是要让维护者展现出欢迎新人加入的态度

• 1.3.2. 设置项目的基础设施

  • 1.3.2.1. 大多数项目都使用GitHub或GitLab等服务，它们为开源项目提供免费的代码托管服务

  • 1.3.2.2. 一个好的开源项目不能仅仅只有一个好的README文件，还需要有不同的沟通渠

  • 1.3.2.3. 邮件列表：电子邮件始终是任何人都能轻松使用的最基本的媒介

    1.3.2.3.1. 开源项目通常使用Google群组、groups.io或GNU Mailman等服务

  • 1.3.2.4. 论坛：许多社群会从使用邮件列表演变为使用论坛，与邮件列表相比，论坛往往更容易被发现并且具有更好的搜索功

  • 1.3.2.5. 即时沟通渠道

  • 1.3.2.6. 会议：无论是虚拟网络电话会议还是面对面的聚会，都是项目参与者实时交流的机会

  • 1.3.2.7. 至少选择一种易于发现的异步通信方法，如邮件列表或论坛。这不仅使来自不同时区的人们更容易进行协作，还能方便那些只能在晚上为项目作出贡献的人

    1.3.2.7.1. 还能够建立一个知识库，虽然在原始论坛中可能不容易被发现，但至少可以将内容记录下来，以后也更容易构建文档或指南

  • 1.3.2.8. 设置定期会议，并尽量确保有线上加入的选项

    1.3.2.8.1. 定期设置会议很关键，因为一方面，这使日程安排更容易

  • 1.3.2.9. 保持会议的条理性，同时保持轻松的氛围

    1.3.2.9.1. 举行正式会议可能会给人一种会议非常专业的印象，但也可能被视为僵化和难以参与

  • 1.3.2.10. 要明确不同的沟通类型所适用的沟通渠道

    1.3.2.10.1. 通过即时沟通渠道很难达成共识，而使用邮件列表又很难获得即时帮助

• 1.3.3. 创建入门指南

  • 1.3.3.1. 入门指南是欢迎人们加入项目的数字界面

  • 1.3.3.2. 在用户体验设计领域，人们普遍认为用户使用应用程序的前5分钟很重要

  • 1.3.3.3. 入门指南可能因项目和技术而异

    1.3.3.3.1. 对于命令行工具，使用--help命令行开关或使用man应该能够触发使用指南

  • 1.3.3.4. 了解你的用户，并为他们提供合适水平的指导

  • 1.3.3.5. 专注于让用户在前5分钟内取得成功

• 1.3.4. 欢迎新贡献者

  • 1.3.4.1. 在自由软件的早期，通常情况下，软件是在“幕后”开发的，最终用户的参与非常有限

  • 1.3.4.2. 贡献者常常对参与项目感到畏惧

    1.3.4.2.1. 项目中可能有他们不认识的人，这些人来自不同的地区，他们的种族、文化程度与性别也都不同，甚至可能是某个特定领域的高级专家

    1.3.4.2.2. 许多软件工程师不擅长处理这些社交动态，所以时刻关注这些问题是缓解这种担忧的好方法

  • 1.3.4.3. 贡献者指南不是从讲解规则和流程开始的，而是始于向贡献者表达感谢

  • 1.3.4.4. 第一次积极的互动是成功的另一个关键

  • 1.3.4.5. “乐于助人”和“谦逊”

  • 1.3.4.6. 服务型领导力

  • 1.3.4.7. 表示欢迎是让新人想留下来的第一步，但是为了让新人留下来，项目必须展示他们对新人贡献的重视

• 1.3.5. 当新人产生影响时，要认可他们

  • 1.3.5.1. 新人通常认为为开源项目作出贡献是为潜在雇主建立自己作品集的一种方式，因为这些代码贡献有助于展示开发者所拥有的技能

• 1.3.6. 让新人感到受欢迎的一个关键方面是，随着时间的推移，应该支持他们成为贡献者或维护者

1.4. 有效支持最终用户

• 1.4.1. 开源项目通常没有为商业产品提供支持的能力，这是有充分理由的

• 1.4.2. 从人员配置的角度来看，很少有项目具备提供相同级别支持的能力

• 1.4.3. 在开源中，我们看到了社群模式，这意味着我们的用户会帮助其他用户，有时bug和解决方案是在公开场合而不是闭门造车的环境下解决的

• 1.4.4. 管理问题

  • 1.4.4.1. 如何提出问题，这也是人们在项目中寻找答案的关键问题之一

  • 1.4.4.2. 良好的问题管理

    1.4.4.2.1. 让提交问题变得容易：许多使用GitHub或GitLab的项目会使用默认的问题跟踪器来处理问题，因为用户通常都知道该工具的使用方法，而且提交问题的门槛很低

    1.4.4.2.2. 指导用户提交有效的问题：最好的方法是在提交流程中提供帮助

    1.4.4.2.3. 定期审查问题并与用户沟通：如果你使用GitHub，可以使用各种GitHub操作来自动发送友好的消息，让用户知道他们的问题已被看到

    1.4.4.2.3.1. 关键部分是节奏，即使你不能提供问题的解决方案，也需要说一些话，如“谢谢你提出的问题，但目前问题有点多，我们很快就会解决”​

    1.4.4.2.3.2. 为用户设定了预期，同时也让他们知道你在倾听

    1.4.4.2.4. 免长时间不回应问题：将问题长期搁置且没有新的评论或活动会给人一种项目忽略问题的印象，应确保主动定期审查陈旧问题，这不仅表明项目在积极关注问题，还有助于项目更好地确定优先级

• 1.4.5. 社群和开发者管理

  • 1.4.5.1. 随着项目不断发展，许多用户会以各种方式使用项目，你将看到围绕项目自然形成了一个社群

  • 1.4.5.2. 理解用户的需求，这意味着要看到评论和反馈，并帮助将其整合到项目中或展示解决方案

  • 1.4.5.3. 积极主动去帮忙，这意味着要尽早分享信息和见解，这样其他用户就不会有同样的困扰

  • 1.4.5.4. 融入社区，要让其他社群成员参与进来，在活动中发言、聚会、发布视频和参与其他活动来融入社群

  • 1.4.5.5. 要富有同理心且保持积极向上，因为良好的社群和开发者管理会考虑到用户经常是因为无法解决问题而来到社群，社群和开发者管理的作用是理解、帮助解决问题，并让用户带着积极的体验离开

  • 1.4.5.6. OpenStack在社群和开发者管理方面投入巨资，这帮助用户和开发者更快地取得成功，并帮助项目本身不断发展，能够解决用户遇到的问题

• 1.4.6. 商业支持

  • 1.4.6.1. 一个充满活力的社群可以为最终用户提供巨大的支持，但它永远不会达到商业支持所能达到的水平

  • 1.4.6.2. 没有多少开源项目维护者希望在平安夜晚上11点修复bug

  • 1.4.6.3. 商业组织参与开源项目是一件好事

    1.4.6.3.1. 良好的治理模式有助于确保供应商中立，以实现更具协作性的项目

1.5. 参与到对话中去

• 1.5.1. 开源社群不是你可以完全设计的东西

• 1.5.2. 把虚拟协作看作社群兴起的第一个渠道

• 1.5.3. 在线论坛和社交媒体

  • 1.5.3.1. 当技术专家和开源爱好者在职业生涯中成长时，你往往会看到他们聚集在不同的在线社群中

  • 1.5.3.2. 使用Reddit、Stack Overflow和其他平台的订阅功能，当你的项目被提及时，会收到提醒

  • 1.5.3.3. 当你发现这些对话时，请推广它们

  • 1.5.3.4. 在这些对话中发表评论，将评论的作者和其他评论者链接到你的文档或其他博客文章

    1.5.3.4.1. 有助于将可能偶然发现该对话的人与正确的资源联系起来

  • 1.5.3.5. 在讨论发生的在线论坛和社交媒体上发布有关项目的信息

• 1.5.4. 区域聚会和活动

  • 1.5.4.1. 聚会和活动是开源文化的重要组成部分，它们对于激发协作至关重要

  • 1.5.4.2. 在会议上发言

    1.5.4.2.1. 作为新的演讲者，可能很难参与大型会议，但较小的区域聚会或活动总是会寻找新的主题和演讲者

  • 1.5.4.3. 当你参加会议时，不要坐在角落里忙于用计算机处理你的项目

  • 1.5.4.4. 如果你的会议被录制下来，请在你的社群或社交媒体中分享

  • 1.5.4.5. 无论是线上活动还是线下活动，社群成员往往会围绕领导者和有影响力的人聚集，让一个项目认可这些领导者有助于激励他们并引导社群成员向他们看齐

  • 1.5.4.6. 支持社群的自然发展是对开源项目价值的一种肯定

    1.5.4.6.1. 这并不意味着它总是容易的

2.1. 开源项目通常采用与创业公司相同的模式，对于创业公司来说，先考虑长期发展再考虑短期成果是很困难的，因为没有一定程度的收入和成功，就没必要考虑长期发展了

2.2. 开源项目往往不太依赖于短期成果，同时又不能忽视短期成果

2.3. 一个好的项目，就像一家好的公司一样，会对两者都给予适当的关注，并在决策时兼顾两者

2.4. 可持续性的一个难题是要让更多的人以不同的角色参与到项目中来，这些人来源于已经投入项目中的人

3.1. 当一个新维护者看到他们在项目中的个人参与增加时，他们常常对项目在成长过程中可能有的更大需求一无所知

3.2. 拥有更多的维护者可以减轻这种负担，并帮助所有维护者将精力集中在他们最擅长的领域

3.3. 减轻当前维护者的压力

• 3.3.1. 挑战之一是维护者的倦怠

• 3.3.2. 维护者的倦怠是开源社群一直存在的问题，但这个问题变得越来越严重了，因为人们的生活方式发生了变化

• 3.3.3. 随着开源软件的广泛使用，维护者所承受的压力达到了历史最高点

• 3.3.4. 最终用户和其他下游利益相关者对维护者施加了太多压力，把维护者当作一个完整的软件开发团队，而不是在不同活动之间维护项目各个方面的人员

• 3.3.5. 维护者会换工作，在这个过程中，维护者必须花费相当长的时间来适应新工作

• 3.3.6. 健康问题，无论是自己的还是亲人的健康问题，都会占用他们的时间和注意力

  • 3.3.6.1. 没有足够的精力继续以以前的速度推动项目

• 3.3.7. 如果项目没有按照维护者或创建者的想法发展，运营项目的吸引力会变得越来越小

• 3.3.8. 将贡献者发展为维护者可以帮助维护者减轻压力，并保持维护者的参与度和兴奋感

3.4. 为项目带来新的想法和能量

• 3.4.1. 一个挑战就是决策中心集中在一个人身上，而根据领导风格的不同，这可能有助于推动共识，也可能会扼杀其他意见

• 3.4.2. 引入新的维护者，也就引入了新的想法和活力

• 3.4.3. 互相学习新的做事方式

  • 3.4.3.1. 有更多活动经验的人可以分享帮助项目做准备活动的技巧，而有更深入开源经验的人可能对复杂项目的治理设置有见解

• 3.4.4. 互相支持，并且从精神和情感支持的角度来看也是如此

• 3.4.5. 当你作为一个项目的维护者能够适应新维护者加入项目时，你就不再需要成为项目中的支点了

3.5. 使当前维护者退居幕后

• 3.5.1. 现有组织增加了额外的资源，尽管通常情况下是相当少的

• 3.5.2. 新组织或独立开发者的价值增长，他们通常很有经验并且在行业中已经比较知名

• 3.5.3. 要让维护者退居幕后，他们必须对此感到舒适

• 3.5.4. 创造了引入新维护者和过渡领导的正确文化，这对于一个项目的初始领导者来说往往是困难的

• 3.5.5. 使维护者退居幕后的另一个方面是思考如何最好地优化维护者的时间

• 3.5.6. 帮助项目扩展增长的最佳方法是构建文档、培训和认证资源，以使项目本身能够进行大规模教育

• 3.5.7. 作为维护者，退居幕后可能会导致角色和责任的转变，让维护者利用他们的可用时间专注于特定领域，但这也可能是一条继任之路，意味着维护者完全离开了一个项目

• 3.5.8. 作为一个维护者，并没有必要终身参与一个项目，就像我们的职业生涯一样，我们并不局限于终身一个雇主或一份工作