开源模式

企业开源模式

开源的四个时代：

• 弱版权时代。哪来的闭源。Unix 在 AT&T 诞生，它以低廉甚至免费的许可分发源码。
• 自由软件时代。开源就是自由。理查德·斯托曼（RMS）发起了 GNU 计划，发起了『自由软件运动』。
• 开源运动时代。开源为了对抗。Mozilla 开创的开源运动重塑了整个技术界。
• 云原生开源时代。开源可以赚更多的钱。云厂商为了扩大市场份额，开始运用开源战略。

对于企业来说，企业使用开源可以：

• 提高软件质量
• 降低总拥有成本
• 改善安全防护
• 为云技术云原生设计
• 能安全利用开源技术
• 获得最前沿创新技术

开源盈利模式

直接盈利

• 付费版本。如开源的 Nginx，以及更多功能的 Nginx Plus。双重许可、商业使用收费、部分组件收费等。
• 咨询/服务。如 JBoss、Spring 通过提供技术支持、培训、二次开发支持等技术服务而获得收入。
• 托管模式。通过免费开源的 MongoDB 吸引用户。推出 MongoDB 数据库托管服务等，增加创收渠道。

间接获利

• 建立内部协作。增强组织内技术氛围，共享团队间的技术资源。
• 打造雇主品牌。在技术社区建立品牌形象，和杰出贡献者保持良好的关系，有助公司技术招聘。
• 构建合作生态。与上下游供应链建立合作，建立在该领域的权威定位。
• 参与标准制定。借助于社区力量，一起促进行业建立标准。
• 推广技术理念。将新的技术理念融入开源项目中，促进整个行业往前发展。

四种模式

大公司采用策略示例

企业开源五大支柱

• 组织支持。开源是一种开放创新型的组织模式，需要自上而下的支持。
• 工程能力。开源项目的工程能力是对外展示工程能力的渠道。
• 开源文化。开源世界有独特的文化基因：开放、协作、透明等。
• 产品思维。每个开源项目都是一个产品，都需要像产品一样对待。
• 社区与生态。活跃社区，构建生态，是一个开源项目强大的必由之路。

企业开源能力全景图

| 组织支持 | 工程能力 | 开源文化 | 产品思维 | 社区与生态 |

使用开源

开放技术构架

优点：

• 更容易招到适合的人才
• 开放技术降低研发成本
• 社区己有拥有丰富的资料
• 技术已被验证过
• 易于寻找迁移方案
• 关注于高优先级的部分
• 无需担心『供应商-锁定』

运营挑战及风险

阅读开源软件源码

最近的一段时间里，我在研究 Android 配套工具和 Android Studio 相关的实现，以及它们如何配合完成一个 APK 的构建。因为整个系统各个模块之间的关系过于复杂，除此，不同模块之间也包含了大量的代码 —— 无论是从行数上，还是从函数长度上来说。（PS：顺便吐槽一句， @google.com 的一部分人写的代码也是又臭又长）

从总体的思路上来说，在进入代码阅读之前，我们需要：

1. 理解代码背后的业务流程
2. 理解架构设计的思想

从而我们才能理解主流程（脉络）。针对于此，我们会发现一些不同的模式：

1. 借鉴他人。从他人的学习笔记中，理解整体的思路和过程。如 Android APK 的构建，Android 资源如何优化，从中理清代码阅读的思路。
2. 源码学习。
3. 借助测试调试。
4. fork 主流程。

它们并不是互相独立的，往往是结合一起使用的。

借鉴他人

这种模式，可以实现快速地学习。它存在的一些明显的缺点是：

• 学到的东西是二手加工过的。
• 部分的代码可能与真实的情形脱节。

所以，它适用于你想快速了解某一部分的功能，从而了解全貌，随后我们就可以深入某一部分进行了解。

在这种模式之下，我推荐：通过购买、阅读书籍的方式来学习。如果能买到书便是一件幸运的事，因为它已经经过了系统性的加工。唯一的问题可能是上面的代码有些老旧。但是，它更加的系统化、完整，方便我们理解，并减少搜索资料的成本。

为什么不是网上找资料？：

1. 找资料需要投入时间成本
2. 资料不一定详细

如果你能直接找到详细的资料，毕竟花费的时间足够短的话，那么也是没问题的。

源码学习

源码学习是一个需要花费大量时间和精力的事情，除非万不得已，否则我也不想用这种方式。因为，我们会缺少大量的上下文，这些上下文可能导致我们理解出现一些误差。

前期准备：

1. 合适的工具。最好是~~收费的（🐶）~~能用上的。
2. 合适的存储空间。像 Android 这样的系统，clone 下来就要 120G，编译的话，估计得达到 200G 吧；而像 Android Studio 的源码，clone 下来也要 60G。
3. 寻找阅读的模式。
4. 尝试去构建应用。它不一定可行，但是如果可以的话，会节省你大量的时间。

源码学习是一个非常重的学习模式。我们要花费大量的时间：

1. 在代码间跳转
2. 梳理业务逻辑

所以，还有一些不错的犯懒的姿势：

1. 通过书籍来加强。我一直觉得对于学习来说，阅读书籍是最理想的方式。因为寻找资料需要成本，而多数的书都会起到一个索引的目的。
2. 寻找相似的轮子。一个有意思的技术，必然有很多公司、很多人都研究过。他们都会尝试去创造类似的轮子。唯一的问题是，我们要学习到什么程度，如果只是理解的话，那么看看别人重复的轮子也是可以的；如果是为了深入的话，那么还得回过头去看看源码

借助测试调试

对于调试来说，我们还会面临的一个挑战是：诸如我这样的入门级 MBP 配置，对于大型系统来说编译根本不够用。应对这种问题的一个比较良好的姿势是：通过 IDE 调试测试来完成对部分代码的调试。（PS：这种方式也适用于业务代码的开发）

如果我们可以在应用的入口中创建某一模块对应的测试，那么我们就可以快速调试整个应用了。

fork 主流程

对于我来说，我觉得只阅读源码是一种只为了解决一时问题的方式。同时，像我这样的凡人，对于某些知识和内容，只要不使用，我可能隔个十天半个月，我就忘光了（虽然我一直觉得这是一件好事）。

边阅读代码，边 fork 项目，我们还会有一些挑战：

1. 语言的熟练度和模式。对于熟悉的语言来说，比如日常编写业务代码的时候，我们并不需要理解于诸如类加载器、元编程、字节码这一类的复杂模式。
2. 新的框架、工具或语言的学习成本。比如，我在过程中就遇到需要理解和学习 Gradle 插件的一些构建机制。
3. 代码中大量的、无用的异常处理的代码。
4. 别人的代码都是 💩。（PS：一个月后自己的代码也是屎）

所以，还有一些模式：

1. 划分模块边界。寻找架构图，通过架构图来划分模块。
2. 切片化运行。一个模块，一个模块来理解整个系统。如 IDEA 插件的编写、IDEA 插件与 Gradle 如何交互，Gradle 插件的原理与编写，Gradle 如何调用其它命令行工具，命令行工具的原理与编写。
3. 通过测试运行。如针对于 ApkAnalyser 这样的工具，我们可以通过单元测试而非构建一个 CLI 的方式来运行。
4. 选择另外一门语言。因为别人用 Java、Groovy、Kotlin 编写的应用，如果你用 Rust、Go 再写一遍的话，那么你就能一次学到两个东西了：一个是新的编程语言，一个是这个开源项目的代码。

README 输出

为了方便我们查阅和其他/她人使用，我往往会把相关的内容记录到项目的 README 上。

• 相关的文档资料
• 相似的开源项目
• 过程中的内容产出
• 代码简要说明
• ……

这样一来，其他/她人在学习的过程中还能 GET 到相似的思路。

结论

最后，简单做一些成本对比：

一些结合模式：

1. 阅读二手资料，根据二手资料理解主脉络
2. 编写主流程调用链，理解架构设计理想
3. 借助开源软件的测试调试，理解参数及流程
4. ……

你呢，你有什么好用的模式？

开发者体验

关注开发者体验之前，应该确保核心功能：完善 + 稳定。即你需要提供可用、稳定的特性，再去提升总体的用户体验。除非，对于你的系统来说，你在一开始就不缺用户。

开发者体验六要素

开发者门户成熟度模型

在编写这篇文章的过程中，刚好看到了一篇对于门户的度量模型，《How Mature Are You? A Developer Experience API Maturity Model》简单地翻译了一些国内适用的部分（详细见原文）：