杂感 - 基于开源产品的技术选型

你是否了解开源？

最近，和公司里的不少同事聊了几款开源产品，发现绝大多数的同事对开源的定义，还是仅仅处于 可免费获取 的阶段，对整个开源的生态并不了解。这在后续的使用和二次开发上出现了很多问题。

在交流的过程中，有三个最常见的观点：

开源的鼻祖首推 Richard Stallman，是一个很有趣的大胡子。有兴趣的读者可以阅读其作品 - 《大教堂与集市》，或者听他的相关演讲。如果你已有所了解，可以完全跳过本节。

这里，我简单地描述下个人看法：

传统公司的开发方式是基于闭源的，所有代码归属于公司资产。产品出现问题时，只能由该公司的开发者定位并修复。在这样的模式下，从整个社会的角度来看，许多公司在相同模块上造了参差不齐的轮子，存在大量生产力浪费；从使用者角度来看，很多紧急的问题，只能期待公司安排人员解决。

当开源软件思想被推广后，优势非常明显：用户可以关注个性化需求，无需重写整个产品；有能力的程序员可以贡献代码修复问题，甚至引导整个开源产品的发展方向。

当然，成功的开源产品背后，肯定需要 基金会 和稳定的 运营团队 开源产品是市场经济导向的成果，自然是最符合市场需求的产品。

优秀的开源产品会提供大量接口。例如 k8s 支持各种网络、存储，prometheus 支持多种界面、持久化存储等，也会提供 HTTP API, web hook 等高度定制化的接口。在绝大多数的情况下，许多侵入源代码的二次开发，只是用户不够了解该产品。

为什么我这么反对侵入代码？当然，侵入代码的程度各有深浅，但一旦修改源码(能贡献到开源产品上的另说)，基本都是越改越多，基本走不回来了（切肤之痛！）。如果无法跟着开源产品同步更新的话，功能开发、问题修复带来的成本只会越来越高。

了解一款开源产品，详细地阅读其官方网站、github说明、版本更新说明，比直接阅读代码好得多。固然，要掌握开源产品，阅读代码是最底层的，但很多开发者误认为了解代码才能体现水平。如果对源码很有兴趣，阅读其中几个核心模块的代码逻辑，足以让你成为领域内的专家。

在开源产品中，阅读文档（最新的文档基本上是英文的）的重要程度被严重低估，也就导致开发定制模块的方案存在诸多问题。

开源产品是一个逐渐发展的产品，前期存在诸多弊端是很正常的，但只要能解决行业内的一个关键性痛点，就会有大量的使用者，产生大量的实践经验，也就有越来越多的人来贡献代码，使得产品越完善。这是一个正反馈的效应。

这里，不得不提一下，中国近几年的开源生态发展迅速，代码贡献量激增，同时也有不少的开源产品放到社区内，比如小米、美团、阿里等大型公司。但是，绝大多数项目开源后，没有一个很好的维护、运营组织，导致许多优秀的产品雏形没有继续发展。

开源产品在不断更新的过程中，越来越完善。对使用者来说，经常有各自关心的特性或bug修复，促使对原版本更新。这时，就体现了不侵入源代码地进行二次开发的优势了。

本次聊的话题有点宽，个人下次还是会找个相对窄的切入点，深入下去。

在公司内实现一款开源产品的落地，不仅仅要考虑技术方面的问题。接下来，我会更新其余方面的心得体会，欢迎各位点评~