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)
