Apache Way 已然成为开源都需要遵循的标准，可是在商业公司的开源方式和常见的开源商业化还是有一定的差别，这篇文章就是来介绍在我在国内某大厂内的商业开源见闻。
OpenSource
为了讲清楚这个话题，首先就要先介绍一下什么是开源，常见的开源是怎么玩的？
什么是开源
开源其实很简单，就是开放源代码；开源也不简单，不只是开放源代码，可是目前依然有很多人认为开源就只是把代码Open了，其他人能够用起来，然后轮流安排人来值班回复Issue和微信群里面的问题，至于新功能开发和长期规划基本上都是内部封闭式讨论，其他人是没办法参与到其中来。从这一点来看，其实也并没有开源。
开源，代表着公开透明
既然代码都开源了，为什么项目周会和季度周会不也开源出去呢？将这些信息开源出去又什么好处吗？
这个时候周会不开源分为以下情况：
- 没意识到周会也是要开源出去
- 觉得周会开源很麻烦，浪费人力成本，还不如不做
- 周会上有不可公开的商业信息，没办法开源
将周会信息公布出去之后有什么好处吗？为了讲清楚这些问题，我需要给大家详细介绍一下Apache Way和一些国内的案例。
Apache Way
接触过开源的人基本上都或多或少了解过Apache Way，这是一个历经全球二十多年开源软件成功发展的标准，也就是说如果想要成功开源，那就遵循Apache Way，最后大概率会开源成功。这句话听起来神乎其神，其本质还是一套心法和备受认可的功法。
那究竟什么是Apache Way呢？
准则
Apache Way有多个准则，我主要罗列其中四点：
- 社区大于代码（Community Over Code）
- 邮件列表讨论（Open Email List）
- 精英民主（管理机制）
- 异步工作（Working with Global Developers）
社区大于代码
顾名思义，社区比代码代码还要重要。不过也是有一定的前提：项目已然有一些稳定版本发布，主要的功能模块是测可用的情况下。不然项目甚至都还没有做，然后就来维护社区，然后就拉一群人来从零开始做一个项目，这不是忽悠人吗？也很少有人愿意来做这件事情，不过我也相信也不乏这类的情况，可能创始人背景太过于强大，会有很多慕名而来的人因为这个人和想法一起来从零开始做。
扯远了，回过头来，当项目已经初具规模，这个时候维护好开源社区是非常重要，原因如下：
- 创新来源于社区
- 贡献来源于社区
- 可持续性来源于社区
创新来源于社区
社区的开发者往往来自于五湖四海，各行各业，并都有使用项目的意愿和独特应用场景。这对于开源社区来说是具备巨大潜力的资源。
首先，那些开发者既然是加入到本社区里面来，肯定是觉得可以应用在他们业务场景当中，遇到问题也希望能够得到尽快找到解决方案，这样他们也可以在往项目成功运行一步步迈进。
当然，在这里先抛一个重点：如何让他们尽快找到解决方案是很关键的一点。
其次，每个开发者的业务场景都有其独特之处，大部分都可以基于现有的功能模块组合而成，少数部分业务需要提供一定的扩展才能够更好的解决他们的业务。此时，这些扩展或许就能够成为项目发展的关键点和创新点。
当然，不是说开发者所提出的所有建议社区都是需要采取，而是需要走类似于企业审批的过程：PMC 投票决定此功能是否有必要加入到项目中来，而且整个社区的人都可以参与到投票中来，这样是不是更加民主呢？
所以，社区的人才是创新的关键，创新也是来源于社区。
贡献来源于社区
上面提到了会有少部分人觉得：如果能够添加XX功能就更好了，同时还会有一些人愿意主动给出自己的提案和解决方案的思考，如果稍作一些引导，此类开发者便可以成为社区的Contributor，我也相信会有很多人热爱写代码，热爱贡献，如果社区一旦发现此类的人，应该重点跟进和维系，并采用开源社所推荐的推坑文化，其本质上是一个用认可鼓励成长的方法。
所以，维系好那些积极的，具备一定热爱的人，来自社区的贡献自然而然就来了。如果此类人的数量多起来了，这相比于公司直接雇一群人来做这件事情而言，会更有长期的价值。
此外，社区会不断有新鲜血液进来，推坑文化也可以保证社区的活跃程度，以及源源不断的贡献。
可持续性来源于社区
这一点其实已经从侧面聊过了，只有维系好社区以及社区的管理制度，社区就会形成一个良性循环，社区人数的增加也会推动创新和贡献不断增长，所以为了实现这一点，最重要的一个前提是：社区的管理制度以及如何维系好开源社区。
说了这么多，我想大家都已经认识到社区的重要性不比代码低，甚至更甚。可是如何真正管理好社区以及让社区更健康？这也是一个重要的话题。
邮件列表讨论
不知道大家对于邮件是否都停留在注册账号激活、绑定某些账户以及各种垃圾邮件等层面中。不过已经进入职场的人甚至是进入管理层的人，会对邮件比较习惯：小组或部门通知基本上都是基于邮件，不过其中的技术讨论极少之又少。
什么是邮件列表讨论
邮件列表的发送对象往往是有一个组的概念，在这个组里面的人都可以接收到相关邮件。如果你发了一封提问邮件，这个时候所有的人都会接收到这个邮件，然后回复者的邮件也会被这个组的所有人都看到。
为什么邮件列表这么重要
那这种方式有什么好处呢？为什么要推荐这种方式呢？
首先，这对于提问者和回复者都有一定的要求：
- 提问和回复已经描述的足够清楚，能够让所有人都能够直接抓住重点
- 我的提问是否有价值，是否在经过一定的努力之后还是没有找到解决方案（这个时候一定程度上还是由于项目文档没有做好导致的）
- 我的回复是否能够解决他的问题，如果不能，是否能够快速通过最少的询问抓住核心问题
由于邮件列表是在公开的地方进行讨论，发送者会对编写的邮件内容非常谨慎，必须是经过思考之后的结果。而这种必须经过深入思考之后提问和回复才能够倒逼他们遵循：提问的艺术和回复的艺术。
Apache 相关的项目都推荐使用此类方法来进行重要事情的沟通，也是一种相对高效的方式。
此外，此类方法无论是针对于提问者还是回复者都可以提升自我的曝光度，增加在团队内部的信誉度和知名度。
可是，此类方法在国内却行不通，这也是有一定的文化因素和互联网背景的。
中国开发者之间的沟通方式
我见过太多的开发者，想要咨询问题基本上都是拉小群来进行讨论，然后让社区维护者就有了无数个小群，这对于他们而言是一件很恐怖的事情。
为什么说是一件很恐怖的事情呢？原因有三：
- 群聊太多，导致需要挨个挨个儿去维护群关系和事情，特别是每个群聊的内容都不一样。
- 群聊太多，很多都是问的同一个问题，然后每个群都要私聊回复一遍，这件无聊的工作量将要重复无数次。
- 群聊太多，导致信息不共享，这将没有办法导致信息的有效传递，将会逐渐让社区进入一个恶性的环境当中，没有办法形成自我更新和成长，这也是以上两个问题的关键。
所以说，在公开的地方沟通，所有的信息都是共享，这将会给社区形成一个健康的良性循环，帮助开发者快速解决问题，从而形成更快的反馈链，甚至从侧面增加产品的迭代。
以上现象的形成，是有一定的原因：国内大部分用户基于微信沟通过，而微信是一个极其封闭的环境。
微信是一个群人数上限只有500人，群管理人员最多只有三人的IM平台，新加入的群成员没法看到历史聊天记录，也只能在人数上限只有500人的群里面来沟通。国内很多开源社区运营人员动辄都有好几十个微信群需要去维系管理，而且不同微信群都在问同一个问题，运营人员需要挨个儿去回复一遍，这是一件枯燥且没有意义的事情。可是并没有办法解决此问题，因为是在微信生态上来做。
不过，我给大家推荐开源社的一个项目：OSSChat 。
所有的事情都公开
源代码其实是最基础的，更多的还是：
- 问题讨论
- 项目会议视频 & 项目会议记录
- 新功能融入投票
只有足够开放，其他开发者才能够有途径了解到项目的实际情况，从而产生兴趣进行贡献。
开源社区如果想要更多的开发者进行贡献，一个大前提就是得给开发者提供足够的文档和渠道，从而让其逐步进入贡献的流程中来，同时还需要保证开发者在上手的过程中，不同的问题都是能够有迹可循，无论是在官网论坛还是github issue当中，只要是能够找到对应解决方案。
如果参与贡献的开发者数量多了之后，会存在一个管理的问题，而Apache Way推进使用精英治理的方式来管理。
精英治理
什么是精英治理
谁的贡献越大，谁的指责越大。
如果一个开发者给社区做了很多贡献，则他理应成为社区的更为高级的管理者，按照不同的title划分，有如下几个类型：
- Contributor(代码贡献者)
- Committer(项目委员会)
- Maintainer(项目拥有者)
- PMC Member(项目管理办公室成员)
- PMC Chair(项目管理办公室主席)
每一个级别都会随着贡献的增多而提升，这个跟公司的职级晋升也是有一定的类似。
这是一种公平且有益于社区健康发展的良性机制，一旦开发者获得了某种title，将永不会除名，这也保证了开发者的贡献是永久有效，不会随着贡献频率的降低而消失。
职责大于权力
这种机制和公司的职级又有很大的区别：职级越高，职责越大，对应的权力却没有很大的增长。因为在开源世界里，民主是更加被推崇的文化，任何抉择只要是被大家所认可的，都可执行下去，同时也不会被某几个人所决定，而是需要大家共同的投票决定才行。
异步工作
现如今异步工作方式已经被大多数人所认可，并被证明是一种高效的工作方式，这并不是针对于个人，而是整个团队而言。特别是当团队是来自于全球各地，其中也是存在一定的时差。
Apache提出72小时工作制度：任何一个需要讨论和确定的事情，至少要存在72小时，其中也考虑到周六周末，这样即使团队的人是来自全球，也能够都看得到某个具体事宜，从而参与到其中。
社区的健康性
如何评价社区的健康性呢？
一个健康的社区，通常具备一下特点：
- 多样性
- 公平
- 平等
多样性
社区的多样性其实来源于多个方面：开发者的多样性以及应用领域的多样性。
开发者的多样性主要表现在开发者来自于不同国家、不同公司或不同工作领域，不多都有相同的诉求：想用社区的项目解决他们的领域中的问题，所以开发者的多样性也是能够间接说明应用领域的多样性。
开发者和应用领域的多样性能够给社区带来未知的创新，而这些创新正是社区发展的动力。
平等
有了多样性，如何让各种多样性能够合理平等共存呢？
无论你是新手开发者还是资深贡献者，在社区都是有权力表达自己的观点，从而保证社区内不断吸纳各种声音，有好的，有坏的，这些都是能够从某些层面改变社区的动力来源。只不过最终如何变化，这是需要获得社区内大部分人的赞同才行。
所以公平也是民主，能够让社区在更加友好的环境下发展。
公开
社区是支持各种不同的声音和观点，也鼓励大家表达自己的观点，而且这些观点必须让所有人都能够及时且清晰的了解到，只有这样，这些观点才是有价值的。
如果某个开发者针对于一个项目有自己的见解，想和大家讨论，推荐的方式是：在公开的场合表达自己的观点。而公开的场合可以是邮件列表，也可以是一次分享会的提问，也可以是在github中的一个issue，形式可以是多种多样，只不过必须得保证是所有人都能够通过网络获取到整个观点的全部内容。
公开的重要性我上面已经介绍过，再次不再赘述了。
两位大佬的观点
商业开源
现如今开源已经和商业产生了紧密的联系，也有很多依托于开源的成功商业案例，在此我将商业开源分为一下两类：
- 创业公司做开源
- 上市公司做开源
创业公司做开源
近些年来，开源的趋势在国内是越来越火，关注到这个领域的人也是越来越多，那些看到开源背后潜力的人大佬们，部分会选择全身心投入到开源项目中去，等成功之后就会将其转化成商业孵化公司，为其提供技术解决方案、技术咨询、云服务等。
其中不乏做的非常优秀的公司，如TiDB背后的商业公司PingCAP，以及Apache APISIX背后的商业公司APISEVEN等，此公司都是拿到多轮融资，做的非常成功的公司。
当然也还是有很多正在开源和商业转化中挣扎寻找适合自己出路的创业公司，虽然还在路上，可是他们都坚信开源是他们商业成功的关键。
优势
优势其实很明显：
- 能够更具社区的需求快速迭代
- 有领域内的顶尖技术专家带领着项目逐步往前走
- 可以指定更为灵活的社区管理方式
- 创新性比较高
创业公司往往可以做出小而美的项目，然后经过时间的迭代，不断成长为业界的顶尖项目。
弊端
不过也有一些弊端：
- 资源少
- 开源社区运营的重要性非常高
创业公司没有上市公司的宣传和技术资源，可能前期的蓄力阶段比较长；另外开源项目的成功与否与开源社区运营的状态息息相关，因为这个在蓄力阶段就决定了产品的受众目标和快速迭代的能力。
总而言之，创业公司做开源基本上是从某一个小方向做起，然后努力做到行业内顶尖水平。
上市公司做开源
国家十四五规划中重点提到了开源对于国家未来软件发展的重要性，于是各大公司也在这方向上有很多尝试，比如百度就做了paddle系列的开源项目，华为做了OpenEuler、OpenGauss（Open*）系列的开源项目，阿里也做了自己的AliOS、腾讯也有自己的TecentOS系统。
优势
从上面的项目中可以看出，大公司往往更适合做底层基础软件，因为它们具备这样的技术底蕴和技术资源，从各个方面都能够支撑基础软件开发的要求，我想这一点在座的各位都应该很清楚。那咱们重点来说说，大厂做开源的弊端。
弊端
根据本人经历与相关朋友的讨论，总结为以下几点：
- 创新性不足
- 产品化思维
- 核心开发者与开源社区的互动少
创新性不足
为什么说创新性不足呢？
这一点其实跟不同的组有关，通常情况下一些新功能的开发需要层层审批，只有当大家都同意之后才行，而往往创新性的东西是具备一定风险的，那领导是否愿意去承担这些风险？
其次企业的tech leader通常是在公司工作多年，熟悉公司技术业务的大佬，可是对于开源是否有一个充分性的认知，这还是有待确定，因为只有深入到开源社区中才能够了解到开源是怎么玩，怎么让它有一个充分性的发展，可是他们往往特别忙，忙着参加公司内部的会议和活动，没有时间去下凡去接触实实在在的开源社区。 所以在一些决策性上面而言，可能与真实情况存在一定的差别。
产品化思维
大公司做项目分工是非常明确的，有产品、运营、管理、技术等不同的人员分配，那每个人是怎么协同工作呢？答案就是产品计划。
这也是大公司做事的一贯风格和优势，以产品化的思维来完成在绝大情况下都能够保质保量的交付，这也是一种靠谱的方式。这一点也是企业实践出来的经验。可是我个人认为做开源项目并不是在做产品。
为什么这样说呢？区别主要存在以下几点：
- 开源项目的项目计划来自于开源社区，并非产品经理
- 开源项目的核心开发者与社区在技术上有深度交互，并非是PM来代替这个角色
- 开源项目首先满足的是开发者，好用是大前提，其次再是企业。
核心开发者与开源社区的互动少
开源社区最重要的一点在于技术的公开性和交互性。
公开性表示所有技术细节应该开放出去，无论是技术讨论还是Feature排期讨论，把这些有价值的东西开放出去给其他开发者，这样他们看到这些更细节的东西之后其中不乏一些愿意参与到讨论甚至贡献中来的优秀开发者，开源社区也是更愿意欢迎这些具备一定主动性、有能力解决一些实际问题的开发者，这类的开发者是社区未来潜在的活跃贡献者，甚至会成为PMC Member，所以如何能够吸引这些开发者参与到社区中来，这一点很重要。 可以类比于，开源贡献，愿者上钩，只不过社区一定要把这个钩子给甩出去；其次是一个弯钩，直钩就太难了；最后如果有饵那就更完美了，我相信会有很多开发者愿意因为一些奖金或者title的荣誉来参与到贡献中来。
互动性表示核心开发者还是需要与社区进行一些互动，并非都是PM来完成这些事情。假象一个场景：如果想要开发者来给项目做贡献，PM就在对应的群或者私聊开发者邀请起参与贡献中来，这个时候开发者内心可能会想：“你一个PM，啥技术都不懂，来叫我做贡献，有奖金吗？”。再来另外一个场景，某开源社区公认的技术大佬在群内或私聊跟某开发者说：“嗯，你的想法很不错，有没有兴趣来提一个PR呢？”，这个时候开发者内心又是如何想呢？大概率会很激动：“卧槽，大佬邀请我来参与贡献，我能完成吗？我该怎么做更好呢？”。
这两个场景可能有失偏颇，可是也是说明了一些问题：和开发者之间的互动，还是需要技术与技术人员之间来沟通会更好。而且每个行业都存在一定的明星效应，如果开源社区本身就力推一个明星开发者，那他就肯定能够代表社区做一些更深入的宣传和运营管理上的工作。
结语
开源是一条必然会成功的道路，无论是对公司还是个人，可是要把这条路给走好，需要做很多事情，也需要用正确的方法来做。以上的所有观点仅代表我个人在此时此刻的认知，如果有不同意见的小伙伴，也欢迎在评论区参与讨论。
最后祝愿各位开源人在自己的开源项目当中都能够有所获得。