开源入门：理解开源及其重要性

开源是什么？开源怎么赚钱？

开源事业，要解决的第一个问题是开源战略，也就是为什么要做开源。如果没有开源战略，开源就只是某个个人或者团队的行为，这样的开源不可能持续（除了那种创始团队跑出来继续的情况）。对公司而言，如果这个项目基本没人知道的话，没啥意义，如果曾经还搞出点影响力，影响反而是负面的，可能导致公司后续的开源都被业界怀疑。

为什么要做开源，我觉得大部分公司的开源目的可以归结为三点：1、开源才能改变世界（行业格局）；2、开源有助于增进创新和分享的公司文化（公司品牌）；3、开源自然也会名利双收（换个套路变现）。

1、开源才能改变世界

我说的“改变世界”没有那么高大上，对于企业级基础软件来说，就是要做到全世界很多国家很多行业都在用。

开源才能改变世界，是经历了背景故事中多个项目黯然神伤的深切体会，Linux、K8S、MySQL、Hadoop、Spark、MongoDB、Redis等大量的案例更可以证明开源是“独立”基础软件实现成功的主要方式。如果不是开源，很多新技术产品不可能有这样的成绩。

这里的限定条件是“独立”二字。“非独立”的基础软件不需要借助开源也能成功，开源可能意义不大。如iOS就不开源，AWS等云产商做了大量的基础软件，也都不开源。云产商做开源的逻辑就比较难讲。

2、开源有助于增进创新和分享的公司文化

创新是公司核心文化之一（另两条是热爱、和用户在一起）。在没有什么平台模式网络效应可以凭借时，所有业务都得拼产品、拼技术、拼运营，最终都要拼创新。

开源可谓推进创新和共享文化的最佳手段。开源可以让技术接受全世界的评议，看是不是真的有用的创新，还是闭门造车自吹自擂，或是为了创新而创新搞出来的怪胎。一个技术如果只是自己做自己用，怎么知道是否先进呢，所以我们鼓励要么开源，要么商业化，接受客户的检验。基础软件这样的公共技术一般没什么业务特殊性，要么做一个最好的，要么就不要做，用已有最好的。开源可以促进共享这点更不必多说，开源不但是分享给世界，也是分享给公司别的部门。大公司总有一些部门墙，开源是最容易突破部门墙的。

3、开源自然也会名利双收

名一方面是公司的技术品牌。因为开源项目的成功肯定是业界公认，对企业技术品牌的价值就非常大。比如百度在AI领域的技术品牌跟PaddlePaddle有很大的关系，一个PP抵得上不知道多少个大赛冠军。名的另一面是企业的社会价值，开源是软件企业反哺社会的一种重要方式。最后，技术品牌和社会形象也就是人才吸引力。

最后说到利。如果开发团队做的这个软件真的全世界都在用，他们作为开创者和主要的贡献者，我们基于这个项目去给客户提供增值服务，会发愁赚不到钱吗，多少总能养活自己吧。记得当初取名“有道”的时候，有一个说法是有道可以解释为“君子爱财、取之有道”。开源，帮助到千千万万的客户，然后顺便赚点钱，也可以说是“君子之道”。

「开源策略」

开源策略方面第一个核心问题是：哪些开源，哪些不开源。这个问题又包含两个子问题，哪些项目适合开源和哪些部分适合开源。

有两类项目最适合开源：

1. 核心基础软件：这类软件功能定义明确、标准化程度高，复杂度和质量要求高，支撑关键业务和核心系统。成功的开源项目基本上都是这一类型。这有两个原因，一是新技术的Early Adopter主要是互联网企业，互联网企业有很强的开源偏好，这类核心技术软件不开源他们基本不敢用；二是功能定义明确、标准化程度高的软件最适合众多开源爱好者参与贡献。开源爱好者是来贡献通用功能的，不是来帮你交付定制化项目的。

2. 围绕已有开源项目的配套软件，如我们开源的KubeCube、KubeDiag都是K8S配套软件。这类开源项目是为了促进某个生态（如容器生态）的普及和成熟。当然我们推动容器生态和商业是相关的，容器生态就如黑土地，网易轻舟就如禾苗。容器生态越成熟，轻舟的市场就越大。

还有一些其他因素需要考虑：

1. 只有开源才能打败开源。如Spark虽然相比Hadoop MapReduce 有很大的改进，但毕竟是同类产品，如果Spark不开源是不可能成功的。我们把Curve开源也是同样的道理，因为已经有了一个非常流行的存储系统Ceph。虽然Curve相比Ceph也有诸多改进，但也还是同类，不开源不可能成功，还不如不做。

2. 开源打商业机会很大。比如MySQL虽然出现很晚，还能在Oracle、DB2等一众商业化数据库巨头间突围而出。Linux也一样，出现晚，在专家眼里技术落后的不行，也获得了巨大的成功。开源打商业如同降维打击，即便又晚又差都有机会。这方面我们正在研发一款开源的云原生数据库（类似Aurora），明年会开源出来。我觉得业界需要有一个开源的云原生数据库。

3. 商业化套件的子产品不开源。比如我们围绕网易数帆下的轻舟和有数套件做的很多子产品都不会开源，这些产品天然就能很好的集成到商业化套件中销售，这时候开源确实可能导致损失很多利益，对业界也没什么价值，因为这些子产品通常不能脱离套件发挥功用。其实这个规则只是再次强调之前说的“独立”基础软件才适合开源。

哪些部分适合开源的问题，我们的考虑是“内核开源”，这也是业界典型策略。内核开源，对客户和生态来说就可以体验到完整的基础功能，满足应用需求。但大型企业如果作为技术战略应用的话，还需要很多安全、治理、监控、计量计费等等“企业级”功能，这些功能可以作为商业版本的特有功能，也没那么标准化，开源爱好者也搞不懂。我今年打过一个比方说采用一个基础软件就像结婚，要慎重，一旦遇人不淑，离婚可不容易。内核开源类似于让你可以深入了解一个人的品行，保证不会遇人不淑，但是你还得花钱买“企业级”的功能和服务，就类似你找到了真爱，但经济上还得自立。

开源策略第二个核心问题是：要放弃控制权，捐赠给基金会。这是因为捐赠给基金会有助于软件的成功。基金会运作更能被客户接受，因为这样才可能有多家供应商能提供服务，才能形成健康的软件供应链。我一直认为，如果一个软件只有一家能做并不是好事，这家公司不可能成功，因为对客户来说这样会面临极大的风险。放弃控制权，培养几家竞争对手，大家才能一起成功，否则谁都成功不了。另一方面，捐赠给基金会，也便于借助基金会扩大影响力。

捐赠给基金会面临的一个问题是：如果IaaS巨头来薅羊毛怎么办？为了防止IaaS巨头来薅羊毛，Redis和MongoDB都改了开源协议，如果捐赠给基金会，就没办法这么干了。这样的风险当然存在，但如果自身能力过硬，应对及时，风险并不大。在一次采访中，Spark的CEO Ali Ghodsi是这么说的，之所以出现一些基础软件产商被IaaS巨头来薅羊毛，是因为这些产商不擅长做云服务。软件已经很流行了，原厂又没能力提供云服务，IaaS巨头提供一个云服务也是为了更好的满足客户需求。所以要避免IaaS巨头来薅羊毛，根本上是要靠自身产品化能力过硬（一般开源的只是内核，不包含所有产品）、商业化和云服务运营能力强，并且在合适的时机就在各大云平台提供对应的云服务，这样我相信原厂的云服务自然是最畅销的。像Spark就和云产商合作的很好，TiDB看起来也不错。当然IaaS巨头的服务也会有市场。

所以要不要捐赠给基金会，取决于你的思维方式是做蛋糕还是分蛋糕。

「开源落地」

战略上认可开源，策略上也想清楚了，接下来是具体怎么做的问题。

头等大事是经费来源。虽然我们说了很多开源的各种价值，但这些价值主要是对企业整体而言偏长期的价值，所以开源的经费来源要尽可能的来自于企业的最高层，越高越好。以我们为例，我们的开源项目主要是放在研究院的公技板块，由集团设立和给预算经费，因此开源并不占用网易数帆BU的成本。因为在公技板块，我们的开源项目都是因为集团自身业务有需要而立项，并非为了赚钱，只是觉得做得好了说不定也能给数帆赚点钱。这样，公技就踏踏实实做开源，数帆就跟着开源的进度，到合适的时候再试试怎么围绕开源去赚点钱，能赚到当然好，赚不到也不亏。所以，虽然是在数字+大会上发布，但实际上并不是数帆在做开源，而是研究院在做，更进一步说是集团在做开源。我在数字+讲开源的时候，其实更多的是代表研究院而非数帆。

大家可能对我们研究院不太了解，那还可以拿阿里类比一下，就类似行颠（达摩院和阿里云的共同负责人）来发布阿里的开源战略，让达摩院踏踏实实做开源，如果做的好的，阿里云来围绕开源赚钱。虽然阿里云做的很大了，但毕竟是个要赚钱的部门，做开源难免纠结。

我们的机制可以归结为集团开源，BU赚钱。我觉得我们这样的机制才能保障开源的“诚意”和“长远”，唯一的前提是大老板要支持，幸运的是老板很支持我们做开源。

第二个是要做好开源项目的管理，不要让不好的开源项目损害公司品牌。开源项目多了，就要建立开源管理委员会，新开源项目都要经过委员会审议，每年每个项目都要向委员会汇报工作和计划。每个项目的价值也要严格评估，只是不评估赚钱而已，但社区情况、应用情况、影响力情况、技术创新与先进性、团队能力等等都要评估，据此确定预算。我们目前还没有正式建立委员会，但杭研和数帆的每个项目要开源也都是我要审批的。后续考虑到项目多了，很可能会建立一个更规范运作的委员会组织。

「不仅自研开源」

以上都侧重于自研开源，实际上我们对开源不仅重视自研开源，更重视开源引入和社区贡献。我们已经连续三年在HR和技术委员会（TM599）组织下开展了三类开源的评选，每年在10.24期间颁奖，以此促进公司的开源文化。

第一提倡的是开源引入，也就是奖励优先采用已有的开源技术并分享开源经验。每年这类奖励的数量是最多的，这是为了尽可能的促进复用，反对重复造轮子。我经常讲，软件最大的优势是只有研发没有生产，只有软件才可能做到不重复造轮子，理论上我们写的每一行代码都应该是创新的，独特的。工业时代每个人都在重复造轮子，米其林是不会说我们要让每个轮子都不一样。可以不用重复造轮子，是我们做软件的拥有的最大优势，尽可能不要把自己的聪明才智浪费在重复造轮子上。

第二提倡的社区贡献。为什么要给社区做贡献争取成为Committer，而不是自用就好？这有几方面的考虑。首先，通过最专业的同行评议可以确保我们的方案是好的；其次，解决方案被社区接受能够极大的降低自己分支的维护成本。如果不积极为社区做贡献，一段时间之后很容易出现和社区分岔太多，merge不了社区最新进步，就如当年我做国产数据库时一样，伤害极大。正因为如此，我们才在OpenStack（曾位列nova项目年度中国第一）、Spark（拥有Committer，国内似乎才5名）、Harbor等项目上都积极贡献。当然，最后还有就是对公司技术品牌的价值。

最后才是自研开源。自研开源其实是已有开源技术确实无法满足时的无奈之举，因此我们往往都是在应用过开源技术，发现确实有无法解决的问题时，才被迫自研然后开源。比如我们是在大规模应用了Ceph（百PB级），发现Ceph因为基础设计的不足导致可用性、可维护性和性能问题无法解决时，才自研Curve存储。

这样的策略，对内能够最大程度的降低重复造轮子，对外可以最大程度的保证自研开源项目个个是精品。

「结语」

本文既是对我们开源的全面介绍，给业界和同事的回答，也或许可为业界做一参考。开源是为了做出成功的基础软件，为了推进创新和复用的文化，也有名和利。开源的无私和商业的自私之间要取舍和均衡，谈开源不必避讳商业利益，从开源中赚钱，可以说是“君子爱财，取之有道”。我们通过集团无私投入做开源，事业部顺便看看是否能赚钱的机制，力求让我们的开源“诚意满满“和”可持续“。