开源的几个层级

//www.greatytc.com/p/143aae61327e

开源的意义是什么？

公司或个人，对于开源的基本诉求有两个，1、证明自己很牛逼 2、证明自己很牛逼并且可以帮你解决问题。第二点的修为，就看各家各显神通了，因为商业模式就在这儿，譬如Red Hat。

如何更好的参与开源活动，通过开源提升自身竞争力，首先要先分析开源活动中涉及的技术点、工具、流程、角色。搅和在一起会分析肯定行不通，也想不透彻，接下来我们准备用分层的方式对开源活动进行思考（每个开源项目各有特点，下文只列出了通用的惯例，如有遗漏、错误还请多多指点，多谢）。

产品研发无外乎人、物、事，从不同的维度思考开源，我们可以得出不同的结论：

1.从传统研发的角度

传统研发、瀑布式模型，对流程讲究，对设计讲究，所以层级也讲究，恨不得把OSI7层模型拿来用。

1.1.开源代码

代码级别开源——代码剪贴即可用，如何把合适的代码改造并融入到现有的系统架构中，是使用者需要思考的问题。遇到编译问题、不同运行环境的适配问题还是需要自己解决。

1.2.开源类库（组件）

STL、glibc，比直接google到的代码段要高一个层次，具备完整的API体系和测试用例。曾经用过德国的muParser做数学表达式解析，预估1周的工作半天搞定，但带来的问题也是开源共有的问题，后续再细说。

1.3.开源框架

Spring、Django、Flask、AngularJS，实现了专业领域的通用基本功能。拿现在最热的深度学习框架TF为例，开发人员不需要太多的编码量就可以实现手写数字识别。当然，调优工作、定制内容还是需要根据项目的不同，做后续的开发。

1.4.开源平台

以虚拟化相关的Linux、OpenStack等为例，提供裸金属、虚拟化的基础资源。这块很有意思，内核都没法直接商用，发行版本之间的差异需要选型时关注。

1.5.开源软件

Nginx纯粹作为端口映射时候，我们理解为软件，当拉取了企业分支维护、以web前端服务器形态作为产品一部分时，我们认为是webSvr框架。

1.6.开源架构

和框架不同，架构是思想层面的，类似c++编程思想。

在开源领域，影响最深的是Google的那三篇论文。Google没空把产品开源，只是开源了架构思想，却让业界忙乎了很长时间。

2.从DevOps的角度

在DevOps工具链中有自研、外购、开源几种，以开源的为例，CI的Jenkins，基本上拿来就用，需要一定量配置工作，除非遇到真的很特殊的情况，一般建议从开源社区寻求解决方案，如Jenkins的plugin。不要重复发明轮子！此外，在思考自己项目的“特殊需求”是否合理?

2.1.Dev tools

版本控制、代码托管、评审、自动化构建测试，目前业界都差不多，不多说了，不然太low。

2.2.CI、CD

这块用的最多的是Jenkins，从Hudson开始跟，直到写点plug-in贡献社区，经历了这么长时间，还没有发现有啥不好的地方。。而且Jenkins也随着容器技术升温、迅速退出容器CI、CD相关的支持，社区活跃度真的很重要！

2.3.Ship

和持续集成有差别，和Deploy也有点不同，借用docker的build、ship & run里的ship表示一下。（其实，我想说shit，因为这里问题最多~）

Ship级别的开源，如configure，代码下载后，通过脚本自动识别当前运行环境，编译并部署到环境中，小而美的开源项目非常适合，大型应用有点力不从心。另外，各种依赖的处理也会让这个过程变得很微妙。Java应运而生，容器、微服务目前也大是红大紫，

2.4.Ops

运维这块内容很多，可以分为部署、配置、监控、分析。Ansible、zabbix、chef等等在我们的开发环境中都有使用。

目前在用ELK做一些日志维护分析上的探索。

3.从项目运营的角度

项目运营开源，这有点不太好理解，简单说就是将运营公开透明。Open Source, 关键是Open。

大家可以参考"Thoughts on Running an Open Source Project"，这篇文章

阐述了开源运营中的几个关键点：社区、Roadmap、Code Contributions、README，说明了不少问题。其中项目透明化是作者着重提出的，这和我们一直强调的公开透明原则不谋而合。

文章链接：https://lornajane.net/posts/2012/thoughts-on-running-an-open-source-project

此外我们再做如下几点补充：

3.1. 提案

结合Code Contributions，github的pull request,、issues，以及jira可以解决一部分轻量proposals。但提案的问题在于频繁讨论，需要有固定的地方存放，并定期更新提案内容。

目前，没有特别好用的提案IT系统支撑，在wiki上创建提案页面是比较主流的做法。

3.2. 讨论

从投递率、归档性看，Mailing List首选。统一的转发邮件地址对于很多大公司的邮件白名单，也省了不少事儿。

3.3. 会议

例会、meetup、峰会(待补充)

4. 后记

开头提到了人、事、物，文章介绍了"事"和"物"，还剩开源中的"人"，也就是各个不同角色在开源活动中的工作内容。这次不打算展开，主要角色都知道，不同项目会有差异，等我梳理好了，在和大家分享。

最后，感谢DBA+社群的发起人杨志洪老师，没有他的催促，我的简书不会开张。