GitHub 超 14,000 Star，中国又一 Apache 顶级开源项目诞生！( 三 ) 【编者按】时至今日

文章图片
2019年开源年会上， bRPCWorkshop合影对于第三点，我们通过建立QQ和微信的开发者和用户群，在线回复了很多用户在使用bRPC的过程中遇到的疑问，来拓展更多的bRPC使用场景和培养更多的开发者。
【GitHub 超 14,000 Star，中国又一 Apache 顶级开源项目诞生！】截止到目前为止， bRPC已经有16位Committers ， 129位贡献者（2023.01数据）。
来自社区贡献的功能持续增加
开源的这几年中，我们经历了功能的持续迭代。相比刚开源的时候，我们发布了更多的功能，提高了更多的稳定性，一开始由百度内部完成，后来大部分都是由开源社区共同完成。比如说HTTP2、gRPC协议支持、自适应限流、熔断器、Prometheus支持、Mac支持、Arm支持等重要功能都是由开源社区共同完成的。
开源5年（包含4年的Apache孵化过程）中团队遇到的困难以及成长
开源以来我们主要遇到下面几个问题。
（1）精力问题
由于大部分Committers都有自己的本职工作，参与开源工作需要平衡好本职工作和开源工作，作为社区的一员，可能会出现因为优先级的原因要离开bRPC的开发工作一段时间然后之后再回来继续参与开发，这在bRPC目前的社区下完全是可能的：工作会由社区其他同学完成。社区的存在让团队由SinglePointofFailure变成了分布式的。参与开源会增加额外的工作量，这里开发者就要更加小心去平衡好这些额外的工作量。避免由本职+开源的长工时引起的职业倦怠（Burnout）是让生活和工作可持续进行的重要因素。
（2）社区的建立和本土化。
由于Apache社区鼓励用邮件列表和订阅的方式来讨论问题，这样做的好处是所有的讨论都可以留档，方便之后再次查看和搜索；但这种方式并不适合国内的讨论文化，大家更喜欢拉一个群，在群里讨论问题。于是在初期，为了更好地与用户交流，我们就建立了一个QQ群和微信群，来讨论各种问题。后来经过实践，我们采用了一种折中的方案：用GitHubIssues来记录一些值得留档的内容，比如需要开发的功能描述、某一个需要解决的Bug或者一个反复出现的问题；用微信群来解决一些需要及时沟通的问题，让用户遇到问题时可以更快联系到开发者。
（3）团队来自不同公司，大家有各自的本职工作，导致一些社区Feature没有办法通过团队及时开发。
我们并没有一个专门的团队来实现来自社区的需求。很长一段时间以来，合入的新功能往往是开发者在自己公司有一个这样的需求，在内部开发完成并上线稳定了，然后把这个功能贡献给社区；如果作为用户有一个新的需求，自己并没有意愿或能力去实现的话，只能依赖社区有人遇到相同的问题，然后贡献代码。这个情况在2022年有所好转，主要是我们吸纳了更多成员，同时戈君等早期成员回归，带动整个社区更加活跃， Issues解决和PR（PullRequests）合入的速度都有了明显加快，并且形成了每个季度定期发版的节奏。
（4）社区的可扩展性。
原有的机制没有办法适应到越来越大的社区。例如，刚开源的时候可能一个人花一两个小时就能看完一周内所有的issues和PR ，而随着社区越来越壮大，这样的方式被证明是不可扩展的，因为个体的时间总是有限的。于是一些新的机制得以建立来解决这些问题：1.建立Oncall轮值，每位同学只有在Oncall时才被期待去解决社区的issues和PR；2.对于一个需要合入的PR ，需要有一个来自Committers的LGTM（LooksGoodToMe ，指代码已经过Review ，可以合并）就可以合入master；3.各种流程的文档化。例如，我们选出下一位发版经理后，只需要按照发版文档来进行发版就可以了。感谢这个发版文档的主要作者——PMC成员李磊。随着社区变大，我们还需要探索更多更好的方式来适应这样的社区规模，来让bRPC发展得更快更好，不被非技术原因的瓶颈所限制。