整理自开放原子开源基金会TOC主席堵俊平老师2020年11月来浪潮做开源治理分享讲座
何为开源
在讨论开源的经营策略之前，我们先回顾一下什么是开源。浪潮的朋友对开源当然应该是比较了解了，刚才晖总也介绍了我们浪潮在开源方面的积累。但是业界的朋友会有一个误解，很多人觉得开源就是代码的事，代码开放出来了就叫开源。其实代码开放出来是叫Source Available，它只是开源的第一个层次，就是你的代码开放出来，但是能不能下载、能不能转发、能不能被redistribution、被修改，这些权利并不是你开放出来代码就可以。有的时候大家开放代码，但是保留着所有的权利，这就是我们的代码只是供别人参考，跟论文paper一样。
第二个层面就是真正的Open Source，就是这个代码可以被redistribution、可以被修改、可以正式的发布使用，那这种模式我们叫OpenSource，这种OpenSource有严格定义，有一个组织叫OSI（Open Source Initiative），这个组织专门负责开源的事情，它会把所谓的license就是开源领域的授权、开源的许可证做一个认证，只有通过它的认证，才可以认为我们的开源项目使用的license是符合OpenSource定义的。在它这里面还有十大原则，除了要自由分发的权利，自由修改的权利之外，它还有比如不歧视任何人。大家知道前段时间，有些像Mongo啊，redis这些它改了自己的许可证协议，它仍然能称自己是OpenSource，但是这个许可证类似SSPL或者commonsource这种，并没有被OSI认证，因为它可能是歧视了服务厂商，因为它不希望用云这种方式直接对外提供免费的服务，也要对它收费，这种相当于歧视，对这个软件的分发或者对软件提供服务对某个群体相当于一种歧视吧，所以它不能成为OpenSource，这个是第二阶段。
那第三个阶段，叫OpenGovernance，就是叫开放治理，什么意思呢，OpenSource这个阶段可能允许别人免费的使用，免费的分发，免费的修改，或者不叫免费啊，free就是自由的意思，但是在OpenGovernance阶段，你还允许把社区打开，允许外部的人或组织合作加入进来，成为某个部门的贡献者，然后帮助这个项目成长，帮助这个项目继续往前推进，然后一个组织或者一个个人在这个项目当中对项目的管控权相当于完全向public去开放，通过这种方式，尤其是通过基金会的方式可以真正为开源提供最广泛的去接受贡献者和开发者，提供了很好的管控。所以我们认为第三个OpenGovernance，在基金会托管的方式是开源最高的形式，也是在开源领域我们能真正全面构建发展生态的基础
何为成功的开源项目
刚才定义了什么是开源，我们再来看一下什么是成功的开源项目。其实这个是见仁见智的事情，到底什么开源项目时成功的开源项目，一千个读者有一千个哈姆雷特。什么样的开源项目叫成功，其实这没有一个业界公认的标准，我们可以参考一些广义上或者情感上认为比较成功的项目，包括像Linux、kubernetes、spark这些，这些开源项目都有一些共同特点，我在这里试图去总结分析一下，看有哪些特性或者因素，做一个画像。
我觉得第一个，成功的开源项目一定是被广泛的使用的，不管是从下载量、分发量、部署量，或者从library引用量调用量，它一定是广泛使用的，没有大量的用户，广泛的使用，一个项目肯定是不成功的，因为所以的项目所有的价值最终都来源与用户，来源于最终使用者，所以这也要求我们所有开源的项目运营一定要以用户为中心，不能为了代码好看为了炫技去提供一些华而不实的功能，最重要的是项目为用户提供真正有用的功能。
第二个我想说的是成功开源项目给世界带来巨大的价值，这个价值像Linux出来的时候，它打破了Windows或者说其他商业化操作系统的垄断，他是业界第一个大规模使用的开源操作系统，后面有很多商用的发行版去支撑；又比如说像Hadoop，它相当于开拓了整个大数据的时代，在Hadoop之前，大家只有这个需求，但是没有这个技术去解决问题；Kubernetes云原生也是，基本上现在我们很多说的很多云原生，各种PaaS、Saas云原生，也是从Google开源kubernetes开始的；这种技术上商业上的价值也是很重要的特性。
第三个就是社区和技术的影响力，后面我们也会介绍什么是社区，社区并不是一个虚无缥缈的，成功开源项目的社区和技术影响力覆盖非常广泛，像kubernetes、cncf的这套技术，基本上现在业界做云计算的不提这套技术感觉就过时了，你还在说云原生之前像虚拟化的一些东西感觉就out了，这个就是好的开源项目的一个特点，大家都会讨论、关注这个事情。然后它还需要一个完善的生态，比如kubernetes如果做一个孤立的项目，它的影响力就不足，但是CNCF还有大量的其他一些项目的支撑比如说etcd、prometheus等，它从一个单点项目构建起一个生态；类似Hadoop也是，它从最早的一个把计算存储引擎部在一起的应用慢慢分离出来后面有spark、flink、hive+MySQL支持数仓的场景等等，它完善出一个生态，这也是很多成功开源项目的特点。最后想说的是成功的商业化，但是并不是一个开源项目没有成功商业化就是不成功，只是说很多开源项目的特点它的商业化后面也做的比较好，比如说linux背后的Redhat这种，成功的被IBM以非常高的价格单独去收购，kubernetes也给Google或者AWS这种提供云服务的厂商带来了大量的回报。商业化可能不是成功必备的条件，但是一个好的项目我们认为它最后是可以被商业化。这个是跟大家聊一下成功开源项目的一些特点，当然也是一家之言，确实没有业界一个统一的标准。
开源项目成功的秘诀——增长飞轮
这里我们讲一下开源项目成功的秘诀，说成功秘诀有一些夸张，但是所有的开源项目成功会遵循一个增长飞轮。
这个增长飞轮解释起来也比较清楚，第一个我们现在假设有一个有潜力的项目，其实一个项目往往是从idea开始的，比如说我有一个idea，有好的工程师把它变成一个项目，生成一些代码，但是我们不想从idea开始讲，因为从idea变成一个项目考验的是个人的工程水平和工程能力，这里我们讲的是一个整体，从项目开始做一个引子。从这个项目来说，他一定是要提供一些功能，刚才我们也说了，你要有用户，你才有价值，那你为用户提供什么有价值的功能是第一步，是抓手，在一个项目里面你的代码肯定不是没有用的代码，要提供最佳的功能，然后通过这个功能扩展能够吸引到一批用户，首批的用户，这些用户是被你项目提供的功能所吸引，然后它加入进来成为项目第一个版本的用户，在这个用户的使用的过程中，可能发现各种各样的问题，有些用户可能用了一下发现这不是我需要的走开了，可能后面要在项目运营中再把这些用户拉回来。正常大家用的时候先试一试，然后上测试环境、上生产，在这个过程中，可能有社区中的人跟开发者有更多的交流，一部分的用户尤其是互联网公司的用户很喜欢上手，又是开源项目，大家会很好奇，于是又进入了下一个阶段，一部分用户可能成为了开发者，加入进来。随着一些开发者成为核心开发者，成为布道者之后，他就会给这个项目带来更多的资源和影响力，我们的开发者资源、用户资源、技术影响力会形成一个闭环，这样这种资源和影响力反过来会推动项目进入下一个循环，项目会提供更丰富的功能，然后吸引更多的用户更多的开发者，进入一个正向的循环，这个正向的循环我们就称为项目和社区的增长飞轮，所有的开源项目基本上都基于这个逻辑，下面我们通过Hadoop和kubernetes为例具体看一下。
增长飞轮 —— Hadoop
关于Hadoop这个项目，最开始源于Google的三篇论文，三驾马车。GFS是关于分布式文件存储，MapReduce上面的分布式的大数据处理引擎，然后还有BigTable，就是一个大的表结构，相当于一个kv的存储引擎，海量的数据怎样组织可以很快的被查询出来。最早的时候只有论文，是左上角这个人Doug Cutting，他之前一直在做search engine，做搜索引擎最早的是Architext，Google之前的一个搜索引擎公司，他在该公司担任首席架构师的角色，他们看到这个论文之后很受启发，因为他长期要解决的问题就是，那时（05、06年）大量公司面临的问题，大量互联网公司获取了大量的数据不知道怎么去处理，所以Google发的这三篇文章正好解决了大家很多问题。
传统的数据库已经解决不了这种海量数据的问题，甚至包括数据仓库也解决不了，像sand这种存储，以前都是share storage，又非常的贵，特别贵。大数据怎么去存，大数据怎么去处理，当时成为拥有海量数据的互联网公司所面临的课题，Doug Cutting就站出来说我要解决这个问题，做了最早版本的Hadoop，这部分工作被Yahoo的人看中，成立一个团队，让他做这个团队的首席架构师，慢慢Hadoop就开始了自己的孵化之旅。其实Hadoop最开始是从lucence这个项目，就是一个开源搜索引擎，包括现在像elasticsearch、solr都是基于lucence这个项目，他也是lucence这个项目的创始人。这样他就有个项目，然后它提供的功能非常明确，刚才也说了，互联网公司有大量数据亟待处理，他这个功能是当时非常非常符合业界的需求的，其实当时除了开源的Hadoop，当时各个大的厂商甚至包括百度，都有自己的类似MapReduce引擎，都是根据早期的paper自己写的。但这就是开源的力量，各家都有轮子，但是这个轮子会比较大也比较好，又是开源的，大家可以免费的进来，所以慢慢收编了其他的项目，在06年以后的8到10年时间一骑绝尘，大家都在往Hadoop上去迁移。它的用户也很多，Twitter、Facebook，包括Yahoo自己也是很大的用户，有大的用户量，几千个节点，几十上百个PB的数据，这些用户、用户使用场景慢慢让这个项目更清楚了，让这个项目可以在场景化、在生产环境可以去落地。在这个过程中，也出现了很多开发者，包括甚至像商业化的开发者Cloudera、mapR、hortonworks等等企业发行版的厂商，这些企业发行版的厂商通过商业的力量和社区的力量两股力量一起把这个项目推到了社区里，推到了商用里，让这个项目有更多的资源和影响力，甚至拉动了整个上下游的生态，像数据怎么进来啊出现了Kafka这样的引擎，包括MapReduce进化到spark阶段更快的内存计算，包括流式的数据处理出现了flink等等周边生态项目。最后又回到项目本身，又到了下一个增长迭代。
增长飞轮 —— Kubernetes
Kubernetes出现也是生逢其时，当时docker刚刚成为一个业界标准，docker容器化和虚拟化的竞争差不多在10年之后，在这之前十几年，虚拟化是业界的主流。从10年之后，差不多从linux container开始慢慢有容器化的趋势。Google的Borg系统在内部运营了多年，差不多有十几年大规模容器编排运维的积累，同时还有很多像调度系统，大概15年开源出来的时候就吸引了很多人的目光。但是那个时候，kubernetes在开源领域还有其他竞争对手，像mesos还有docker推出的swarm等。Google那时候儿投了几百个工程师吧，去做这个社区的开发，包括社区的支持，那个时候他们社区非常友好，成立了各种SIG（Special Interest Group），每个人都可以在这里面，比如说有一个大数据的SIG，你只要对大数据感兴趣，对大数据发展感兴趣，你就可以加入这个工作组，然后一起协同的去做，而且所有会议都是开放的，可以随时进行讨论，我说一个时间点，然后提供一个Google Meeting的地址，所有人都可以加进去讨论，非常的开放。这就吸引了很多的开发者和布道者，在业界产生了很大的影响力，像IBM、微软、Redhat、华为这些国内国外头部的公司都提供了云原生的服务，云原生这个领域，成为各大云厂商包括各大IT公司一个首选的方向。Kubernetes当前对业界产生了非常深远的影响，基本上每个公司都在往这个方向走。
如何吸引用户？
这个增长飞轮好说，但在增长飞轮的每一步都面临很多挑战。比如如何吸引用户。
你有一个好的项目，提供了有价值的功能，那如何让用户知道这个项目满足他们的需求。我觉得这里面有几个点。
第一个可能就是项目网站和文档建设，需要格外的关注，其实国内许多项目，大多数项目都不太注重文档的建设，项目网站大家都知道是一个脸面，我们为了这个脸面可能包装的很fancy，但具体到里面的文档的时候就惨不忍睹，也不是说惨不忍睹，就是并没有很好的规划设计，作为first try的用户，或者用户第一次来的时候，他通过你的文档能不能够很好的上手，能不能把我需要的功能达成，在这个过程中会不会碰到一些问题障碍，我觉得这是你文档建设的一个首先的目的，我们花了很多时间做运营，花了很多精力吸引来用户，结果用户试完之后发现部署不起来，安装不起来，那这些用户可能就走掉了，可能来了100个，试了一下不通，走掉了99个，最后只有一个留下来，效果就不好，所以文档建设非常重要，除了一开始要非常完善，后面每个版本迭代的时候也要和文档保持同步。很多像类似Hadoop这种，他有一个好处就是，随着版本的迭代文档也会有版本，这个文档的版本和项目代码的版本是保持同步的，这样再release的时候文档也会同步的发布，它是一个绑定的关系，这样就永远不会出现文档和代码版本不同步，不会对第一次来试用的用户不友好。
第二个比较重要的点就是社区支持，好的项目一定要有强大的社区支持，不管你是mail list还是社区微信群，各种运营方式，但总体你要让用户开始用的时候碰到问题能够在这个地方得到答案，能够解决问题，因为如果不能够在这里很快的解决问题，用户可能又会流失，可能就会转向其他的项目，所以这两点是一个基础，文档建设，社区支持。剩下还有很多，比如说社区的运营和推广，这也很重要，其实相当于我们的玩法，我们的项目怎么样让更多用户知道，要广而告之，通过技术峰会和Meetup可以辐射到开发者和用户群体里面去，拓展一些相应的渠道，让用户可以了解这个项目，包括像建设用户墙这样的东西，通过用户墙你能看到这个开源项目有哪些用户，然后这些用户是不是跟你来自同一个类型的公司或者同一个应用群组，这样就会知道，哦原来这些公司他们也在用，很多用户可能就觉得这个行业里面是一致的，应用场景是一致的，我们很可能对这个项目的使用方式也是一样的，这种用户墙对项目的运营也是很重要的，同时相当于设立了一个路标，帮助项目走向更多的用户，实现自己的价值。当然还有商业化的运营和推广，这里就不多说了，商业化的力量和社区的力量是两股力量，都可以帮助一个开源项目去落地，去产生价值。
如何吸引更多的开发者？
开源社区我们刚才提到了，并不是一个很虚的东西，其实他就分为一个类似金字塔的模型，社区的组成并不是只有开发者，只有contributor，它其实最多的是用户，是目标用户，是对这个项目而言，我的目标用户都是社区的组成。因为他们也会有贡献，潜在的目标用户通过使用项目把自己的场景带进去，把自己的领域知识场景知识带进去，给这个项目提issue提问题，都是社区contribution的方式，所以这个大的底座是项目的目标用户，然后实际上使用，包括测试使用、包括生产环境使用的用户是上面的一部分，然后上面这些用户用多了，在生产环境用了，他就会发现一些bug，比如说扩展到了新的场景，或者原有的场景有一些大的数据量或者规模上的扩展他会发现一些issue，这些用户就称为报bug的用户，其中，这部分人中有一部分人，他提了这个issue，代码又是公开的，那工程师好奇心很强，我就干脆自己动手修改代码去fix，这部分就成为了提PR的用户，最后很多人长期提PR就成了这个领域的专家，最后他成为了这个领域的commitor。这个就是我们认为，从目标用户开始，一直到上面的核心贡献者，都是整个社区的组成部分，所以让一个社区蓬勃发展，不光是上面的贡献者，不光是上面核心贡献者要大，底座也要大，包括目标用户，使用用户也要大，所以这也就是为什么不管是商业的项目还是基金会的项目，我们都要对最终用户负责。我们从最下面的目标用户到最上面的核心贡献者，每一层都希望有更多的转化，这就希望我们要构建一个开放的社区，鼓励贡献和合作，把这些报bug的用户怎么变成提patch的用户，有的时候可能就一句话，有的人在Jira上面放了一个问题，这个时候一个有经验的commitor就会鼓励他，要不要fix这个bug，虽然这个问题我们随手就可以解决，你一定要克制住自己解决问题的冲动，把这个问题留给用户，要不要上来试一下。甚至有时候我们在社区里面会开一些针对新手的Jira，这些问题开出来就是专门让first day的用户或者贡献者去fix，这样他就会很快的成为提patch的用户，或者一个早期的贡献者，一步一步牵引他成为核心贡献者，这个是吸引开发者很重要的一个点。
如何吸引更多的核心开发者？
有了一定的用户和开发者基础，如何吸引更多的核心开发者，这就要求我们对社区的规则要清楚。包括我们强调社区优先，技术导向，所有技术的argument不要出于立场，也不要质疑别人的立场，不管这个立场是属于商业还是什么，我们要出于本身技术的一个角度去看这个问题，包括在公开的场合讨论所有的问题。因为所有的在公共场合讨论的技术问题沉淀下来都是社区的资产，包括我们要用到共识的力量，有的时候我们说开源里面找到一个共识非常重要，不是说谁的嗓门大，谁就有power，最后是相互妥协，找到一个互相能认同，相互的一个理解体谅，找到一个可以相互妥协的方式，这个可能是很多开源领域最后达成共识的方式，所以在开源领域我们鼓励这种积极的妥协，不是说我们什么事情都妥协，该有底线的时候有底线，坚持我们技术的思考，但是有时候技术A也可以B也可以C也可以，那我们不一定要坚持A，我们可以尝试一下中间道路，所有人都可以接受的那种方式，这个大家一定是要Open的，包括有时候我们不太鼓励大段代码写出来一下扔到社区，因为代码写出来的时候，技术路线定下来了，在没有跟别人讨论的情况下，弹性是很小的，就是你一定会坚持你的代码和技术路线，很难被说服去调整，但是如果你在这个过程中先抛一个设计文档上来，这个时候别人说可能还有更好的方式，那就相对来说比较有弹性，所以从这个角度来说，我们鼓励先有设计，然后达成共识后再往下去写代码，再往下去做大的需求。在这里参考了Apache的commitor的标准，有了这么一个标准可以鼓励更多的开发者加入进来做核心开发者，相当于是目标牵引。第一个你要有坚实的代码的贡献和质量，就是说你在这里使用还不够，或者说做推广还不够，你要真正懂代码本身，对代码有逐步的贡献，包括代码的质量都是要符合标准的，然后更重要的是code review的能力，因为commitor一个核心的点就是要去review code，如果代码评审能力不行或者方式特别简单粗暴，别人的patch代码可能有改进的机会但是直接否决了，不给机会，那可能也不是一个理想的标准。包括在user group里面，刚才我说到的，社区的维护，要积极的去维护它。包括这种讨论是否互相respect的精神，因为合作很重要，如果你在这个commiter的团队，或者governance的团队，出现很难合作的人，最后整个开源项目的风气就会变换，那风气变换了，一些好的优秀的人可能就会走开，大家还是希望在社区里面感受到温暖积极正能量的事情，很多人在工作上积累了许多负能量，到了社区真的是为了正能量而来的，所以在社区尤其要注重维护正能量，大家都是凭着热情和兴趣在做这个事情，这个时候没有正能量那回报是有问题的。
说这么多规则，吸引核心开发者，其实核心的一点是要把这个Bar设置出来，整体的氛围是正能量吸引人的氛围，这样才能有更多志同道合的人加入进来。
解决好开源中的矛盾
另外一个要解决好开源中的一些矛盾，开源是个好东西，但是其中的矛盾也不少。里面有比如说商业和公益，开源中有些feature可能是商业化的需求，但是有些feature可能又是普惠大众的，这个时候应该怎么去选择去抉择，这个时候要处理好，全商业化的牵引可能也不太有利于这个项目的成长，最后也会影响到商业化。第二个要解决好组织和个人，我们在这个社区里面是以个人身份加入还是以组织群体的身份加入，这个也很重要，带着组织群体的身份进来，那很多讨论可能就不是那么技术，就会有一些组织诉求，但如果只是一味的个人呢，完全不考虑组织，那组织对这个项目的投入也会减少，所以要解决好这个组织和个人，尤其是个人开发者还有一个大的问题，就是真正能够持之以恒真正凭自己的兴趣，投入到开源项目的还是少数，linux本人包括刚才提到的Doug cutting毕竟是少数，可能还是说我个人对这个感兴趣，但是背后还需要组织支撑。刚才也说到了设计开发测试，这三个，都要平衡。有一个好的设计还是有一个快速的开发迭代还是一个快速的测试包括测试的覆盖面，因为对于很多项目尤其是早期项目，它在这三个方面的资源是有限的，三个方面的资源怎么去平衡也是很重要的。我们是求快还是求好，我们求feature是求多还是求少，这个时候对这个项目的owner也好组织者也好，这些都是需要考虑的因素，要把这些矛盾都解决好。 这些就是我今天要分享的内容。
后记：堵俊平，开放原子基金会TOC主席，Apache基金会Member，Apache Hadoop, Submarine等项目PMC, Apache YuniKorn, TubeMQ等项目导师，在云计算和大数据领域有超过10年的研发和管理经验，在开源领域也有近10年的贡献和积累。以上内容均由笔者（Booogu-郝志北）整理自堵老师的现场讲座录音，原创权、著作权归堵老师所有，如转载请注明出处和相关链接！
