读开源项目成功之道11开源项目落幕

1. 开源项目的落幕

1.1. 开源项目都始于良好的意愿：有一个需要解决的问题，有一位热情积极的维护者，以及众多涌入该项目并提供反馈的用户和贡献者
1.2. 用开源许可证发布代码是永久不可逆的操作，但拥有开源项目则并非如此
1.3. 开源项目生命周期的末端是持续

• 1.3.1. 代表项目接下来进入了长期维护状态
  
• 1.3.2. 虽然项目仍有用户，但它在整体上已经是个功能完整的成熟项目了，后续任何的变更和增加都只是聚焦于修复漏洞和解决安全问题
  

1.4. “持续”阶段项目的社群开始衰退，并转向其他正在积极开发或更适合他们需求的解决方案

• 1.4.1. 这会产生连锁反应，随着用户离开，贡献者也会离开，最后维护者也离开了项目，久而久之就没有人主动维护了
  
• 1.4.2. 项目生命周期的下一步—落幕
  

1.5. 项目落幕也不见得是一件坏事

• 1.5.1. 开源社群往往资源有限，因此让项目社群聚集到一起有助于发展一个更强健的项目，并避免冗余
  

1.6. 开源项目的落幕意味着减少或终止该项目的开发和维护工作

• 1.6.1. 原因可能很多，包括缺乏资金、开发者不再感兴趣，或是项目目标已经实现
  

1.7. 结束一个开源项目可能是一个艰难的决定，项目维护者必须清楚地传达这一决定，并指导用户迁移到其他解决方案

• 1.7.1. 为了确保资源的有效利用和项目的传承，结束项目也可能是必要的
  

1.8. 结束一个开源项目并不等同于开源项目的失败

• 1.8.1. 即使项目被结束，也不意味着它对未来没有影响
  

2. 如何判断一个项目正在放缓

2.1. 一个开源项目是进入维护状态，还是真的要走向落幕，这当中的区别往往很微妙，并且通常与项目投入的支持直接相关
2.2. 开源项目具有多重维度，不仅需要强大的社群支持，还需要明确的使用案例和对项目的持续投资
2.3. 在这个可持续性循环中，每个环节都必须正常运作，以维持整个循环的运转
2.4. 项目—当代码速度和社群参与度下降

• 2.4.1. 项目衰落的显著迹象之一是代码速度（代码贡献的数量和频率）和社群参与度的显著下降
  
• 2.4.2. 如果项目的用户和贡献者社群衰落到活跃参与者所剩无几的地步，那么维持项目的开发和维护可能会变得困难
  
• 2.4.3. 如果项目创始开发者失去兴趣或转向其他项目，寻找愿意且有能力接手的新维护者会变得更加困难
  
• 2.4.4. 一旦项目已经实现了既定目标或完成了预定的任务，继续开发的需求可能就不存在了
  
• 2.4.5. OpenOffice是一个因社群衰落而走向落幕的经典案例
  
• 2.4.5.1. 当项目发生分支而未能合并回原项目时，通常会有一个分支因为资源不足而无法继续
  
• 2.4.5.2. 随着社群的精力有效转移至LibreOffice上，OpenOffice就变成了落幕的首选项目
  

2.5. 产品—处于正在衰落的技术领域

• 2.5.1. Palm Pilot这个个人数字助理(Personal Digital Assistant，PDA)
  
• 2.5.2. 当一个项目依赖于过时技术或与新的平台或系统不再兼容时，结束该项目并启动一个新项目可能是更合理的选择
  
• 2.5.3. Camino Web浏览器就是这样的一个例子，尽管它采用了与Mozilla Firefox相同的Gecko渲染引擎，但它在用户界面上使用了Mac原生的Cocoa API，实现了与Mac OS X早期版本的Aqua桌面环境的无缝融合
  
• 2.5.4. MeeGo：一个由诺基亚和英特尔共同开发的开源操作系统，面向移动设备和平板电脑，但随着iOS和安卓操作系统在移动市场主导地位的确立，MeeGo的关注度逐渐下降，最终在2011年落幕
  
• 2.5.5. Google Wave：一个旨在将电子邮件、即时消息和文档协作合并为一体的开源协作平台，尽管起初备受欢迎，但随着时间的推移，人们对Google Wave的兴趣逐渐下降，项目于2012年落幕
  

2.6. 利润—资金和投资枯竭

• 2.6.1. 开源项目通常依赖于捐款或资助来支持其开发和维护
  
• 2.6.2. 资金可能是直接的现金支持，也可能包括提供开发者和工程资源、市场支持，以及硬件和合作基础设施等
  
• 2.6.3. 一旦资金来源枯竭，维持项目的难度将大大增加，有时甚至寸步难行
  
• 2.6.4. OpenSolaris
  
• 2.6.4.1. 停止开发OpenSolaris的决定引发了争议，并因此形成了几个由社群驱动的项目，以继续开发代码仓库，如Illumos和OpenIndiana项目
  
• 2.6.4.2. 尽管做出了这些努力，但OpenSolaris项目还是走到了终点
  
• 2.6.5. 项目资金和投资的枯竭通常是市场环境变化的结果
  
• 2.6.6. CyanogenMod是一个例子，这款流行的开源操作系统为安卓智能手机和平板电脑提供了标准安卓操作系统所不具备的额外特性和定制化选项
  
• 2.6.6.1. 随着CyanogenMod的关闭，曾支持该项目的开发者和用户社群转而开发名为LineageOS的新的开源安卓操作系统
  
• 2.6.6.2. LineageOS继承了CyanogenMod的核心理念，旨在提供类似的功能和定制选项，同时坚持完全开源和社群驱动的原则
  
• 2.6.6.3. 今天，LineageOS已广泛受到安卓爱好者和开发者的欢迎，并持续从其贡献者社群获得更新和改进
  

3. 结束项目的流程

3.1. 对于社群来说，结束一个开源项目是一个艰难的决定，需要社群中所有活跃的参与者共同参与，从维护者到最终用户
3.2. 确保每个人都同意这是一个正确的决定
3.3. 在社群中就项目落幕达成一致

• 3.3.1. 当项目有一个开发者社群时，将这些开发者纳入决策过程，并鼓励他们承担维护现有项目或创建新的分支项目的责任变得至关重要
  
• 3.3.2. 有助于确保投入项目中的知识和专业技术不会流失
  
• 3.3.3. 有时候，社群规模缩小到一定程度，反而能让项目落幕共识的达成变得简单
  
• 3.3.4. 落幕的过程并非总是顺畅的，特别是当存在利益冲突或开发者对其工作或项目本身有强烈个人情感时
  
• 3.3.5. 在结束一个开源项目时，如果不全面考虑商业利益、社群利益及其对周围社群的广泛影响，就会面临各种挑战
  

3.4. 宣布项目落幕的意向

• 3.4.1. 当项目即将结束时，项目维护者必须向社群传达这个决定
  
• 3.4.2. 尽早通知：一旦决定结束项目，就应立即向最终用户发送通知
  
• 3.4.2.1. 将给他们充足的时间来计划过渡和寻找替代方案
  
• 3.4.3. 清晰地沟通：在与最终用户沟通时，重要的是要清楚透明地说明项目结束的原因以及他们对未来几个月的预期
  
• 3.4.3.1. 定期提供最新信息并回答最终用户提出的任何问题或疑虑也是很好的做法
  
• 3.4.3.2. 项目可能无法考虑到项目结束对社群产生的所有影响，而能够解决这些问题将有助于使整个过程顺利进行
  
• 3.4.4. Firebug在宣布结束项目的意向时就做得很好
  

3.5. 帮助最终用户过渡

• 3.5.1. 以Firebug项目为例，通知社群落幕意向的一部分工作是提供指导，告诉他们如何继续使用该项目或迁移到替代解决方案
  
• 3.5.2. 一旦代码以开源许可证发布，那就是一个永久不可逆的行为
  
• 3.5.2.1. 通常最终用户会希望转移到另一种解决方案
  
• 3.5.3. 提供替代方案：随着落幕过程的推进，应该与最终用户一起确定他们有哪些可用的其他替代方案
  
• 3.5.4. 提供迁移支持：根据项目的复杂程度，最终用户将其数据和工作流程迁移到新解决方案的过程中可能需要一定支持
  
• 3.5.4.1. 可以与他们合作，提供文档、工具和资源来帮助他们顺利完成这个过程
  

4. 项目结束后的步骤

4.1. 一旦项目决定落幕，就需要在停运项目时做一些工作
4.2. 项目结束后，必须明确地表明该项目不再进行维护，并确保项目资产有一个长期的归宿
4.3. 将代码仓库和问题跟踪器标记为归档状态

• 4.3.1. 项目一旦结束，明确项目的状态至关重要
  
• 4.3.2. 涉及将项目的代码和文档存放在公共仓库中，以便用户和开发者未来仍能访问
  
• 4.3.2.1. 如果该项目对开源社群有重大影响，这点尤其重要
  
• 4.3.3. 在仓库的README文件中添加通知：README文件通常是用户和贡献者访问项目代码仓库时首先看到的内容
  
• 4.3.3.1. 可以在README文件中添加一则通知，说明该项目不再处于积极开发或维护状态，有助于防止混淆
  
• 4.3.4. 使用“已弃用”或“已归档”标签：许多代码托管平台（如GitHub）允许项目使用标签标记仓库，使用“已弃用”或“已归档”等标签可以清晰地表明项目不再处于积极维护状态
  
• 4.3.5. 在仓库描述中添加说明：在仓库的描述中添加说明，表示该项目已不再处于积极开发或维护状态，有助于帮助防止混淆
  
• 4.3.6. 考虑将用户重定向到替代方案：如果用户可以使用其他开源项目来代替你的项目，可以考虑在仓库的README文件或其他文档中添加指向那些项目的链接
  
• 4.3.6.1. 可以帮助用户找到满足其需求的替代解决方案
  

4.4. 项目应确保任何相关的工具或服务都要关闭

• 4.4.1. 如果项目有关联的服务，如网站、社交媒体账号或论坛，确保将它们停用或重定向到替代方案
  
• 4.4.2. 如果项目获得了资金支持，请关闭与资助相关的账户和渠道
  
• 4.4.2.1. 如果还有剩余资金，可考虑将其捐赠给推荐最终用户迁移的某个项目
  

4.5. 为资产所有权找到归宿

• 4.5.1. 开源项目通常有两类资产：代码和文档，以及项目名称和标志（统称为标记）​
  
• 4.5.2. 对于代码和文档，许多开源代码托管平台都有针对开源项目的归档程序和政策，GitHub的归档程序就是一个很好的例子
  
• 4.5.3. 要想获得更全面的解决方案，有一些组织可以作为中立的第三方来保护开源项目的商标，包括软件自由保护协会(Software Freedom Conservancy)、自由软件基金会(Free Software Foundation)、Linux基金会(Linux Foundation)和开放源代码促进会(Open Source Initiative)
  
• 4.5.4. 当一个开源项目结束时，关键是要确保该项目相关的商标能按照项目目标和价值进行管理，上述组织都是行业公认的开源项目管理机构
  
• 4.5.5. 它们还可以管理网站的托管和代码仓库的凭证，防止无法联系到最后的维护者
  
• 4.5.6. 将商标转让给中立的第三方，可以确保商标的使用不会违背项目的开源原则，也不会损害项目的声誉或遗产
  
• 4.5.7. 开源项目结束后，处理资产的目标应该是确保该作品得以长期保留，以供未来使用，并确保用户和贡献者了解项目的状况以及可能存在的任何替代解决方案
  
• 4.5.8. 尽管落幕是开源项目生命周期的最后阶段，但这并不必然代表它已走到尽头
  

5. 开源项目在结束之后仍可恢复

5.1. 取决于项目最初被终止的原因

• 5.1.1. 如果该项目是由于缺乏资金或开发者失去兴趣而结束，那么可能会有新的资金或开发者出现并恢复该项目
  
• 5.1.2. 项目可能会被其他开发者或组织分支，希望使用新的名称或添加新功能以继续开发
  
• 5.1.2.1. 这可能会促成一个新的社群，并吸引新的贡献者和用户加入
  

5.2. 两条路径

• 5.2.1. 将项目移交给新的维护者，由其继续开发和维护
  
• 5.2.2. 对项目进行分支，创建一个可以继续发展并满足用户需求的新项目
  

5.3. 恢复一个已结束的项目可能很有挑战，特别是在原项目拥有庞大而活跃的用户群并已转向其他解决方案的情况下

• 5.3.1. 新项目必须向社群展示其价值和相关性，而且可能需要时间来重建势头和吸引新的贡献者
  

5.4. 重要的是要仔细考虑项目当初结束的原因，并制定明确的计划，以便在项目恢复时应对这些挑战

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！