本期访谈阵容
嘉宾：陈梓立tison，夜天之书作者、Apache Member & 孵化器导师、Apache Flink Committer。
主持：庄表伟，开源社理事、华为开源管理中心开源专家。常年参与社区各类活动，热心开源治理、开源成长、开源学术等方面的研究与分享。
Q：我们在社区里会看到很多形形色色的开发者，有纯粹出于爱好的个人开发者，有想在社区学习成长的学生，还有带着任务被企业派到社区里的。请 tison 聊聊，遇到过的比较有意思的开发者及他们的表现形式有哪些？
tison：学生的环境比较单纯，可能会更纯粹。他们的动机通常是在学校里学到了很多知识，但却很难接触到工业界比较成熟或者说能用上生产环境的软件，通过参与开源社区，把书上的知识与现实中的软件互相印证。当然，也有一些是为以后的实习或工作打基础。
开源社区关注软件价值。社区决策时，考虑的是软件整体用户的利益，以及核心开发者的诉求。社区成员一般有三种类型：一种是用户，或者叫 End User；一种是期望做生态整合集成的开发者；还有一种想成为内核开发者。如果你带着企业开发的习惯参与开源社区，很快你就会发现企业常见的审批流程主导的控制模式以及 Deadline 驱动的工作方式，在开源社区里是不管用的。开源协同强调的是志愿参与。
Q：我们说待人接物要不卑不亢，你刚才举的例子都过于“亢”了，但有一些人（学生偏多）在社区总是小心翼翼的，他们又过于卑微了。如何看待这种情况？
tison：这类人很多时候已经超出谦卑的范畴，而是完全不想说话，或者不好意思说了。他们会很小心地猜你想干什么，比如说提出一个补丁以后，压力山大地担心别人会给到什么反应。如果是前面提到的傲慢的人，他们会觉得维护者合并他们的补丁是天经地义的，不管写的怎么样，你最好别废话。
过于卑微的问题，其实不仅发生在 Contributor 身上，在 Maintainer 身上也会发生。尤其当 Maintainer 过于关注流失率、Contributor 数量等指标要求的时候。这也是部分 Contributor 对 Maintainer 趾高气扬的依仗。
对于新加入的 Contributor，如果 Maintainer 认为他需要帮助，可以在时间充足的时候引导他们，告诉他们应该怎么做，或者在察觉到他们有一些紧张情绪的时候，告诉他没关系。前不久我给一个 Gradle Plugin 叫 spotless 提补丁的时候，第一次合并的补丁里有问题。虽然我马上就提了一个修复，但是心里还是挺不好意思的。这个时候 spotless 的维护者就宽慰我说大家都会犯错，我做的工作是很多用户期待了一年的功能，是很值得骄傲的。听到他这么说，我也就释然了。Maintainer 不是高高在上的，社区当中的成员都是平等的。
Q：如何快速将自己的状态调整为社区里比较适合的不卑不亢的状态？
tison：不可能说开源社区有一套机制能确保解决这个问题，因为待人接物不卑不亢是个人品质问题，彻底的办法唯有多看书、多学习，从根本上解决。
如果在参与社区的过程中，遇到沟通上的障碍，可以多观察其他成员是怎么做的，尤其是意见领袖是怎么表达的，喜欢用哪些词汇表达某个意思，等等。不同社区有不同的习惯，重要的是贴合社区的价值观。
Q：前面说了个人参与社区的各种情况，但其实还有一个更重要的主角是企业。有些企业只是想把开源的东西关起门来用，最好没人知道，但也有些企业会非常积极主动地参与到社区里，有没有一些有意思的案例可以分享一下。
tison：企业使用开源的姿势大致可以分成三种，一种是使用开源软件，一种是参与上游社区，还有一种是企业将自己内部成熟的软件开源，并尝试构建开源社区。
国内的企业，常见的情况是无意间使用了开源软件，发现之后试着规范地做供应链分析、安全合规审计等等，这些都属于使用范畴。
一些技术驱动的公司，例如阿里和哔哩哔哩等等，它们的员工都有参与到开源社区的动力和行动。公司层面也会将内部成熟的软件开源，构建影响力，例如阿里捐赠到 Apache 软件基金会的 RocketMQ 项目，哔哩哔哩开源的 go-kratos 项目。另一方面，越来越多的技术创业公司选择使用开源技术或将自身的核心技术开源，以赢得更多关注和合作。例如，PingCAP 开发的分布式数据库 TiDB 就是开源的，StreamNative 则是以制作开源软件 Apache Pulsar 的发行版和订阅服务起家。
国内公司还经常基于开源项目魔改出内部软件，也就是二次开发。如果能够将修改后的版本发布，或者回馈上游，这也是某种参与。至少应该做到的是宣传魔改软件时，声明是基于某开源项目魔改的。大部分开源软件的许可证都要求保留作者信息，当企业对外发布软件时，需要讲清楚软件里面用了哪个开源软件。
几个月前，Volcengine Inc.（火山引擎）基于 Apache SkyWalking 做了一个观测的项目，号称是自研，但后来被发现和 SkyWalking 雷同，而在相关网站上却找不到任何使用 SkyWalking 的声明。这样的项目脱离上游发展，同时没有什么开源精神，也无怪乎今天再去看这个项目，它也和其他千千万万个企业内部项目一样快速消亡了。
Q：企业是否会因为开源软件使用的普及而慢慢变好？根源是什么？
tison：我认为企业的技术发展和开源运动的发展是可以相辅相成的，而这个过程需要我们这些开源活动家的努力。
没有开源运动的时候，企业对软件的要求也可以得到满足，例如招募员工开发或者购买专有软件。所以不是说只有开源软件才能解决企业问题，这是不存在的。开源软件的价值是由开发出软件的开源社群提供的，开源协同有一套经过二三十年考验的所有权机制和声誉激励机制。一旦企业意识到自己可以从开源软件的发展当中获得杠杆，以及可以通过已经在利用的开源软件为自己带来价值，我想企业就能够正视开源工作和开源治理的意义。这有点像价值维度里第二象限的特点，用户不知道自己需要，但是一旦提供，用户会欣然接受。
为了促进开源运动的发展和企业实践开源的进程，我们能做的是宣传如何正确高效地跟已经存在的这个庞大的开源共同体协作，帮助有潜力的项目构建开源社区，并且指出哪些开源社区是有活力的，哪些企业实践开源的做法是好的。
例如前面提到的违规使用开源软件，我们就要指出来批评。不能因为一个事情打上了开源的标签，就无底线的容忍。对于做得好的案例，我也在“夜天之书”公众号里多有撰文介绍。
庄表伟：当年牛顿说，我这么厉害，是因为我站在巨人的肩膀。这种“基于别人的贡献，做出更进一步贡献”的观点和国内的观点是有区别的。在中国，越是没依赖外部力量，自己从头到尾做起来的，越是光荣。反过来，如果依赖了别人，就没那么光荣。但我想说的是，基于别人的好东西做出来比他更好的东西，一点不丢人，这个鄙视链是需要打破的。
Q：当企业想运营一个自己的社区时，你看到过一些什么奇怪的事情吗？
tison：我最近跟朋友交流，经常引用《People Powered》里提到的社区黄金法则，其中一条是“社区成员为社区工作，而不是为你工作”。
一个社区成员会有什么诉求呢？开源社区的终极目的是创造好的开源软件，并使它被广泛使用。好的社区成员的终极目标应该也是如此，在这个过程中，他可以锻炼自己的技艺，收获同行评价带来的声誉，并且可以基于对软件的了解和积累的经验找到工作或是创造一份事业。
我写过一篇文章叫《共同创造价值》，其中提到企业角度做社区运营，一个基本点就是找到社区价值、参与者价值和公司价值的共同点，利用开源协同的技巧玩正和游戏，而不是简单的套用传统的企业管理方法。企业内部的流程，例如审核、绩效考核等等，在开源社区里是不存在的。
社区成员想要直接实现的是个人目标，他的利益与软件质量、个人发展，以及他在社区里的话语权有一定的相关性。另一方面，企业的最终目标是盈利。企业发起的开源社区，常见的问题是照搬企业的管理模式，希望以企业的模式去管理开源社区当中的人和事，导致在管理过程中遇到很多问题。
庄表伟：我想站在企业的角度说一下企业的逻辑。企业一定会有自己的成本，付出了成本便要有收益。比如说我现在往社区里面投 10 个人，明年我要不要投 15 个人，还是只需要再投 5 个人，这是成本必须考虑的事情，很多企业会这样来思考问题。如果投入 5 个人能吸引来 20 个人，就相当于 1 个人能够撬动 4 个社区里的人，如果 5 个人能够撬动 100 个人，那么社区的成本投入就是划算的。商业公司不是做慈善的，这是我想替企业说的一些话。tison 怎么看待这种思维模式？
tison：我觉得这种观点很对，企业就应该这么想。企业面临的挑战是它不知道开源社区的价值如何衡量，因为有些价值在目前的评价体系下看不到，这可能会让企业误以为没有价值。Apache 有一个项目成熟度模型，orbit.love 公司也提供了一系列衡量社区指标的手段，ClickHouse 公开了自己衡量社区指标的查询，这都是一些前沿的探索。
企业面临的另一个挑战是对开源协同模式的陌生。撬动劳动力杠杆是困难的，需要掌握相当的知识和亲力亲为，不是说我今天号称自己建立了一个开源社区，其他人就排排队来“贡献”了。
达成指标并不困难，困难的点在于企业如何认识开源，企业设立开源办公室以后，从上到下和部门之间如何认识这个部门的作用以及如何衡量它的价值。
Q：如何看待企业既要求吸引参与者，撬动劳动力杠杆，又要求能主导开源社区的技术发展方向的问题？
tison：这是可以做到的。企业在开源社区当中的影响分成 hard influence 和 soft influence 两种。
所谓的 hard influence 指的是 Hashicorp 之于它的项目群，VMware 之于 Spring 核心模块，或者 PingCAP 之于 TiDB 这样的，绝大部分乃至所有的 committer 都是公司员工。这种情况下软件要怎么发展自然能够由公司所掌控。
但是如果一个软件为越来越多的企业所采用，它总会走向某种共和制度，多家公司都有自己的影响力，这个时候企业要想引导社区和软件的发展方向，就需要 soft influence 也就是指明方向和投入贡献带来的影响力了。
企业需要什么类型的影响力，应该投入多少人力和时间构建这种影响力，取决于企业的生存和盈利多大程度上建立在对软件的主导权上。一个典型的多家公司参与的项目是 Kubernetes，红帽和阿里都在销售 Kubernetes 的发行版，但是他们对 Kubernetes 上游的贡献可以惠及每一个参与者。他们需要这种影响力，同时也需要让自己的解决方案成为上游标准的解决方案，而不是被其他方案所颠覆。对于 Google 来说，Kubernetes 而不是 Mesos 赢下容器战争，已经能够保护自己的业务不被新技术颠覆，并且维护了 Google 业内技术龙头的地位，这对于公司来说已经是非常卓有成效的结果了。
换个角度讲，主导并不是集权。不是企业的身影无处不在，每件事情都要经手审批。如果真这么做，项目的生产效率会被企业的效率所限制，即使 cosplay 开源，其实际效率也和公司内部开发软件类似。
庄表伟：社区里有非常多的决策，大到架构级的决策，小到 PR 的合入。重要决策可能只占整个社区的 20%，甚至可能只有 10% 是关键决策，而剩下的 80% 都没那么重要。所以我们只需要保证核心特性后面的关键人物。
tison：其实在开源社区里面，方向性的决策并不是主要的内容。我们提 soft influence 的概念，它的建立方法也是企业背景的员工为这个软件开发出有价值的功能。当我们提到企业对公司的主导权，或者影响力、话语权时，必须问自己，到底企业想要达成的目标是什么？
企业想要达成的目标其实只有一个，那就是自己的业务不要受影响，能够持续盈利，赚的越多越好。这点并不是你控制了一个开源社区就能达到的。
如果企业想要保护自己的业务，那么参与上游并把企业内的场景积累出来的经验回馈到上游，在上游的持续集成流水线里加入自己的测试套件，就是一种很可靠的方法。例如阿里巴巴选型 Flink 作为自己的流计算引擎之后，从 2015 年开始连续投入了大量的人力实现了 session window 和 incremental checkpoint 在内的海量特性，并且在 2019 年的时候收购了众多 Apache Committer 所在的公司。小米在公司内部大量使用 HBase 作为存储系统，将自己的经验和需求在上游完成，前后也培养了数名 Apache HBase Committer，这就是一个好的做法。即使不是 100% 的“控制”社区，也不会影响自己赚钱的步伐。
当然，开源社区也不都是合作，确实会有同一个需求不同成员提出不同解决方案的问题。这个时候就需要企业通过长期的经营掌握决策的话语权，来否决不合理的方案。例如 Oracle 在 JCP 决策中强力否决了 OSGi 作为 Java 模块化官方解决方案，这是一个典型的例子。但是这样的方向性决策并不是开源软件开发的主轴。企业应当保持对关键决策的敏感性，但是关注到日常开发和经营才能够收获足够的 soft influence。开源社区当中也有许多谈不拢最后 fork 的故事，并不是说 fork 的一定是弱势。说来话长这里就不再展开了。