读开源项目成功之道08开源的商业化

1. 应对增长

1.1. 开源项目通常从小规模开始，最初可能只有一个或几个贡献者
1.2. 当一个项目能够持续发展时，组织就会考虑投资并将其用于内部，同时将其构建到自己的产品中
1.3. 商业化可能被视为开源的反模式，但实际上，这也是对项目价值的一种验证
2. 衡量增长

2.1. “不能衡量就无法管理”是一句经常被引用的名言
2.2. 关注太多指标也很难，因为指标的差异太大，优化起来也很困难
2.3. 用于衡量增长的关键领域：认可度、采用度和多样性
2.4. 增加项目的认知度

• 2.4.1. 在提升认知度的阶段，我们的目标是让尽可能多的人关注项目，并且了解在某人第一次接触到该项目时所采取的行动
  
• 2.4.2. 显示某人与项目接触的指标
  
• 2.4.3. 查看他们可能采取的下一步行动的指标
  

2.5. 项目采用度

• 2.5.1. 一旦有人开始使用一个项目，下一步就是以某种方式观察项目的采用度
  
• 2.5.2. 在商业项目中，通常会使用某种遥测技术来报告活跃用户的数量，但对于开源项目来说，这种侵入性行为通常是不受欢迎的
  
• 2.5.3. 报告问题
  
• 2.5.4. 在邮件列表/论坛上提问
  
• 2.5.5. 撰写关于项目使用的博客文章或进行会议演讲
  
• 2.5.6. 为项目贡献代码
  
• 2.5.7. 关于某人使用项目的推荐或案例研究
  
• 2.5.8. 在项目网站或代码仓库中的ADOPTERS文件中列出组织标志或名称
  

2.6. 项目的多样性

• 2.6.1. 一个多样化的项目是可持续的，因为来自不同领域的个体可以帮助支持项目，而不是依赖于某一人群、某一组织或某一地区的支持
  
• 2.6.2. 多样性是在项目开始时就需要考虑的事情，因为多样性是由项目文化塑造的
  

3. 评估和补救低增长的领域

3.1. 提交记录/提交者

• 3.1.1. 独立的提交者数量
  
• 3.1.2. 在一定时间内的新贡献者数量
  
• 3.1.3. 提交数量
  
• 3.1.4. 添加/更改的代码行数
  
• 3.1.5. 审查贡献者指南，确保其对预期清晰明了，并且对贡献者的要求不会过于苛刻，因为它可能会阻碍简单的贡献
  
• 3.1.6. 确保定期审查和回应所有贡献，并与贡献者合作，帮助他们将贡献纳入项目
  
• 3.1.7. 在发布公告中认可新贡献者，让他们感到受欢迎和被赏识
  
• 3.1.8. 贡献者的流失
  

3.2. 项目使用度

• 3.2.1. 通常不鼓励使用遥测方式，因此在开源衡量中使用指标可能很棘手
  
• 3.2.2. 下载量或仓库克隆/分支量
  
• 3.2.3. 关于使用项目的帖子或问题
  
• 3.2.4. 使用项目的博客文章或其他社交媒体
  
• 3.2.5. 在调查中，最有可能回应的人是那些有所顾虑的人，而不是对项目完全满意的人
  
• 3.2.6. 调查的确是一个绝佳的工具，可以识别项目中存在的问题，以及项目让用户满意的地方
  

3.3. 多样性

• 3.3.1. 提升项目的多样性往往是非常具有挑战性的领域之一
  
• 3.3.2. 它往往促使项目维护者引入与他们不同的人
  
• 3.3.3. 与项目维护者不同的人通常会觉得参与项目令人生畏
  
• 3.3.4. 在项目社群中寻找来自代表性不足群体的成员，并支持和鼓励他们
  
• 3.3.5. 确保项目有一个行为准则
  
• 3.3.6. 将多样化的贡献者发展为维护者
  

4. 增强和扩展项目的领导力

4.1. 创始人承担了从销售到市场营销再到产品开发的多种角色，包括诸如“增长黑客”这样的角色，这些角色在公司规模扩大以后是不可持续的
4.2. 创始人的兴奋度和投入程度极高，以至于他们对投入公司的时间和对他们产生的影响视而不见
4.3. 从项目通才到项目专家

• 4.3.1. 项目的需求已经高到维护者缺乏时间来专门投入特定领域
  
• 4.3.2. 提升项目某些领域所需的技能并非维护者所擅长的，因此尽管这些工作已经完成，但完成得并不是很好
  
• 4.3.3. 项目没有很好的方式让新用户和开发者“自我赋能”​，这意味着缺乏良好的文档或培训材料
  
• 4.3.3.1. 当需要这样的材料时，通常只能临时准备，无法重新利用
  
• 4.3.4. 维护者倾向于在相关项目中担任类似领导的角色，这导致他们精疲力尽
  
• 4.3.5. 维护者倾向于务实地管理任何行业活动，包括举办聚会、准备演讲、进行社交外联以及与活动经理协调
  
• 4.3.6. 维护者手动管理CLA，需要向每个维护者发送文档，然后必须对每个新贡献手动核对CLA签署者名单
  

4.4. 时间管理和预期管理

• 4.4.1. 帮助维护者在其他优先事项之间平衡时间的解决方案
  
• 4.4.2. 时间管理实际上也是预期管理，意味着需要明确工作内容、花费的时间以及所需资源的预期
  
• 4.4.3. 可能会出现“贪多嚼不烂”的情况，因为通常看似简单的事情，当你在深入研究时可能会变得更加复杂
  
• 4.4.4. 扩展不仅仅是增加更多资源，还包括更有效地工作
  
• 4.4.5. 所要做的工作太烦琐
  
• 4.4.6. 沟通完成任务的预期时间框架
  
• 4.4.6.1. 对于问题分类，你可能明确表示所有问题将在5天内审查完毕
  
• 4.4.7. 沟通是开源项目的关键—尽可能透明和诚实往往能在维护者、贡献者和用户之间建立更牢固的纽带和信任
  
• 4.4.8. 不善于管理时间的风险就是逐渐倦怠
  

4.5. 避免倦怠

• 4.5.1. 倦怠是开源领域的热门主题之一
  
• 4.5.2. 倦怠是我们经常看到的现象，但实际上，它是项目维护者未能妥善管理压力的最终表现
  
• 4.5.3. 使用任务管理系统记录你需要做的所有事情
  
• 4.5.4. 使用任务管理系统来帮助优先排序或安排事项
  
• 4.5.5. 合理安排休息时间，并坚持执行
  
• 4.5.6. 尽可能在周末休息来恢复精力，而不是工作
  
• 4.5.7. 安排好节假日，将其真正用于休息和恢复精力，而不是用来修复你一直想要解决的项目功能问题
  
• 4.5.8. 确保饮食质量，同时安排充足的睡眠和锻炼
  
• 4.5.8.1. 疲劳、疾病和焦虑都是不健康的症状
  
• 4.5.9. 找到项目之外能带来乐趣的活动
  
• 4.5.10. 定期进行健康检查
  
• 4.5.10.1. 对于那些生活在拥有良好的医疗保健系统的地区的人来说，他们往往是最不善于实际利用这些系统的人
  
• 4.5.10.2. 请至少每年安排一次身体检查
  
• 4.5.11. 当你遇到心理障碍时，可以暂时离开一会儿，做一些不同的事情
  

5. 开源的商业化

5.1. 在20世纪90年代和21世纪初，微软被认为是开源的主要反对者，其内部立场是“拥抱并扩展”​，这是一种用于在市场上取得主导地位的策略，也用于与其他竞争软件供应商竞争
5.2. 很多时候，查看和修改源代码本身就是有价值的，而这通常是商业软件无法做到的
5.3. 时至今日，企业愿意参与开源就已经是一种进步了，这些组织在与开源项目和社群合作时采取了更加负责和尊重的方式
5.4. 时至今日，企业愿意参与开源就已经是一种进步了，这些组织在与开源项目和社群合作时采取了更加负责和尊重的方式
5.5. 开源软件通常与免费和自由软件一起被归类为FLOSS，即Free Libre and Open Source Software

• 5.5.1. 开源中的自由是“自由如同言论自由，而不是免费啤酒”​，这与libre一词的词根有关，它更多地用于描述自由，而不是没有成本的东西
  
• 5.5.2. 尽管它是免费的，但代码的许可证为项目的用户提供了使用项目的条款和指导
  

5.6. 开源项目是可以商用的，就如同项目的其他用途一般

• 5.6.1. 商用有助于开源项目的可持续模式
  

5.7. 可持续性循环

• 5.7.1. 项目是软件代码和社群本身的集合
  
• 5.7.1.1. 只有在一个强大、协作和多样化的团体共同努力，一起构建他们认为非常重要的技术时，开源社群才能取得成功
  
• 5.7.1.2. 社群可能包括为雇主工作的企业员工，也可能包括对这个领域感兴趣和有热情的个人
  
• 5.7.2. 当项目变得越来越有用，对市场越来越有价值时，项目可能将被产品化
  
• 5.7.2.1. 产品化还有另一个视角，那就是使用，意味着有人接受该项目并以某种方式使用它
  
• 5.7.2.2. 当项目被他人使用时，实际上就已经产品化了，因为项目就像任何其他产品一样被“消费”了
  
• 5.7.3. 所有的决策都是由经济价值或利润驱动的
  
• 5.7.3.1. 在这个可持续性循环中，利润是验证开源项目产品化的关键部分
  
• 5.7.3.2. 降低研究和软件开发成本：无须编写和维护开源项目提供的代码
  
• 5.7.3.3. 扩展潜在市场：在项目中添加当前项目开发团队没时间或没能力开发的特性和功能
  
• 5.7.3.4. 加快上市时间：开发团队可以利用一个或多个开源项目作为他们商业产品的构建模块，而不必自己从头构建
  
• 5.7.3.5. 既节省了时间和金钱，还使工作更加灵活，所有这些都创造了经济价值，也代表了利润
  
• 5.7.4. 完成循环的关键是要将利润重新投入项目中
  

5.8. 开源的商业化仍然颇具争议，因为这有时会被认为是在利用开源项目和开源开发者为企业谋利
6. 开源的商业化模式

6.1. 作为更大商业软件包的依赖项或组件

• 6.1.1. 是将开源软件作为更大商业软件包的依赖项或组件使用
  
• 6.1.2. 是最常见的开源软件商业化形式，也是大多数人非常容易忽视的
  
• 6.1.3. 当依赖项或组件作为更大的商业软件包的一部分使用时，需要确保在开源代码中保留适当的归属声明
  
• 6.1.4. 使用软件包数据交换的简化版许可证标识符可以使FOSSology等许可证扫描的工具产生更准确的结果
  

6.2. 服务和支持

• 6.2.1. 服务和支持是开源商业化较早的模式之一，由红帽公司通过其Red Hat Linux Enterprise支持计划推广
  
• 6.2.2. 开源软件本质上是免费使用的，但与所有软件一样，最终用户会遇到问题或有其他需求，需要有人提供帮助
  
• 6.2.3. 对于公司来说，其业务所依赖的软件出现问题可能带来巨大的影响，如果有所谓的“可追责的对象”确实会使他们在使用软件时感到安心
  
• 6.2.4. 传统的呼叫中心或支持中心，人们可以与中心内的某人讨论他们遇到的问题，并获得有关解决问题的帮助或方法
  
• 6.2.5. 帮助安装或实施开源软件，如设置服务器或进行定制
  
• 6.2.6. 培训和教育，可能是讲师指导与线上培训，或者可能是像Packt这样的图书出版商出版关于使用特定开源项目的图书
  
• 6.2.7. 最大的挑战也是其最具吸引力的地方就是进入门槛低
  

6.3. 开放核心

• 6.3.1. 开放核心仍然是一种常见且有效的商业化策略
  
• 6.3.2. 与开放核心类似的模式是，开源可以作为一个基础框架，然后有多个商业扩展插件可与之连接或集成
  
• 6.3.3. 许多专用设备驱动程序在商业许可证下被设计为与Linux兼容
  
• 6.3.4. 在Hadoop等生态系统中也看到过这一点，供应商会构建从数据可视化工具到Hadoop的集成，以利用存储在数据湖中的数据
  

7. 为商用设置项目

7.1. 为商业供应商提供一种使用项目的方法，可以吸引更多的使用者，也可以带来更多你之前可能未曾想过的使用方式
7.2. 可以增加新贡献者和维护者，帮助支持和推动项目，并帮助改进项目的运营方式和代码仓库的质量
7.3. 品牌和知识产权管理

• 7.3.1. 依据项目所使用的许可证，供应商应该对其产品使用的项目进行恰当的归属声明，这是非常重要的
  

7.4. 认可和一致性计划

• 7.4.1. 认可供应商是项目的用户，不仅能够表明善意，也是对开源项目本身的认可
  
• 7.4.2. 最简单的方式是项目在其代码仓库中新建一个ADOPTERS文件
  
• 7.4.3. 如果用户不仅愿意表明自己是用户，而且愿意提供背书，那么可以考虑用户推荐或案例研究计划
  
• 7.4.4. 建立一致性计划通常采用项目与特定供应商之间签署法律合同的形式
  
• 7.4.5. 一般步骤
  
• 7.4.5.1. 确定什么是一致性
  
• 7.4.5.2. 当确定了什么是一致性后，就可以开始正式定义要求了
  

1. >  7.4.5.2.1. 第一部分是技术部分，社群可以定义实施方式或应用程序需要做什么才能符合一致性，也可以定义在支持或服务一致性的情况下，供应商应该具备什么能力>  7.4.5.2.2. 第二部分是商业要求，通常意味着对项目的某种资金支持以及供应商在指定期间维护技术要求的义务

复制代码

• 7.4.5.3. 项目需要建立处理一致性申请的运营流程
  

7.5. 一致性计划是为项目筹集资金的绝佳方式，因为我们都知道运营一个开源项目需要成本

来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除