编者按
随着开源软件的兴起，越来越多的国内企业和个人投入到了开源社区的贡献中，并逐步将开源软件应用到公司的商业软件交付中。《赢在开源》系列访谈是以国内参与开源软件的一线专家发展经历为主线，针对大家关心的开源热点问题进行访谈，旨在让更多的朋友了解开源、认识开源，并引导更多对开源感兴趣的朋友参与到开源软件的贡献中，推动开源软件在国内的发展。
-- 《赢在开源》书籍作者 孙远
“开放是协作的最佳方式，也是创新的根本要素。
-- 开源信徒 李建盛（适兕）”
受访者简介：
李建盛（适兕），开源信徒，青云 QingCloud 产品经理，开源社执委会成员兼总编辑。在加入 QingCloud 之前，一直在做 Linux 和虚拟化相关的开发和管理工作，曾经服务过中科红旗、云端时代等公司，也曾任 InfoQ 中国开源专栏主编。其是Linux 爱好者、开源文化布道师、技术作家、开源之道博客作者，也是分布式系统、云计算普适的死忠粉，偶尔写写程序，热爱读书和健身。
受访者现就任公司简介：
青云 QingCloud 是一家技术领先的企业级云服务商和云计算整体解决方案提供商，也是一个基于云模式的综合企业服务平台。
．·°∴ ☆．．·°．·°∴ ☆．．·°．·°∴ ☆．．·°
访谈正文
╰☆╮ ╰★╮
职业发展经历
孙远：建盛你好，能否介绍一下你的职业经历？
国企工作
李建盛：我是 2005 年大学毕业的，我的第一份工作是在国企--河南日报社。我在那里做了一年的系统管理员，因为岗位的原因，工作任务不是特别重，我可以有很多的机会玩 Linux的各种发行版。
通过一个省政府网站的项目，我接触到红旗 Linux 发行版。当时红旗 Linux 的售后工程师过来进行项目合作，我终于找到了一个可以交流的机会。我记得当时他下飞机的时候已经晚上八九点了，我抓住机会和他聊了起来，当时能够和懂 Linux 的人接触是难能可贵的机会。
加入中科红旗
说来也巧，刚好中科红旗 Linux 当时正在招聘工程师，我懂一些 Linux 指令，中科红旗的工程师让我考虑加入中科红旗 Linux。就这样，我2006年底来到北京，成为了中科红旗 Linux 一名售后工程师，工作任务是出去帮客户装系统。后来我慢慢学习编程和脚本语言，也做一些故障处理，比如服务器宕机、Kernel Panic 的原因分析等。
大约一年后，公司内部有一个研发岗位空缺。我抓住机会在公司内部转岗到了研发部门。刚开始是做安装程序，就是写一些引导程序初始化磁盘、网卡等硬件，软件包的选择，也包括引导双系统启动。后来开始接触一些其他的系统，如基于 Heartbeat 的高可用等，也接触一些实际的项目。就这样一直参与项目并编写程序。直到 2010 年，中科红旗内部有一些状况，我选择了离开。
孙远：当时离开中科红旗，是出于什么考虑呢？
李建盛：我对公司当时的一些走向比较失望，而且觉得这份工作对自己提高技术水平没什么帮助，就有了换一份工作的想法，其实工作换得也很迷茫。还没有怎么来得及思考，就进入了极其快节奏的创业公司。
加入创业公司
2011 我加入了一家创业公司，这家公司的主要业务就是做瘦客户端盒子，但也提供桌面虚拟化产品及服务。我有了带团队的机会，像这样的创业公司，团队通常都是一点点组建的。
开源社区成熟的项目，如 oVirt、OpenStack 等，后来由于不能参与到上游，项目各种失败（这点我专门撰文写过，下文会提到。）
问题出在哪里呢?其实团队中的成员都很聪明，有些人是 Qemu、Libvirt 社区的代码提交者。但是很多时候不得不屈服于公司的某种压力，无论是个人发展、项目发展还是公司盈利，都无法走到良性发展的轨道上。
总而言之，基于开源项目进行商业运作，往往会走弯路。2015年，我越发的感到开源的发展，技术并不是主要的，这一年，我思考了很多，或许思想和文化这些软实力更重要一些，技术不一定能解决问题。
于是，我下决心改变自己的职业生涯，用巨大的勇气，决定做开源布道的工作，希望能够写一些文章，做一些演讲分享。决定做开源布道师之后，陆续的增多了个人的演讲、并开始写开源之道，传播一些开源的理念，其中包括开源的商业价值、开源工程，还研究中国本土关于开源的各种奇奇怪怪的现象。
于此同时，参与到本土的唯一入选OSI的社区——开源社，做一些力所能及的事情，当然主要也是利用文章来传播一些事情。
以上这些事情均是利用业余时间来进行的，主要的工作，仍然和云计算、操作系统技术相关，将普适计算进行到底。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
国内开源的奇怪现象
孙远：国内开源有哪些奇怪的现象呢？
李建盛：首先第一个奇怪的现象是偷换概念。很多公司基于一个开源项目去开发软件，说自己对该软件具有全部知识产权，甚至申请国家专利了。
第二个就是认知的问题，他从上游去克隆一个项目，然后拿过来去封装，不管这个项目有多大，哪怕是 Linux Kernel、Openstack 这样的项目，他们也敢说这是深度定制。
还有一些很矛盾的说法，比如说基于某几个开源项目做了一款产品，然后说我们现在还很弱小，没法去参与到上游上面。还有一种现象是觉得自己开源一个项目后，全世界就应该都轰然过来参与这个项目。此外还有一种现象就是拿国家或者安全这类事情运作，你可以看到一些自主或国产之类的炒作。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
印象最深刻的开源文章
孙远：你写过很多开源方面的文章，哪篇文章让你印象最深刻呢？
李建盛：我在 2015 年写了一篇《为什么基于成功的开源项目的商业产品会失败?》一文。中国的本土开源是在 2000 年左右开始的，之后开源的商业公司层出不穷。这些公司基于当年的 Linux、MySQL 和目前的 Docker、Kubernetes 等开源项目进行商业运作。但这类基于开源项目的商业运作大部分会失败，这篇文章就是阐述失败原因的。
我把我这几年主持项目开发的经历结合起来阐述观点。你看现在所谓的国产 Linux 已经几乎找不到了，基于 OpenStack 创业的公司正在走当年 Linux 的后路。当时为什么有些人做这些项目？从开源的工程欠债、人才的管理、项目的利用、开源选型等角度来分析原因。这项研究是我职业生涯的一个转折点。
我原来博客一直都是在谷歌的 bloger 上，所以点击率很低的。因为文章的读者大多在国内，我现在已经通过公众号将博客迁到国内了，这样大家更方便阅读了。甚至索性开了公众号：开源之道。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
印象最深刻的开源项目
孙远：哪个开源项目对你来讲印象最深刻？
李建盛：最深刻的开源项目是 anaconda，就是红帽系列的 Linux 安装程序。这个程序就是一个标准化流程。程序从一个光盘启动，它本身也是一个小的 Linux，启动的时候不写硬件初始化，然后去识别硬件，之后进行磁盘分区、网络初始化、软件包选择等操作。在这个项目中我的收获很大，第一我掌握和运用 Python 语言，第二对 Linux 整个系统有一个很深认识。这让我在技术上有了一个质的飞跃。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
平衡公司内部的项目与开源项目
孙远：通过这个项目也带动了自己编程技巧的提升。在工作中，公司内部有一些商业项目，而你在其他时间是自己投入开源，那你如何去平衡你公司内部的项目和开源项目呢？
利用业余时间投入开源
李建盛：这个问题涉及到了国内开源软件的现状，我为什么投入到开源工作中呢？是因为我们这些早些接触开源的人，大部分都是利用业余时间投入开源的，牺牲自己的个人时间和陪家人的时间去翻译一些国外开源文章，解答别人的疑问，贡献代码到开源社区。
国外很多开源社区有公司支撑
在国外，很多开源社区和开源软件发行版背后是有公司在支撑的。Kubernetes 背后是谷歌、红帽等公司。而在国内，通常是把一个人投到社区中，只是为社区做工作，而考核这类指标都没有跟上。国内的一些大公司，包括百度、阿里、腾讯，对于开源投入很有限。华为这两年好一点，但是是针对公司内极个别员工的，并不是针对全部员工。
IBM 有开放技术部门，谷歌有开放实验室，英特尔有开源中心，华为有开源能力中心，这些部门会把开源投入的工作纳入到绩效考核中，这包括你在开源社区的系统设计、代码投入等工作。这正是我们国内大部分公司所缺失的。在国内的环境中，基本上是牺牲掉自己的个人时间去做这些事情。工作上基本是没时间去碰这些开源的项目。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
给刚接触开源的朋友的建议
孙远：现在国内确实是有这种现状，像华为、阿里这些国内的大公司会设立开源的部门。但对于中小企业，对开源的投入往往是不足的。有很多工程师和大学生以前没有参与过开源项目，对于这些想投入开源贡献但有缺少实际经验的人有什么好的建议吗？
结合自己的兴趣投入到开源社区中
李建盛：这两年国内开源的环境好多了，因为像我们这样投身开源的人更多了，而且现在开源成了一种默认的技术方向了。随着 GitHub 的崛起和 Linux 的成熟，有更多的成熟的开源项目可以选择，现在大学生们已经很幸运了。投入开源从根上就是教育的问题。要说给建议的话，那就是首先你自己得有独立的能力。分析一下你看好的项目，结合自己的兴趣，然后投入到开源社区中，努力地去融入开源学习中，积极进行沟通，贡献代码提升自己的编程水平。
提高主动性，保持开放，融入社区
其实开源社区对于我们大学生或者是刚毕业这些人的水平的要求是相当高的，除了编程这个硬的技能之外，要提高自己的主动性，保持开放，融入社区中。提交开放的代码，是提升你自己技能最好的方式。眼光放远一点，去上游找一些自己感兴趣的项目去做，但在过程中你会觉得这样的路非常地难，很多困难要克服。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
如何选择开源项目
孙远：现在开源项目很多，很多大公司陆续开源了一些项目。在众多项目当中，应该通过什么方式去选择自己想投入的项目呢？
李建盛：这不是一个本质性的问题，归根到底是一个教育问题。我假设一种场景，有一位学生对于计算机基础理论有浓厚的兴趣，于是去学习很多相关的知识，例如各种算法或者网络知识，之后选择对应的开源项目。上次我参加了北京 Linux 的一个线下活动，参加活动的很多人是做运维的，他们参加活动的目的只是学习一些 Linux 的技巧（例如网络配置等），而这些技巧不是系统化的知识。而参与开源需要你有比较系统化的计算机知识后再做出选择。
一般来说，以大学生的身份参与到的开源社区通常是基础学科相关的，比如操作系统社区。这些社区很少涉及到应用开发。
大学里边会讲很多基础理论，比如会讲计算机的历史，从图灵到香农，再到高德纳，还会讲到一些编码，安全方面等知识。你可以根据自己的兴趣选择一个大致的方向，在这个方向上会涉及到程序语言、词法分析等内容，你可以根据所选择的方向再进行开源项目的选择。
当前市场上有一些计算机培训，比如“21天学会 Linux”或“十期搞定大数据”等。商家用这些字眼吸引眼球，但很少有人能通过这些培训入门的，通过类似的培训很少能把开源生态真正搞起来。
这些培训当然很赚钱，但很少能让学员真正掌握全面知识。Java 有个 SSH(Spring、Struts、Hibernate)的框架，学员学完这个框架之后去企业去找份工作，做些应用开发，但无法为整个后端项目贡献一些有价值的代码。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
开源软件的前景
孙远：对于开源软件的前景，你是怎么看的呢？？
李建盛：开源已经 20 岁了嘛，它肯定是一种趋势。开源将会是一个主流软件工程方法论。比如现在的架构都在去中心化，分布式趋于活跃，当前微服务的设计架构很流行，说到微服务就要讲到康威定律，什么样的组织决定什么样的软件架构。微服务的架构涉及到分布式，组件与组件是平等化的，通过 API 来交互，每个组件是单一独立的。程序员可以将精力投入到每一个小服务中，把它彻底做好。由众多小服务组成的庞大系统就需要采用开源的方式。
这种方式是平等的、民主的，将会是一个未来的趋势。如果软件提供商想把软件架构向微服务方向发展的话，开源是必然的。如果康威定律成立的话，在软件工程实践中开源肯定也是必然的。
开源离开商业发展不下去
开源软件的商业模式会变得更趋于复杂化。开源如果离开商业，也发展不下去的。Kubernetes 跟 TensorFlow 分别成为了容器编排和机器学习的主流。容器编排的项目是开源的，其他项目很难取代它。那么如何通过这些开源项目去赚钱呢？在开源背景下，工程师的视野会更加开放，思想会越来越独立，他们不会被某一个公司所绑架。如果工程师不适应某个公司的环境，其不会受到非常大的影响，反正自己在开源项目里。
开源项目让工程师更加独立和专业
开源项目会让工程师变得更加独立和专业，而且技术的保值是不断的去融合和组合，如果你不开放的话，对于工程师的发展是不太好的，其视野会变的相对来说窄一些。如果是开放、开源的话，那你会借鉴到很多知识和经验。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
开源商业模式
孙远：你是如何看待开源的商业模式呢？
李建盛：我在去年的北京 Linux conference 上跟一位国外的布道师交流过。他认为根本没有什么开源的商业模式，我们所说的开源商业模式不过是一种自欺欺人的假象。你想拿开源软件盈利，有几种方式。对于开源软件，我可以自由的获取、修改、分发。在这个过程中，谁也拿不到钱的。别人看到的不过是代码而已，软件编译、运行等过程可以产生一些价值，你可以雇一些人在开源软件的基础上做二次开发，把软件做的更完善后卖给客户，这是一种商业模式。开源软件本身是没有利益的，你必须围绕它去做一些事情。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
评估开源软件的质量
孙远：开源软件的源码是公开的，有没有一个方法来评估开源软件的质量呢？比如公司需要选择一个容器编排的开源软件，Kubernetes、Mesos、Swarm 都有容器编排的功能,有没有一种方式去度量这个三个功能上比较相近的开源软件？
李建盛：这分几个方面说吧，首先我会辩驳开源软件质量会差的观点。对于 Linux 这个项目，从 1991 年算起，有二十五六年了。它的管理模式包括其质量保障方式，在不断的变化，没有什么是完整的。我们没法证明商业软件一定好，商业软件某些方面可能可以满足你，但有些遮遮丑丑的部分是不开放给你的，所以说开源软件不代表质量差。
其次，对于评估开源软件的质量，可以采用一些方法或者一些工具。你提到了 Kubernetes、Mesos、Swarm 的例子，你可以读下它们相关的论文，了解它们的设计理念，之后你一项一项进行比较，列出适用的场景和解决的问题以及不足之处。
这些技术上的优劣可以通过比对来衡量，其实这三个项目单单的从技术上讲是相差不多。在早先，包括 kubernetes 的一些开源项目并不支持 statefull 的应用程序功能特性，在红帽没有加入之前，其实他们都是差不多的，甚至 Mesos 对任务的处理还有一定的优势。那么到最后，为什么 kubernetes 一统天下了呢？这就和社区运营有关了。除了技术之外，你还要考查社区的健康发展。这包括用户的反馈、社区的友好程度、项目的健康程度、商业公司的利益等。活下来的开源项目，不一定是技术最强的，当然技术上也不会太差，技术是个必要条件。除了技术以外，还会涉及到社区的健康程度等因素。
★~☆·☆.~*∴*~★*∴ *·∴~*★*∴*★~☆·☆.~*∴*~★
本篇为孙远新书《赢在开源》第二章，如果支持新书出版，请关注开源社微信公众号，在后台回复“支持”即可查看全文。开源社微信号 kaiyuanshe