GitHub 超 14,000 Star，中国又一 Apache 顶级开源项目诞生！
【编者按】时至今日，Apache bRPC 在 GitHub 上已经收获了 14,356 个 Star，并正式从 Apache 孵化器毕业成为顶级开源项目。但 bRPC 的成功并不是一蹴而就的，开源近 6 年，遭遇过 KPI 方式的失败；团队来自不同公司，都有各自的本职工作，导致一些社区功能没有办法通过团队及时开发；国内外讨论文化的不同、语言的障碍等等。
这篇文章，既有一个开源项目如何实现星火燎原的成长，又是中国开发者如何从开源软件的使用者成长为开源项目的贡献者、主导者的缩影。由 CSDN 及《新程序员》数据研究能够看到，今天，中国开发者主导的开源项目占全球 12.5%，希望通过 Apache bRPC 开源团队的分享，未来，能够有更多中国开发者主导的开源项目活跃在国际舞台，吸引全球开发者参与其中。
前言
从 baidu-rpc 到 Apache bRPC；
从轻量级的 RPC 库到全功能、高性能、云原生的 C++ RPC 框架；
从 2015 年第一行代码到现今的 20 万行代码；
从寥寥无几的关注到 GitHub 14,000+ 的 Star；
从无人问津的社区到 100+ 位贡献者；
从公司内部的 RPC 库到 20+ 的采用公司列表；
从寻找 Mentor 到顺利成为 Apache 顶级项目。
……
Apache bRPC 团队核心初创人员将讲述开源过程中从零到一的跌宕起伏，并以时间轴为线索为你呈现它开源之路背后的故事。读者通过本文可以收获对 bRPC 和 Apache 软件基金会的基本了解、bRPC 在顺利毕业前所遇到的困难和我们对此的思考和解决方案，以及开源的力量和参与开源过程中的收获。
项目介绍
Apache bRPC 是用 C++ 语言编写的工业级 RPC 框架，常用于搜索、存储、机器学习、广告、推荐等高性能系统。
Apache bRPC 的亮点主要包括：
支持多种开源通信协议，如 HTTP、gRPC、Thrift、Redis 等；
丰富的服务发现、负载均衡、组合访问支持；
高度可扩展设计，很容易添加自定义协议和策略；
极致的性能优化；
可视化的内置服务和调试工具。
下图展示了 bRPC 丰富的功能和无所不在的扩展性：
为什么要加入 Apache 软件基金会
Apache 软件基金会（ASF）旨在为全世界提供优质的开源软件，同时欢迎全世界的朋友加入 Apache 社区贡献力量，并在这个过程中不断成长、得到肯定、共建开源社区。无论是否从事软件开发工作，大家多少都知道它的存在及其提供的优质开源项目，可见其影响之大、之深远。
此外，参与 Apache 开源社区，并在自己的努力下成为 Apache Committer 和 PMC 成员，更是大多数软件开发工程师心之所向。
bRPC 在开源之初，就有进入 Apache 软件基金会的计划。其原因有以下几点：
Apache 软件基金会独特的 Apache Way 和社区建设思想会让一个开源项目更规范、更有生命力；
Apache 软件基金会的导师制度会给一个开源社区带来优秀的指导和帮助；
Apache 软件基金会会为旗下的开源项目带来版权和商标上的法律保护；
Apache 软件基金会在全世界范围内的影响不言而喻，若是能进入 Apache 软件基金会，则会扩大项目的影响力，使其进入世界范围的开源领域；
Apache 软件基金会内的项目会更有机会登上世界舞台，并与其他开源项目建立友好交流，也能吸引更多贡献者加入社区。
但同样，进入 Apache 开源基金会的门槛可并不简单，特别对于国内的项目来说，语言和地域的障碍无疑雪上加霜。
成功进入 Apache 孵化器
在 2017 年，我们把 bRPC 开源在 GitHub 上，定期会把百度内部的改动同步到 GitHub 上，此时 bRPC 主要改动的来源是百度内部。开源以后，几个核心开发者陆续离开百度，如何让 bRPC 可以长久可靠地维护下去，并留住项目核心人员，成为我们最需要考虑的首要问题。
当时可行的方案是建立成熟的社区、培养更多的 Committer 和开发者。它的思想有点类似从 Single Point of Failure（单点故障）的团队进化成更可靠的分布式团队的模式。Apache 软件基金会成熟的社区培育模式能够为 bRPC 带来新的视角和方法，于是我们决定把项目捐给 Apache 软件基金会，用 Apache Way 来给 bRPC 注入新的生命力，希望它可以可持续发展。
决定之后，我们首先需要获得百度内部管理层的许可，签署捐献项目所需要的文档。其次，进入孵化，我们需要找到一位领路人和三位导师。当时负责百度开源整体推进的谭中意找到 bRPC 项目当时的负责总监，完成了 Apache Software Grant Agreement 文件的签署。其后谭老师又通过各种关系，为我们找到了领路人和导师。领路人是 Dave Fisher，Apache 软件基金会非常有名望的导师之一，三位导师分别是 Jean-Baptiste Onofré（我们简称他为 JB），Von（冯嘉）和 Kevin A. McGrail，后来 Kevin 因为太繁忙而中途退出，我们又找了 Apache 软件基金会中国地区的第一位女性成员——潘娟作为导师。他们给 bRPC 在建立社区和代码 License 规范上提供了不少的建议。我们也借鉴了不同开源项目的经验，在 2018 年成功发了第一个 Apache（WIP）版本。后来的发版过程也越来越顺利。
整个过程不在这里详细说明了，简单来说主要做了如下几件事情：
将所有文件的 License 改成 Apache 软件许可协议（ASL） ，并检查第三方代码是否和 Apache 兼容；
把所有的文档翻译成英文；
提交一份提案来申请进入 Apache 孵化器。
社区之火如何燎起
提案通过之后，就是孵化和培养社区的过程。到今天，我们已经有由 6 个发版管理员发的 6 个正式版本。在今年（2023），还会考虑加入更多的功能发版。
用户、贡献者、Committer 和 PMC 的逐渐增加和多样性的变化
进入了 Apache 孵化器以后，我们面临的问题是：怎么让社区活跃进而扩大？社区的活跃对于开源项目尤为重要，无论是用户、贡献者还是 Committer 的活跃都会给项目带来收益。活跃的社区会带来活跃的开发者，活跃的开发者又促成活跃的社区。
在初期我们很难找到合适的新人加入开发队伍。关键在于：开源项目不是公司项目，没有明确的 OKR/KPI 驱动，大家参与的动力主要是兴趣和技术驱动；C++ 是一门复杂的语言，入门门槛比较高；C++ 场景的多样性在慢慢变小，以致于不是所有开发者都知道 bRPC，也就没办法参与。
针对上面这些问题我们也采取了一些措施来尝试解决。
对于第一点，当时没有很好的解决办法，靠谱的方式是把社区建好和文章写好，可以吸引更多的开发者和用户。我们相信好的项目自然会吸引更多的开发者参与进来，事实也证明了这一点。当然也做了一些的运营活动来帮助推广。
对于第二点，我们写了入门文档（https://brpc.apache.org/zh/docs/getting_started/），以及在 GitHub 上标注了 Good First Issue（对新人友好的 issues）方便开发者提交一些基本的代码和完成整个提交流程。我们还举行了若干个线下的活动。
对于第三点，我们通过建立 QQ 和微信的开发者和用户群，在线回复了很多用户在使用 bRPC 的过程中遇到的疑问，来拓展更多的 bRPC 使用场景和培养更多的开发者。
截止到目前为止，bRPC 已经有 16 位 Committers，129 位贡献者（2023.01 数据）。
来自社区贡献的功能持续增加
开源的这几年中，我们经历了功能的持续迭代。相比刚开源的时候，我们发布了更多的功能，提高了更多的稳定性，一开始由百度内部完成，后来大部分都是由开源社区共同完成。比如说 HTTP2、gRPC 协议支持、自适应限流、熔断器、Prometheus 支持、Mac 支持、Arm 支持等重要功能都是由开源社区共同完成的。
开源 5 年（包含 4 年的 Apache 孵化过程）中团队遇到的困难以及成长
开源以来我们主要遇到下面几个问题。
（1）精力问题
由于大部分 Committers 都有自己的本职工作，参与开源工作需要平衡好本职工作和开源工作，作为社区的一员，可能会出现因为优先级的原因要离开 bRPC 的开发工作一段时间然后之后再回来继续参与开发，这在 bRPC 目前的社区下完全是可能的：工作会由社区其他同学完成。社区的存在让团队由 Single Point of Failure 变成了分布式的。参与开源会增加额外的工作量，这里开发者就要更加小心去平衡好这些额外的工作量。避免由本职+开源的长工时引起的职业倦怠（Burnout） 是让生活和工作可持续进行的重要因素。
（2）社区的建立和本土化。
由于 Apache 社区鼓励用邮件列表和订阅的方式来讨论问题，这样做的好处是所有的讨论都可以留档，方便之后再次查看和搜索；但这种方式并不适合国内的讨论文化，大家更喜欢拉一个群，在群里讨论问题。于是在初期，为了更好地与用户交流，我们就建立了一个 QQ 群和微信群，来讨论各种问题。后来经过实践，我们采用了一种折中的方案：用 GitHub Issues 来记录一些值得留档的内容，比如需要开发的功能描述、某一个需要解决的 Bug 或者一个反复出现的问题；用微信群来解决一些需要及时沟通的问题，让用户遇到问题时可以更快联系到开发者。
（3）团队来自不同公司，大家有各自的本职工作，导致一些社区 Feature 没有办法通过团队及时开发。
我们并没有一个专门的团队来实现来自社区的需求。很长一段时间以来，合入的新功能往往是开发者在自己公司有一个这样的需求，在内部开发完成并上线稳定了，然后把这个功能贡献给社区；如果作为用户有一个新的需求，自己并没有意愿或能力去实现的话，只能依赖社区有人遇到相同的问题，然后贡献代码。这个情况在 2022 年有所好转，主要是我们吸纳了更多成员，同时戈君等早期成员回归，带动整个社区更加活跃，Issues 解决和 PR（Pull Requests）合入的速度都有了明显加快，并且形成了每个季度定期发版的节奏。
（4）社区的可扩展性。
原有的机制没有办法适应到越来越大的社区。例如，刚开源的时候可能一个人花一两个小时就能看完一周内所有的 issues 和 PR，而随着社区越来越壮大，这样的方式被证明是不可扩展的，因为个体的时间总是有限的。于是一些新的机制得以建立来解决这些问题：1. 建立 Oncall 轮值，每位同学只有在 Oncall 时才被期待去解决社区的 issues 和 PR；2. 对于一个需要合入的 PR，需要有一个来自 Committers 的 LGTM（Looks Good To Me，指代码已经过 Review，可以合并）就可以合入 master；3. 各种流程的文档化。例如，我们选出下一位发版经理后，只需要按照发版文档来进行发版就可以了。感谢这个发版文档的主要作者——PMC 成员李磊。随着社区变大，我们还需要探索更多更好的方式来适应这样的社区规模，来让 bRPC 发展得更快更好，不被非技术原因的瓶颈所限制。
开源的力量
bRPC 已经是真正意义上的开源项目，Committers 的公司分布非常广泛，大部分新合入的功能也是由社区共同完成。本篇主要介绍我们理解的开源带来的力量。
KPI 方式的失败
bRPC 刚加入 Apache 孵化器不久的那一段时间，当时百度还是很重视 bRPC 的发展，在内部找了一些同学，给他们设置了 KPI，比如一个季度要合入多少个 PR、要在什么时间毕业等，但实际的效果并不好。原因是这些同学并不是真正的对 bRPC 项目感兴趣，缺乏持续贡献的动力。另一个原因是来自百度内部的 PR 和社区的需求并不完全一致，缺少和社区成员的沟通，因此难以被社区接受。KPI 的方法维持了不到几个月就宣告失败，事实证明社区的力量才是推动项目发展的真正动力。
社区与土壤
开源社区和产品的关系有点像土壤和树的关系：不能做拔苗助长的工作，只能做好灌溉的工作，并相信树在好的灌溉下会茁长成长。bRPC 的毕业是一个新的开始，它标志着 bRPC 社区已经是成熟可自治的社区，我们在未来会继续去发展社区（土壤），相信良好的社区会让 bRPC 发展良好，使其在更多的场景下更好地发挥它的能力。
参与开源社区的收获
参与开源社区是需要花额外精力的，除了可以为产品本身做贡献，我认为它为工程师自身带来的收获也是巨大的。
（1）开源项目提供有别于公司项目的视角，可以学到不同的技术栈和开发流程；
（2）能认识有同样兴趣的工程师，他们往往来自国内外不同公司，交流能产生更多收获和思考；
（3）开源项目中获得更多的成就感：短短一行代码的提交可能会影响所有的使用公司，具有杠杆效应和大的影响力；
（4）参与社区是一份公开的简历，由于所有的讨论和提交记录都是公开的，所有人都能看到你提交和讨论了什么；
（5）紧跟业界动态：知道业界需要的是什么样的 RPC 框架，以及上层使用 bRPC 的应用有什么具体的需求。
从孵化器毕业，成为顶级项目
所有孵化器的项目最终都希望能走向 TLP（Top Level Project，顶级项目）。在 Mentor 的指导、PPMC 的探索、Committer 和 Contributor 的支持与付出下，bRPC 开始筹备从 Apache 孵化器毕业。
Apache 成熟度评估模型
依据如上所示的 Apache 的成熟度评估模型，可以很好地评估社区和项目是否成熟。其实在 Apache 项目社区的初建阶段，建议大家就在这几个方面发力，因为这是官方给予的毕业标准及指导方针。以此为方向，探索属于各自项目的独特社区运作方式，也可谓是百花齐放。
经历 Release、社区建设、Apache Member 的指导、Meetup 举办等一系列事件，bRPC 终于在社区发起了毕业讨论，开始接受 Apache Member 及所有 Apache 成员的指导和评估。即便是经过四年多的社区建设，项目基本成熟，但面对毕业还是有很多工作要合乎规范，例如确认商标是否可使用、完成项目官网有关 Apache brand 和 trademark 的陈述、网站符合 Apache Way 等。
最终，bRPC 以 16 +1 binding votes、9 +1 non-binding votes 和 no -1 or +/-0 votes 顺利通过毕业投票。
2022 年 12 月 22 日，Apache bRPC 最终通过基金会董事会决议，加入了 TLP 行列。2023 年 1 月 26 日，Apache 软件基金会正式官宣，Apache bRPC 成为顶级项目。
Apache 软件基金会官宣博文
未来之路
回首这一路，收获与付出兼存，而在文章结尾，我们也特别想对开发者朋友说：
感谢所有参与 bRPC 项目的贡献者！你们是这个项目能够成功毕业的基础，你们的贡献和支持是我们最大的动力，你们的积极参与和不懈努力让 bRPC 能够不断成长，特性更加丰富、更加稳定可靠、更加灵活易用。我们真诚地感谢你们，希望你们继续在 bRPC 开源社区中做出贡献。
从 Apache 孵化器毕业成为 TLP，对 bRPC 来说，并不是一个结束，而是另一个开始。在产品功能上，bRPC 将继续在 RPC 领域上深耕，支持更多协议，提供更丰富的服务治理能力；在性能方面，bRPC 将不懈追求极致性能，引入 RDMA、DPDK 等高性能网络技术，优化线程模型和事件模型等。从社区角度讲，bRPC 仍将继续活跃社区，鼓励更多朋友成为社区的 Committer 和 Contributor。所以，我们欢迎大家关注 bRPC，并加入到社区来，与更多知己结伴前行，我们也希望能够和大家一起探索 bRPC 的更多的应用场景。
虽然未来的路不可预测，但我们还是坚定地立足于当下，眺望未来，持续地追求我们的愿景。
Apache bRPC Committer 列表
Mentor
Jean-Baptiste Onofré
Von 冯嘉
潘娟
PMC
戈君，字节跳动
何磊，字节跳动
朱佳顺，Google
陈章义，Momenta.AI
蒋如杰，字节跳动
王耀，百度
王伟冰，百度
谭中意，第四范式
蔡道进，Shopee
李磊，自由职业
Committer
牟盖东，腾讯
王维，腾讯
刘帅，百度
王晓峰，百度
胡希国，百度
陈光明，欢聚时代
Apache bRPC 官网：
https://brpc.apache.org/
GitHub 地址：
https://github.com/apache/brpc
作者信息：
朱佳顺，Apache bRPC PMC，目前就职于Google
王伟冰，Apache bRPC PMC，目前就职于百度
《》特别策划了“开源深度指南”专题。由 Apache 软件基金会 2022 年董事姜宁担任顾问，邀请当今开源世界的先锋人物，包括 Python 之父 Guido van Rossum，MySQL 之父Michael "Monty" Widenius，Apache之父、OpenSSF开源安全基金会总经理Brian Behlendorf，MongoDB CTO Mark Porter、凝思董事长宫敏、Linux 内核守护者吴峰光等，更有国内外开源基金会、知名企业代表，从开源安全合规、企业内部开源、开源技术创新、开源行业落地等多方面，为开源背后的开发者、企业、开源组织及开源社区提供更清晰的开源生态建设与升级版开源发展全景式图鉴。点击下方小程序即可立即订阅！