读开源项目成功之道02好的开源项目

1. 好的开源项目

1.1. 好的开源项目绝不是一个简单的概念
1.2. Linus在Linux中采取的一些新颖的方法

• 1.2.1. 他不是从头开始写所有代码
  
• 1.2.1.1. 他从Minix中借鉴了相当数量的代码（以及概念和想法）
  
• 1.2.2. Linux发布的第一个版本实际上是Beta质量的代码
  
• 1.2.3. 他公开鼓励他人提供反馈并参与工作
  

1.3. 在自由软件运动的早期，项目开放的特征仅仅与代码的许可证有关，即它是否在允许人们查看、修改和分发代码的许可证之下
1.4. 并没有一种固定的方式来运营一个开源项目，也没有一个社群应该采用一种固定的工作方式
1.5. 不同的文化、不同的行业领域、开发的速度和进度、项目的成熟度以及参与项目的人等诸多因素都会产生影响
2. 开源项目的核心特征

2.1. 用户是开发过程的一部分

• 2.1.1. 开源中有句话叫“水涨船高”​，这在用户参与开发的过程中得到了充分体现
  

2.2. 早发布，常发布
2.3. 透明和动态的决策

• 2.3.1. 相关的资金不仅来自学区资助，还来自私人资助与筹款
  
• 2.3.2. 开源项目蓬勃发展既依赖有意的透明度，又依赖快速动态地做出决策的能力，这通常会使开发速度变快，并让项目保持活力
  
• 2.3.3. 开源项目既可以成为推动协作和创新的机制，也可能成为无意建立社群而仅仅推送代码的一种方式
  

3. 发布开源代码与创建开源项目

3.1. 有一种特别的趋势，那就是公司将开源代码视为一种使源代码可用的方法，但并不一定希望围绕它构建一个开源项目
3.2. 智能代码转储

• 3.2.1. 那些之前可能是商业产品或其他不开源的代码，现在以开源许可证的形式被共享，但贡献代码的组织并没有打算继续维护它，更不用说构建项目或社群了
  
• 3.2.2. 非常有用的转储原因
  
• 3.2.2.1. 帮助那些仍在使用较旧版本软件的公司，使他们能够继续运作
  
• 3.2.2.2. 允许其他人使用过时的文件格式构建转换器或连接器
  
• 3.2.2.3. 通过为社群的爱好者和发烧友提供过时的软件来表达善意
  
• 3.2.3. 发布开源代码但不创建开源项目不仅适用于过时的软件，也适用于所有希望获得更大用户群的软件
  

3.3. 开放核心

• 3.3.1. 意思是公司发布一个基本的、精简的但功能齐全的产品版本进行开源，然后采用专有许可证发布一个功能更全面的商业版本
  
• 3.3.2. “唠叨软件”(nagware)
  
• 3.3.2.1. 共享软件
  
• 3.3.2.2. 它们会弹出烦人的窗口，提示用户购买商业版本
  
• 3.3.3. 主要的开发工作并不是在开源社群中进行
  
• 3.3.4. 代码发布只是倾倒到社群中供人们使用
  
• 3.3.5. 尽可能扩大用户群体，其策略是随着软件在组织中使用量的增加，用户可能会考虑购买其商业版本
  
• 3.3.6. 通常是在供应商中立的基础上，将下游生态系统建设的概念视为帮助解决变现问题的一种进化方式
  

3.4. 以开源方式发布代码时的期望

• 3.4.1. 开源对下游用户和开发人员负有道德责任
  
• 3.4.2. Linux基金会主持的项目TODO Group提供了一个合作论坛，名为开源项目办公室(Open Source Program Office，OSPO)，它提供了一个很好的资源
  
• 3.4.3. 尽早让其他有兴趣参与或贡献的外部组织和人员参与进来
  
• 3.4.4. 建立协作基础设施并将其公开
  
• 3.4.5. 定期举行社群会议，并寻找自然的见面机会，例如参加活动或当地聚会
  
• 3.4.5.1. 不仅为社群设定了预期，也为作为维护者的你设定了预期，让你始终牢记这些重要的事情
  
• 3.4.6. 启动一个开源项目意味着你需要有意识地支持其成功
  
• 3.4.6.1. 前期投资可能会很高，甚至比内部非开源项目还要高，但如果做得好，这种投资会得到回报，你能够以更低的投入获得惊人的技术回报（其他人也可以）​
  

4. 成功的开源项目的模式和反模式

4.1. 适用于一个项目的方案可能不适用于下一个方案，因为每个项目的人群、文化、行业动态和速度都不同
4.2. 开放式沟通（和过度沟通）

• 4.2.1. 最大挑战是沟通
  
• 4.2.2. 沟通的缺失会导致混淆和误解，甚至有时事情本身会被误解
  
• 4.2.3. 待办事项永远不会完结，需求不断，用户经常给你“踢皮球”
  
• 4.2.3.1. 多一点宽容会有很大帮助，更重要的是，这为你提供了吸引贡献者和用户的最佳方式
  
• 4.2.4. 过度沟通在前期需要做很多工作，但它可以节省你以后回答问题的时间，并有可能帮助你接触到你可能从未联系过的用户
  

4.3. 仁慈独裁与委员会领导

• 4.3.1. Linux已经由Linus领导了30多年，他是仁慈独裁领导风格的典型代表
  
• 4.3.2. 无论是从项目管理的角度，还是从文化和道德的角度来看，仁慈独裁者模式都给个人带来了沉重的负担，这意味着个人必须能够推动项目向前发展，同时吸引贡献者和用户，赋予他们能力和权力并推动技术的发展
  
• 4.3.3. 仁慈独裁作为一种模式通常属于“一般不起作用，但在某些情况下，有了正确的仁慈独裁者和正确的社群，它就会起作用”的狭窄类别
  
• 4.3.3.1. 模式的挑战在于需要正确的人来领导，他们需要有远见、有组织、有思想，能够将人们聚集在一起并发挥作用
  
• 4.3.4. 委员会领导解决了仁慈独裁者模式的问题，通过将决策和责任分散到多个人身上来提高项目效率，并随着时间的推移获得多样化的贡献者和贡献
  
• 4.3.4.1. 迫使项目进行更好的沟通
  
• 4.3.4.2. 并不意味着由委员会领导是完美的
  
• 4.3.5. 仁慈独裁者可以在自己的脑海中思考关键决策，而委员会的方法则迫使每个人都表达自己的想法以达成共识
  
• 4.3.6. 初创项目更适合采用仁慈独裁者模式，而成熟项目更适合采用委员会领导模式
  

4.4. 分支

• 4.4.1. 分支是开源中每个人所拥有的基本权利之一，也是每个开源许可证的核心
  
• 4.4.2. 分支的缺点在于用户必须承担一些成本，即对分支的持续维护成本，因为它可能会长期存在（可以持续多个项目版本，甚至是永久存在）​，而且随着时间的推移，需要将项目代码仓库中的更改持续引入分支的版本中
  
• 4.4.3. 在上游工作是一种更好的方法，这意味着当对代码仓库进行更改时，你可以将它们贡献回项目中，而不是单独维护它们
  
• 4.4.4. 在开源社群中，在上游工作通常是最好的方法，它能够使你的更改得到更广泛的测试，节省了将它们合并到后续版本中的时间，并展示了你作为代码仓库管理者的能力
  
• 4.4.5. 社群中的冲突是健康的，因为它给人们提供了发表意见的机会，并确保社群内部存在凝聚力和不同的观点
  

4.5. 过度治理

• 4.5.1. 如果你遇到一条看起来有点疯狂的法律或规则，那么它的背后肯定有一个更疯狂的故事
  
• 4.5.2. 一个活的文档，可以随着时间的推移而改变以适应项目的不同阶段
  
• 4.5.3. 不要制定处理假设情况的规则，而是针对已知问题制定规则，并随着时间的推移重新审视它们，并予以修改
  

4.6. 欢迎竞争对手

• 4.6.1. 开源的一个独特之处在于，合作是向所有人敞开的，因此即使是竞争对手也可以参与其中
  
• 4.6.2. 实际上，只要制定适当的基本规则，就可以使开源项目充满活力并且高速发展
  

4.7. 把一切都写下来

• 4.7.1. 书面文化与开放式沟通非常契合，因为实现开放式沟通的一个好方法是通过书面文字沟通
  
• 4.7.2. 使得重复流程变得更加一致，同时还能找到提高项目效率的机会和需要解决的问题
  
• 4.7.3. 将事情写下来不仅有助于与外界进行沟通，还可以协调和确定活动的优先级
  
• 4.7.4. 把一切都写下来，虽然有时看起来很烦人，但有助于使项目更加高效和有条理
  
• 4.7.5. 这样做还能帮助社群扩大规模，使新的成员随时加入社群，接管这些职责并持续管理这些任务
  

4.8. 拥抱你的社群

• 4.8.1. 创建开源项目的主要驱动力是让各种各样的人参与进来，提供反馈、贡献代码并帮助维护项目
  

4.9. 关注你的优势，利用工具和其他资源来弥补你的劣势

• 4.9.1. 作为人类，我们最难做的事情之一就是接受自己的缺点和我们不擅长的事情
  
• 4.9.2. 技术文档是一个很好的例子，大多数软件工程师觉得自己在这方面表现不佳，或者对技术写作没有太多兴趣，但是有些人在这方面非常擅长，可以为项目制作出出色的文档
  
• 4.9.3. 除了找对人，使用正确的工具也是一种提高工作效率，减轻工作负担的方法
  
• 4.9.3.1. 像FOSSology这样的工具可以帮你完成这项工作，并同时生成报告和软件物料清单(Software Bill of Materials，SBOM)
  

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