开源生态构建及业界优秀实践
一、开源项目、社区和产品
1、什么是开源-项目还是产品？
很多人认为开源就是将代码放在某个代码托管网站上，比如 GitHub、Gitee 等，把代码开放出来。但这只是一种形式，实际上我们需要理解开源——真正做开源的意义是什么？
在 2013 年前，开源是一种文化和精神，按照现在比较流行的说法：开源代表了西方自由主义精神，是一种文化的追求，或者个人诉求的表态。因此如果仅仅只是将代码开放出来，而没有将想要表达的事情表达出来，这只能说是做了形式上的开源，同时这也是开源的一个误区。
而在 2013 年后，随着 Docker 在湾区的兴起，开源越来越多地跟经济、产品以及商业模式等紧密联系在一起，这时的开源代表了自由经济的一种方式，包括产品运营方式，或者研发模式方式，这些都在发生改变。2013 年是一个非常明显的分水岭，2013 年之前的项目，比如openStack 等，但它们最终的结果正如大家所见，并未真正流行起来，而 2013 年之后的项目，比如 Docker 等，到现在近 10 年，都有被大众广泛使用，因此 openStack 虽然也是开源，但它没有真正把握住机会、做好商业模式。
开源背后的精神究竟是什么？2013 年之前是个人开发者的文化，包括个人思想、形式的表达，2013 之后是经济形式的表达，而最近这两年，不仅仅是经济形式的表达，更是政府政治意志的表达，比如国内的开放原子开源基金会，国外的包括美国的很多政府部门，出台了各种规定，包括对开源的各种限制，比如 GitHub 封过伊朗、叙利亚、俄罗斯等。开源越来越受到政府政治、地缘政治的影响，越来越不如最早的精神文化般纯粹。开源的每个阶段都有对应的特点，现阶段开源更多的是在国家层面上，认为开源需要被管理，这也是一种自由经济形式与政府的计划经济形式的碰撞，开放原子开源基金会也正是在这种情况下成立的一个开源组织。
开源不仅仅是开放了源代码或者硬件设计，或者写了一个大家可协作的文档，比如基于 CC（Creative Commons）协议的开源共享，开源的背后到底是什么？对于我来说，通过这些年的工作经验来看，我认为开源项目是一个很纯粹的产品，如果想把它做好，需要投入很大的精力。开源可能没有具体的定义，但需要大家思考：在开源背后你代表的是什么？如果个人写一个开源项目，代表想要表达对这件事情的看法和逻辑；如果公司开源了一个项目，则代表对商业的诉求；如果政府做了一个开源项目，那么代表了政府的意志；这些都是开源背后需要深入思考的问题。
2、什么是社区？
社区是一群人因为共同的兴趣和爱好，不论时间、空间、年龄、性别、国际、种族等等聚集在一起形成的一种聚集形态。当然可以给这种形态设计一个门槛，签署一些合同或者文件，或者其它的任何形式的仪式。在国外，可能称之为“club”。
在 2020 年，有几个以前一起做研究生的朋友，都是技术背景出身，因疫情原因封控在家，大家一块视频“云喝酒”，慢慢地形成了一个小的 community，我们叫做“云原生喝酒 SIG”。在这个SIG里面的成员，基本都是有技术背景，然后喜欢喝点小酒，啤酒或者威士忌，因为共同的兴趣聚集在一起，慢慢形成一个非正式的组织，不需要签字/文件。
但我们经常性会看见很多公司会说：“XXX 公司签了 CLA，加入了 XXX 社区。”如果有签署的门槛，签了某个文件才能加入某个社区，那这个社区其实不是 open source 的社区，而是叫做“行业协会”或者“组织”，那就涉及备案、查询以及一些复杂的法律问题。因此在开源的社区里，只要大家在使用这个工具，或者一些想法的交流，甚至只是尝试下载使用了，那也是社区的一部分，而不是说一定要签 CLA，才是社区的一部分。
3、开源生态在 2 B和 2C 之间的过渡
开源对商业有什么帮助？
1）开源可以形成事实标准，会产生隐形绑定
很多公司经常会讨论为什么要做开源？开源有时是一种事实标准，只要有标准就相当于绑定了客户（因为商业模式也是一种垄断），形成了标准就形成了商业利益。
2）开源会形成生态，对商业市场产生支撑
比如 Docker、kubernetes 就是生态，对商业市场产生支撑，无论哪个做云服务的厂商，都有在做 kubernetes 以及相关的各种定期服务。
3）开源是产品口碑的双刃剑-马太效应
开源做的越好，对产品的口碑越好，开源才会越做越好，这时一个向上积累的过程。如果在一开始口碑就做差了，后面就算产品做好了，也会形成越做越差的效应，这就是马太效应。因此一旦开始开源，一定要谨慎选择，因为如果开源没有做好，会影响到产品，从而影响到产品的销售。
To C 商业模型的开源项目：目前很少有项目对 To C 在商业上有特别大的帮助，主要还是注重做生态。
To B 商业模型的开源项目：开源项目主要是针对商业合作伙伴，即商业的上、下游，这时伙伴是最关键部分。
如果没有形成社区就想做一个商业生态，希望很多人都来使用这个产品，这是不现实的，更建议直接销售这个产品，将售前、售后队伍壮大，这种方式会比做“跨过社区做生态”这件事更加能落地。因此决定开源的公司 / 上游的公司，优先考虑一个问题：该项目是否可以形成一个生态？形成商业生态的基本原则是该开源项目有很多人都在使用，比如 Docker，任何一个做前端或者后端的人都可能会用到 Docker，Docker 拥有非常广泛的群体，在社区形成之后才慢慢开始做商业，到现在 Docker 还在盈利中。
二、金字塔模型和沙漏模型
1、开源之战略-金字塔模型
在公司负责开源，或者是商业开源运营者，或者产品设计者，都会遇到投资人的发问：“你为何要做开源？开源给你的商业利益带来什么好处？”尤其是大公司，面临的挑战可能就更多，涉及的人员更多，小公司可能一两个老板就能直接拍板，因此如何说服投资人来做开源呢？ 主要分为以下几个步骤：
1）制定战略
战略是企业开源的灵魂，没有灵魂的开源项目不会获得成功。
“将开源作为企业的战略，开源给企业带来的价值是什么？”需要将这个事情向领导层解释清楚，如果公司的领导层，比如董事会等，没有开源的战略意识，就算是做了一个开源项目，那么这个项目在公司里也做不大，因为没有战略就没有战略投资，没有战略投资就无法将该项目做长。如果没解释清楚，当跟公司建议做 marketing 宣传时，领导层会疑惑做了这个宣传后会带来多少订单，但这其实跟市场宣传没有直接逻辑关系，为公司商业项目来说，将资金投入到开源中，包括社区、生态建设等，是无法获得直接利益回报。 因此想在一个公司里将开源这件事做好，那么一定要将开源变成公司的战略，灌输到管理层，开源项目才有机会成功。
2）设计行业标准或事实标准
如果公司都是开源的，比如 RedHat 模式，全部以开源为核心展开的服务，就不用再考虑金字塔模型了。
但如果公司是做传统生意，我们需要建立行业标准或事实标准，根据项目的具体情况来说服管理层。
3）设计开源项目
一定要将开源项目当作产品来设计，关注开发者需求而不是追求项目的成就感。如果仅仅只是开放出去，开源项目很有可能活不长久，目前国内传统的几家大厂，每年开源的项目加起来至少两三百，但目前依旧活跃的项目并不多，因此开源项目需要设计。
如何设计开源项目？ ① 商业目标：将开源项目当作产品，思考商业目标是什么。 ② 用户体验：用户体验怎么样？从用户出发，操作易上手是最基本的要求。
4）建设生态
这是商业的载体，壮大用户群体、活跃开源社区、让合作伙伴使用等，让整个生态生机勃勃，健康发展。
2、开源之产品-沙漏模型
沙漏模型最核心的点在于这个图中最细处，即开源项目，也可看做产品，把握好这个最细处，整个过程就不容易失控，而且需要清楚知道面向的受众是谁？很多情况下大家以为面对的是普通开发者，然而不是，从商业角度上看，项目要面对的是下游的商业合作伙伴的开发者，比如前两年我做欧拉运营，面对的不是使用欧拉的普通开发者，而是使用欧拉做商业发行版的厂商开发者，比如麒麟，只有下游的商业合作伙伴获利，才会在我们的上游投入人力，一起将这个开源项目做好，形成一个良好的循环。
在形成循环之后，核心是控制中间产品功能的设计，需要松弛有度，卡的太紧其他人无法参与，卡的太松所有人都来了容易乱套。比如 Cloud Foundry，在 2011 年的时候，国内的几家大外企公司员工基本上很多人都有参与，到现在成立了基金会，也有开放治理，但参与成员并不能真正像 Cloud Foundry 一样贡献代码，这种就是卡的太紧情况。
3、沙漏模型成功案例-Kubenetes
Kubenetes 的核心产品特性，比如 CSI，这些接口的标准都被 Google 所控制，其他公司一般进不去，如果想要在里面推广一些事情，那就得和Google 先打好关系，这也说明 Google 有技术能力以及社区影响力，能牢牢把控住 Kubenetes。Kubenetes 的下游商业伙伴包括国内外几大厂商，这些厂商会将自己的特性往上游推，在上游投入人力，因此形成一个良好的循环，还能够通过 CNCF 的稳定治理给所有人一个可以发言的机会。
4、沙漏模型失败案例-Docker
Docker 拒绝改变，拒绝别人给它的意见，因此 Docker 逐渐在走下坡路，最后还被拆分，虽然拆分以后据说今年又挣钱了，但这只能说明 Docker 的生态做的不错，而在社区把控这一块，Docker 卡的非常紧，非常不利于开源，这也是一个典型案例。
5、沙漏模型失败案例-OpenStack
OpenStack 失败的点在于无法把控中间处，没有一到两家具有非常强技术实力的公司把控项目，造成了 OpenStack 里项目满天飞，各个项目、各路人马互相厮杀，也因此导致 OpenStack 开始越来越散、越来越乱，尤其在Docker 的冲击之下，OpenStack 逐渐停了，连基金会都改名了。而捐到CNCF 里的项目虽然也很多很乱，但没有影响到生态的发展。
国外做 OpenStack 的厂商可能不多，但国内还是有很多做 OpenStack 的厂，在小的范围、小的模式下，有些厂依旧活跃着，这也说明它的商业在某些程度上还是挺成功。
三、同心圆模型
1、企业开源之生态-生态伙伴同心圆模型
同心圆模型是指，当我们在企业内做开源时，由近及远，谁是我们可以合作的人？尤其在一些大型公司内，做一个开源项目不是一个团队的事，这个项目公司内部很多团队都要参与，因此需要平衡公司内的利益、公司外的利益，包括对产品设计要有想法、竞争力，也包括说服各个 BG 的老板，这些都需要投入很多精力，如果能将公司内部的这些力量整合在一起，形成核心开发者圈子，这个项目基本就成功了 80%。
第二就是是否拥有忠实的追随者？从商业角度来看，追随者是判断是否能说服公司上下游企业的开发者的关键，比如 openEuler，需要维护的追随者是麒麟、统信。
圈再往外就是当真正投入到开源社区里，是否能形成一些更多的个人用户，俗称散户。如果文章写得足够好、功能特性足够吸引人，那确实会有很多散户被吸纳进来。比如 TKEstack 中的一个特性，是针对 GPU 的虚拟化混合部署的方案，这是互联网公司才有的特性，因为互联网公司会购买很多卡，只要英伟达开始出售就会购买 20~30 块来使用，因此形成一种易购的环境，为了将这些易购的卡发挥最大的作用，需要将它们平衡在一起，形成一个调度管理，这是当时 TKEstack 主打的功能，后面有听说一个房屋租赁公司，内部就有在使用 TKEstack，这家公司跟社区无联系，也与华为和腾讯没有商业来往，但正是因为 TKEstack 符合它的需求，才开始内部使用。因此产品做的好有特点，也能够吸引很多散户。
最难做的是什么呢？是最外边这一圈的竞争对手。很少能有两家公司在商业上有非常明显的竞争关系，却能合作做同一个开源项目，一般情况下由中立的基金会从中协调、平衡。在基金会里，所有人可以吵架，但都需要有理有据、合情合理，不能无差别性攻击，然后形成统一的观点之后，不允许私下乱做一些小动作，这些规则不是一开始就有，而是基金会从中调解，这同时也是基金会的价值。
2、企业开源-开源就像投资
这个就是前面所说的金字塔模型理论，即一定要有投资，开源就像是做投资，一定是企业老板有投资才能做，比如员工全职在公司做开源，这些员工的工资、奖金等，都来源于投资，没有投资，开源项目不可能做得特别成功或者特别大，当然也有些因为个人兴趣做好的开源项目，可这种情况非常少。
3、企业开源之案例-TKEStack（开源就像创业）
做开源好比创业，需要天时、地利、人和同时具备，三者缺一不可。
1）天时在正确的时间做正确的事情 – Kubernetes 已经成为现在基础架构中的主流选择，这时候开源 TKEStack 并不需要更多的精力去教育市场。 把握技术发展趋势，顺势而为 – TKEStack 的整个管理是 Kubernetes On Kubernetes 的方式，一切功能都做成插件，顺应 Kubernetes 的大潮流而设计开发。
2）人和开源最重要的就是生态，没有人参与的开源项目不算开源项目 – 内部集合了 TEG 数据平台部、企业 IT 部和 CSIG 云产品部容器产品中心，同时得到了 TEG 研发管理部和运营管理部的大力支持。
找到项目所属的社区，善于利用社区力量，构建核心的维护团队 – 国内已经有丰富的 Kubernetes 社区，这是发展 TKEStack 的良好土壤。
让开发者觉得好用，并不需要满足所有人的需求 – 没有完美的产品，所以要锁定自己的目标用户。
3）地利尽量利用本地社区建立核心团队，在身边的人开始发展社区用户和生态 – 公司内有机会使用 TKEStack 的团队是建立社区的目标。
选择项目的范围，利用自身影响力的范围划定首要的区域 – 不盲目扩展项目的范围。
四、openEuler 实践
1、通过 SIG 践行商业伙伴之路
SIG 成为运营的最小单位，但是也容易造成社区割据的局面，不同的商业伙伴在其中相互影响；需要有社区的核心来平衡各方的利益，带领社区前进。
Special Interest Group（SIG）作为 openEuler 运营的最小单位，如果每个 SIG 都非常活跃，社区很可能就会被毁了，这里同时有一个新问题：是否要无限制成立 SIG？一个 SIG 从成立，到运营好，到活跃起来真正成为社区中前进的动力，这个过程需要很长时间进行磨合。
因为成立了很多 SIG，所以成立的过程中相对没有那么多苛刻的要求，比如考试。社区成立 SIG 逐渐转变成不同的商业合作伙伴需要成立各种各样的SIG，这里就有商业导向的问题，也因此很容易形成割据的局面，但同时能发现运作 SIG 这件事是好的，比如麒麟与统信，两者在操作系统这个市场上是敌对状态，但这两个公司还共同维护了一个 SIG，而且维护的还不错。
而社区中总有一些令人惊喜的人和事存在，比如中科院软件所，它在整个操作系统，包括开源领域的投入是非常有价值的，他们在 openEuler 里面做了很多踏踏实实的工作，很多事情都是软件所在默默无闻的干。如果大家都能以软件所那种心态来做开源，那么这个社区会做的很好。同时因为公司有各自的商业利益，这需要有人来进行平衡，因此需要考量社区运营者，包括核心团队，以及商业领袖是否能进行周旋的能力。
第二个问题：要不要把 marketing 行为与社区生态建设进行绑定？现在有个趋势，大家要成立一个社区，就先举办一个大会，请几个院士过来进行宣讲，举办大会已经变成比拼“院士”，这次请4个院士，下次请 8 个院士，再下下次不请院士大会就无法举办了！这个现象非常的不好，其实 marketing 与社区生态是相辅相成的，只要还有举办大会的资金，那开发者大会就可以举办，但不应该把举办这个大会变成一种商业竞争的方式，比如前面所述的比拼“院士”的会，有时不仅要拼“院士”，还要拼“领导”，不仅公司的领导，还有政府的领导...正常办大会应该如此：做社区面对的是开发者，那么举办大会就请重要的合作伙伴开发者；如果是商业社区，那么商业体系更成熟，可以请客户、供应商等；如果面临普遍推广，那就普遍进行邀请、撒网即可。
openEluer 里还有一点做的不错的地方：基础设施。因为 GitHub 上很多基础设施没法用，所以不得已自己做了很多基础设施，比如会议程序（小程序）、会议系统等，能够帮助开发者真正聚集在一起。如果你想要做好一个操作系统的社区，你的基础构建能力非常关键。
2、找到合适的人是这个工作的关键之一
运营包括几种方式：
1）平台运营
比如 CSDN、infoQ、开源社等，这些不做具体的项目，因此不需要技术背景，只要是传统的 marketing 出身的人，或者有从事客户关系维护等，都是可以来做平台运营。
2）技术社区运营
需要有非#### 常强的技术背景，如果不懂技术，但又想做这个社区的运营，那么可以进行学习，没有人生来什么都懂，都是通过后天学习获得。因此做这个社区运营最核心的一点就是摇动技术，至少其他人说了你能够听明白。
做好运营也需要有平和的心态。比如做一场 meetup，涉及到活动议程的设计，该请什么人来进行演讲比较合适，并且有设计演讲内容的能力，能够跟讲者达成一致以及平衡；协调大家的时间等，这些事情都非常琐碎且繁多，因此需要有一个平和的心态，将事情做好。
做运营可能有时候不仅仅是一个运营，还可能是个多方面小能手。比如欧拉早期运营，还需要做一些售前售后的工作，面见客户与客户沟通，了解客户的需求，甚至有些项目需要进行售后的事情，因此需要像一个项目经理一样，从前到后的所有事情一件件搞定，这需要非常多面的素质才能将事情做好。