专访 Tetrate.io 创始工程师吴晟：开源领域需要 40+ 的开发者，也需要更张扬的年轻人

不久前，「一源初始，开放共创」开放原子开源基金会 2020 年度峰会于北京圆满落幕。峰会由开放原子开源基金会主办，阿里巴巴、百度、华为、趣链科技、SegmentFault 思否、招商银行等开源项目代表单位及开源社区协办，亦得到了全体理事单位的大力支持。

会议中，Tetrate.io 创始工程师、Apache Member、Apache SkyWalking 创始人吴晟进行了主题分享，并参与了开源运营治理分论坛的圆桌讨论环节。在分享中，吴晟提出了对国内开源环境以及开源和商业间的思考。SegmentFault 思否对吴晟进行了专访。

Q1：如果需要给“开源”下一个定义，您认为是什么？

开源在我的印象中，是一个技术工程师在跨商业实体间合作的平台与机会。在传统的开发模式中，工程师开发的软件只能在公司内部共享，而借助开源，可以和其他公司的人一起来开发、分享。对于工程师来说，这样的开发模式会更有成就感，项目的质量要求相比之前也会高很多。

Q2：开源领域有很多角色分工，比如工程师、宣讲者等等，您认为您在开源领域当中的角色是什么？

主要还是一个工程师的角色。SkyWalking 最早就是我自己参与开发的项目，所以开发者的身份在我的日常当中占据很大的比例。布道、运营之类的工作也会有一些，但主要是在项目进入 Apache 基金会并顺利毕业之后，会有一些外部活动邀请进行相关的经验分享。

Q3：现在比较普遍的一种认知是，开源的参与者不只局限于开发者。您觉得各种角色的加入对开源来说会造成哪些促进或影响？

其实就像一个软件公司，除了开发者之外也是包含很多其它角色的。比如宣传市场、售前售后等等，但无论是哪一种身份，大家都是抱着同一个目的，在为同一个产品或开源项目在服务，在合作共建。

开源只是将这件事情放大了，把公司里由几个人干的事情进行更广泛的分工，找到更多擅长的人来一起完成。因为不可能一个人什么都会，需要有不同身份的角色参与其中。

Q4：能否分享一下您对国内开源领域的看法？

国内开源领域有一个现象，是大家现在看到了开源背后的更明确的商业价值，所以有点“一窝蜂式”的涌入。

这个现象的结果可能跟其它所有行业一样，在“一窝蜂”的涌入后，会在一个时间内变的非常繁荣，但到了下一个阶段，其中有一部分人可能会被淘汰掉。但泡沫总是会破灭的，能剩下的才是那些真正务实的项目和人。

开源项目的核心是为了解决一个具备通用性的问题。如果项目真的能解决一批人的问题，那不管泡沫破不破灭，它都会一步一个脚印的活下来。但如果单纯是靠造势、造泡沫发展起来，就会长得快破的也快，项目很快也会被大家忘掉。

Q5：您认为开源与商业间的关系是什么？开源项目应该如何协调与商业间的关系？

我最近在和 PingCAP 的朋友聊天中，谈到一个很有共性的思考。

以前的开源项目有几个发展阶段，最开始会是卖所谓的商业版产品，但这种方式在今天的成功率已经很低了。做开源项目的商业版，意味着会“藏”一些东西。但“藏”这个事情对于开源领域来说是很反感的，用户会认为你只是开源了一个玩具，开源出来的项目本身就没有多少价值，也会和商业版产生竞争关系。

比如你将一些功能“藏”了起来，外部的项目贡献者为你提供了一个一模一样的功能，你就需要考虑是否要将这项功能合并进来，如果不合并又需要用什么样的理由去拒绝。

所以现在最典型的开源模式就是像 RedHat 一样的全开源，项目功能全部都是开放的，只售卖咨询服务。全开源保留的只是“人”。写项目的人是我的，所以我在这个项目中最专业、最擅长。

第二种就是卖云服务。云服务应该是现在相对比较好挣钱的方式，但也有一定的门槛。比如说太小的开源项目或者太组件化的项目就很难售卖配套的云服务，而偏产品化的产品就相对比较好卖。

第三类在国内还相对较少，就类似于我们在北美的那家公司一样，做的是一个商业产品，但产品 95% 以上的功能都是来自几个不同的顶级开源项目。我们把它们“捏”在一起为客户解决一个实际的场景需求，提供了一个完整的商业产品。

Q6：您觉得什么样的企业适合参与开源？

我之前接触过各种各样的企业，如果要细分的话，如果一家想要主导开源，或者想要新做一个开源项目的话，企业一定要具备“技术范儿”，是一个技术导向的企业。

我们可以看到国内很多互联网企业开源的很多东西，可能过了两三年就没人管了。本质上开源的目的是因为内部需要，但很长时间没有进行改进，外部也只是拿走去用，然后开源项目的热度就慢慢降下去，没有人再使用了。这是一个最常见的情况。

另外一种，如果只是参与开源，那门槛其实就没有那么高。只要是自身也需要这个领域的东西，无论是使用还是贡献其实都是参与的一种方式。

Q7：企业开源项目两三年后便不再维护的原因，一般都有哪些？

没有找到商业化路径肯定是原因之一，没有利益驱动会导致后续不再投入成本进行维护。

第二种常见的现象是国内互联网公司的一个特性。很多公司的员工从一个职级晋升到另一个职级时，开源项目会是一个评估指标，所以很多工程师会利用工作时间和业余时间来完成这个指标。但随着两三年后的晋升成功，到了下一个级别的情况就不一样了。国内很少有高职级的纯工程师，基本上华为 20 级以上、阿里 P8 以上的时候，很难会有沉下心来写代码的工程师。

到了这种级别就需要分出一部分精力参与项目合作、市场宣传、管理等等，而开源项目的发展必然就会受到影响，甚至死掉。

但其实很多所谓的“KPI 开源项目”都是好项目，也有很多人用，也能解决很多实际的问题。但问题就是缺乏延续性，给大家一种感觉就是国内没有“开源大项目”。没有历史悠久、在领域内耕耘多年、特别资深的项目，国内这样的项目确实是比较少的。

Q8：您认为基金会的出现和介入，对这种情况是否能有所改善？

这个和基金会的运作模式有关系，也就是基金会模型的问题，比较典型的就是 CNCF 和 Apache 之间的区别。

如果一个项目捐献到 Apache，如果社区没有建立好，初始的人离开项目还是很容易死掉的。CNCF 也类似，会要求 3-4 家公司成为项目的主要构建者，如果少了一家公司可能不会对项目造成太大的影响，如果再少一家公司，情况可能就不同了。

基金会只是一种组织形式，可以让大家放掉很多顾虑。不会出现一家公司影响项目生死的情况，但项目的具体发展，即使是在 Apache 或者 CNCF 这类基金会中也有很多不那么成功的项目，包括我自己在 CNCF 中有一个参与了的项目，就做的很不成功。虽然那个项目做了铺天盖地的广告宣传、有名厂站台，但项目本身不是非常被市场需要，并没有预期中那么有用。

包括像我们这种最早的项目参与者，认为这个东西好像挺有用的，可以解决很多的问题，但随着深入，大家都觉得这个产品似乎并没有那么好，事实上的效果也没有达到预期。

所以项目会起到决定性的因素，如果项目不好，哪怕是最顶尖的工程师来操刀、加入最顶尖的基金会，该做不起来还是做不起来。

Q9：您觉得对于开源项目有没有一些评判标准？

最关键的就是项目的主人或核心贡献者，他们最清楚项目的价值与优劣。

往往我们在评价别人的开源项目时，会有很多空子可以钻。比如说 Star、Fork、Watch、Contributer、提交频率、issue 解决时间等等，这些都是有空子可钻的。尤其是对开发者来说，各种接口都摆在那儿，找到规律之后甚至都不要人来具体执行。

所以评价项目是不是真的有价值的重点，是有没有那么多人或者厂商，真的基于自己的需求在不停的和项目之间进行沟通、相互提高。如果能在项目中看到这种情况，那么这个社区可能就是成功的。哪怕有很强的商业背景、很强的 KPI 背景，只要用户认可，认为这是一个好项目，贡献者也认为这个项目符合我解决特定问题的思路，我们就会把这个事情干好。

我们举个最简单的例子，比如一个知名厂商开源的系统可以在一夜之间吸引到 1000 个工程师，吸引到 1000 个 contributer ，但另一个项目可能只有两三百位贡献者，不过都是真正有需求的用户，这两个项目的社区活跃性、体系化和延续性，都有很大的差异。后者实际上要强大的多。

不同的项目贡献者的数量肯定也是不一样的，如果是一个全套的 IT 系统，那么覆盖的人群就会非常广，而另一个项目可能只是其中某一个非常具体化、细节化的需求，覆盖的人群就会相对少很多。所以不能单纯从数量来作比较，还要考虑一个市场占比的问题。

Q10：SkyWalking 作为一个顶级的开源项目，成功的关键因素是什么？有哪些环节您认为做的比较好？

最重要的一点是大家真的需要这样的一个产品。SkyWalking 没有专职的 Marketing 同事，相对其他项目在宣传、包装之类的方面做得非常少。

我们还是希望好好的做技术，和研发人员打成一片。只要真的愿意来贡献，我们就可以深入探讨如何将这个事情做好。

下一步的计划比较清晰，要涵盖监控领域绝大多数的场景。

最早的阶段 SkyWalking 只做追踪这一块的业务，后来增加了拓扑图分析、Metrics计算、API 监控、Service Mesh、日志监控等等。我们会推出更全面的解决方案，也是因为看到一些贡献者有这样明显的倾向。

当初最难的问题我们解决了，现在大家希望的是将工具都能往这个上面来靠，将一些相对陈旧的东西迁移到最新的产品当中，保证平台的唯一性。

从项目本身来看，我们在 Agent 和 Mesh 做的最好，最核心的重点肯定会在这个方向，但从社区来看，是有这样的一个趋势。

Q11：国内外的开源社区，在运营模式和发展方向上是否存在一些区别？

主要的区别有两点。

第一点是参与者的专业性。国外有很多专业的“开源玩家”，在他们的职业生涯中可能碰到过 2、3 个成功的顶级开源社区或者开源项目，在做一个新的开源社区时会更加得心应手，不会走弯路。

第二点是团队作战，这在国内是最难的一件事情。我们的开源项目没有跨实体的集团做的，都是一两个人或者一家公司，在对抗国外可能是五家十家全球顶级企业开发的项目，在对抗一个行业。

国外很多行业都有一种私下的“君子协定”，他们会在同一个航道中走，而如果想跳出这个航道或者做一个平行航道，那就会不在同一个水位线上，很容易被对方淹没。

Q12：有哪些技术领域，国内可以通过开源来占据一些地位？

我们还是举 SkyWalking 的例子。在最开始做这个项目的时候，绝大多数人对 API 都不太了解，但国外做的其实是非常强的。我们要考虑的几个点是自己能不能走得出去。

全球化社交对中国来说是一个硬伤，这并不单纯是语言的问题，更多还是一个大的生活习惯和文化环境导致的。我们国家幅员辽阔，在大家的概念中出国永远都是一件“大事”，包括我之前所在的公司，出国参加一个会议，审批都要比国外多好几级。

但有些时候，出国甚至比国内出差在地理距离上还要近，比如去日韩、东南亚之类的，并且出国也很方便，但我国企业在这些地方发展的还是很有限。除了一些出海产品走出去了，但缩小到技术领域来看就更少了。

比如在东南亚和印尼，当地的技术活动是很多的，但中国没有机会去互相沟通、交流、推广开源解决方案等。我们可能需要先把这个壁垒打破，技术反而不是第一个致命的问题。

现在的问题是我们有好技术，但推不出去，是被迫在国内搞。而大家又会因为你的项目只在国内活跃，大家就会担忧你的盘面会不会太小、不被国外企业厂商接受。

现在行业内有一个共识，就是不能只在国内市场发展。短期可以，但可能不会做的太长久。

Q13：解决国内开源问题，最重要的一步是什么？

我的想法是“一上一下”。

大家都在讨论开发者 35 岁或者 40 岁会是一道鸿沟，我觉得这在短期内确实很难避免，毕竟这和国内很多企业实际的运营情况相关。“上”就是指 35 岁以上、40 岁以下的工程师能不能有更多的人留下来，企业给他们更大的空间去写代码？

我有一个感受，在国内大家可能觉得我是一个资深的工程师，但每次出国参加活动我都是最年轻的。国外有些工程师可能代码已经写了 40 年，头发都白了。之所以坚持下来，也许他挣得足够多，也许他只是单纯的喜欢，但那个环境给了他这样的一个机会。

我们在日常的项目运营中，看到很多年轻工程师有精力、有一腔热血，但做事情很容易走错方向，因为行业经验太少了，是按照以往的经验来干活，不知道前面可能有一些什么样的坑在等着。

但假如有这种 40 岁以上的开发者能帮他们指出问题，就可以少走弯路。哪怕他们的代码量不多，但代码质量相对来说一定会是很好的，并且更能沉得住气来解决问题，更能接受长线的运营项目，就像中国的第 N 个五年计划一样。我觉得这是对高年龄程序员的一个定位。

我非常愿意看到有一天，当我们在 coding 的时候既有年轻人，也有资深年长的程序员，

“一下”，指的是学生群体。现在很多老师已经做了很多工作，所以这部分的发展比上面的发展要好很多。我经常能看到很多新鲜血液，比如 SkyWalking 的群里就有高中生。虽然我们的项目是个工业项目，不知道对他来说会怎样使用，但能吸引年轻人的重视，是一件很好的事情。

现在大家都很重视年轻人，无论是媒体、政府还是厂商，都非常重视对于学校的布道，只要我们把该讲的讲对了，别布错了方向，那我觉得这部分之后的发展，问题不大。

Q14：您觉得给年轻群体推广开源文化，有哪些需要注意的点？

我觉得要让我们的学生更张扬一些。我喜欢现在的一些 90 后，能在文字的环境中表现出张扬的一面，但我希望他们能够再张扬一些。

你要相信你的观点和观念，真有经过讨论和学习，确认别人的观点更好或者更准确的情况下，再去放弃自己的观点和观念。但无论如何，都要能站出来，持续的表达自己的观念。现在能看到很多大学生观念很强，但对于维护自身观念的坚持不够。

第二点就是需要给学生更多上台的机会。我国的教育常年造成的一个现象是没有人愿意站在台上讲，一上台就会跑掉一半的人。做卷子可以、写文章写邮件文字采访可以，但如果要上台讲个 10 分钟，那分享的东西可能就乱套了。

国外的学生因为教育的原因，在个性方面相对会更加张扬，更能在公开场合坚持表达自己的观点。SkyWalking 有一个 90 后的贡献者，他就是那种知道自己经验不足但会坚持表达的人，这样才可能做出一些之前想不到的事情。比如他把 SkyWalking 集成到了 IDE 中，在源代码中就可以看到指标，这个思路就很特别。

这就是年轻人的独特价值，是 40 岁的开发者提供不了的。但 40 岁的开发者可以保障你的奇思妙想得到很好的、快速的实现，避免走偏路。

只有“上下”都发展起来，整个开源的队伍才能建立起来。现在开源领域大部分的开发者工作年限可能也就是 5、6 年，虽然也能在一些项目中看到一些 40+ 的开发者，但他们大部分都是没有开源经验的。国内这方面的发展可能确实还需要再熬一熬、等一等。

开放原子开源基金会在开源领域开了一个先例，我们虽然不能指望有什么快速的产出，但他给了我们一种可能性、一个靶子。给了我们一个去做比较、去发现问题的方式。

基金会中第一批开源的项目，我们不能下定义它们是否会成功，但无论结果如何，在发展的过程中会有很多教育和借鉴的意义，这可能是最有价值的地方。

---