转载

姜宁，带程序员前往开源“乌托邦”

在各种会议或者视频中做自我介绍时，姜宁常常用这张照片——穿着蓝白黑的格子衫，背着双肩包，脸上带着笑，两手直直地放下，任谁看一眼都能猜到，他是程序员。

他确实做了十几年的程序员，但有一点特别的是，他为 Apache 软件基金会（ASF）的开源项目写代码。一开始，开源于他而言，不过是一份挣钱的职业。被推着走了很久之后，有一天终于意识到，在工作之外，自己要担负起开源布道的责任。

一开始只是组织贡献者线下见面，后来发起了 Apache 北京本地社区，协助成立 Apache 深圳本地社区，将 ASF 项目开发者，与社区开源爱好者聚在一起。这两年，他还开起了播客，以嘉宾访谈的形式，宣传开源相关的知识和文化。

他将“Open Source Community”翻译成“开源共同体”，称之为程序员的乌托邦，是除了 996 ，程序员可以拥有的另一个选择。“在这里，程序员们通过邮件，代码评审一起交流编程心得，一同协作开发足以改变世界的开源项目，在这里，菜鸟可以够得到高手的帮助，快速成长成为业界大牛。”

今年 3 月初，姜宁当选 Apache 软件基金会（ASF ）2022 年度董事。他在董事竞选宣言中说，“希望能够帮助 ASF 打破地域、文化、语言的障碍”。

在开源布道的路上，他已然看到了横亘在面前的难以逾越的大山。纵使如此，姜宁也要踏过去。

01 成为开源布道师

对姜宁来说，四年前的“抄袭”风波仍然在敲响着警钟。

2017 年 6 月，华为开源了微服务框架 ServiceComb，托管在 GitHub 上。及至年底，该框架的 GO 语言版本 go-chassis 也开源了。

不料十几天后，go-micro 的作者 Asim 前来讨说法，因为 go-chassis 使用了其部分代码，但没有按照开源许可证的要求作出声明。经过沟通之后， ServiceComb 团队立即修改了代码，并得到了原作者的认可。事情到这里似乎已经解决。

但传到国内后，一切都变了味，舆论把它演变成了华为抄袭。

姜宁赶紧在知乎上解释，但并没有多少人关心事情的详细经过，以及他们做了什么，大部分人都盯着他们没做什么，以此发泄情绪，“故意”、“抄袭”、“狡辩”，即便有人发表中立观点，也被指是在为华为洗地。百口莫辩。之后，他没有再追上去解释。

现在回过头来看，姜宁正处在职业生涯转型的关键时期。2017 年 1 月，做了十几年开源程序员的他，来到了华为担任开放能力中心的技术专家，成为了一名开源布道师。“我来华为，就是要把我对开源世界的理解，把我做开源的经验，转化成一些基本实践原则，来帮助项目成长。”没成想，却在一年之后发生了 go-chassis 事件。

这件事不仅仅打击了他的个人声誉，还把公司拉下了水，被扣上“抄袭”的帽子。整个项目开发节奏也被打乱，最终 GO 语言部分的微服务框架代码，没有进入 ServiceComb。

从事开源开发十多年，他也是第一次遇到这样的事。教训很深刻，让他看到了很多，也学到了很多，深感开源布道重要性。“以前做开源，是跟着大牛学习，只需要遵守社区的规则，按部就班参与进去就可以。但现在，要带着没有开源协作经验的小朋友们一起开源，需要考虑的事情更多了。”

姜宁曾向项目团队成员交代过，要规范使用代码，但很多开发者不重视开源代码的版权，缺乏合规意识，只想快速实现功能。“以为开源的代码，想怎么用就怎么用，想怎么改就怎么改。这种想法是有问题的，最终是会付出沉重代价。”姜宁评判说。

事实上，在项目正式开源之前，所有自研代码都会用工具进行查重审查，以确认代码是否符合规范，但工具不能识别所有的问题。

他认为，唯有提升程序员的版权意识，避免片段化引用第三方代码才能彻底解决这一问题。

"尽量以库的方式来引用第三方开源代码。否则，很难说清楚自研代码和第三方开源代码的关系，操作稍有不慎，就很容易被扣上抄袭的帽子。如果要修改第三方开源代码，要把需求或者补丁提交到上游代码库。这样即减轻了我们维护第三方代码的工作量，也进一步完善了第三方开源代码的使用生态。 ”姜宁总结道。

他也意识到，开源之后，所有问题都是敞开的，如果涉及大厂，问题会被放大，影响更恶劣。“版权意识，是每个开源人都要具备的。”

经此一事，国内更多项目开始关注开源合规的问题。姜宁也经常拿这件事来当反面案例，“不能把别人开源的代码拿来随便用，要严格按照开源许可证的规范来。”

这场风波直接让姜宁的职业生涯陷入了危机，但无暇顾及太多，他还有很多事要忙。就在两个月前，ServiceComb 项目捐赠给了 ASF，进入了孵化阶段。

姜宁意识到，要想让项目从 ASF 顺利毕业，除了合规发版，还需要构建起健康发展的共同体，发展外部贡献者。而要发展外部贡献者，就要扩大项目的影响力。影响力又是靠用户不断积累起来的，所以要发展更多的用户。

他采取的方式很原始，主动跟对项目感兴趣的人聊天，聊业务背景，聊实现细节，聊如何解决大家的痛点问题。起初，姜宁的内心有些抗拒——他以前是一个很少抛头露面的技术宅，转做社区工作后，开始还有些不适应，但随着时间的推移，他发现，通过这种方式，自己结识了很多志同道合的小伙伴。

“慢慢地，通过这种交朋友式的沟通交流，基于对开源项目共同价值的认同，让人与人之间的关系紧密了起来。大家对开源共同体也产生了一定的认同感，会觉得这是我们的项目，而不是某一个人的项目。这样贡献者会投入更多精力进来，项目也会变得更好。”姜宁形容那种感觉，就像创业时找合作伙伴一样，需要通过共同的目标来感召大家。

这个方法颇有效果，Apache ServiceComb 逐步吸引了一些外部贡献者，不到一年时间就从 ASF 孵化器顺利毕业，成为顶级项目。

虽然参与了很多 Apache 项目的开发，但直到从零开始完整运作 Apache ServiceComb 项目之后，姜宁才对孵化流程中的 License 合规有了系统化的、全面的理解。他也更加领悟到了构建开源共同体的重要性，并坚定了向国内更多的开发者传播 Apache 之道的决心。

2021 年， Weex 项目的社区成员不再活跃。没有人提交社区报告，甚至连项目发版时都没有足够的 PMC 成员来进行投票。最终，姜宁结束了 Weex 在 Apache 的孵化，这是第一个在他手上退休的项目。他说感到很遗憾。

姜宁也希望 Weex 能够善始善终。在此之前，已经有多个导师退出了该项目，他是坚持到最后的人。姜宁比以前更从容了，也看得开：“孵化项目失败，我比其他导师经历的事情，也就更多一些。”

随着身份的转变，姜宁对开源的认识也不一样了。

以前，姜宁觉得，开源只是程序员关注的事情，大家把代码相关的所有东西都放在网上，谁都能看到，有兴趣的人还可以参与其中，相互协作，把项目打磨得更好。“它是一种更先进的协作开发方式，给程序员的成长提供了一个很好的空间。”

现在的他认为，开源不单单是技术领域的问题。在把开源的成功经验复制到企业内部的过程中，他发现，要解释清楚开源的运作原理，还涉及了很多社会学、经济学的知识，它有很强的人文属性。“从这个角度来说，我又找到一个新的，可以为之奋斗十年的一个方向。”

开源之路并非坦途一片。正因如此，让姜宁在开源项目孵化方面积累了很多经验：“我们要遵守开源社区的规则和潜规则，开源许可协议是底线。此外，还有很多优秀开源实践，可以帮助我们的项目走得更快，例如上游优先，小步快跑，社区大于代码等。”

02 程序员的乌托邦

在孵化 Apache ServiceComb 的过程中，姜宁意识到，原来通过布道可以影响更多的人。于是在 2018 年及 2019 年，姜宁先后组织了两次国内 ASF 贡献者线下聚会，之后又发起了Apache 北京本地社区，协助成立 Apache 深圳本地社区，将开源爱好者汇聚在一起，做一些有意思的事。

渐渐地，姜宁认识了越来越多的程序员，特殊的角色让他成为了一个观察者，看到了很多困在程序员身上的枷锁。开源布道的责任，就这样在他心里慢慢生长起来。他想，要用自己十几年的开源经历去告诉大家，还可以有另一种选择。

“开源共同体是程序员的乌托邦。”姜宁如此认为。他将“Open Source Community”翻译成开源共同体，而不是开源社区。

“‘社区’一词，容易和居委会，我们居住的社区混在一起。”姜宁解释说，“Open Source Community 既有生产者（开发人员），也有消费者（使用者），大家为了共同的目标（把开源软件打磨得更好）聚在一起，相互协作共同成长。”

ALC 北京成员聚会（2020 年 8月，北京）

他自己就是从开源世界成长起来的，最直接的收获就是技术能力的提升。

令姜宁印象深刻的是，早年学习 ACE，看用户手册，学习架构模式，都是自己一个人，好不容易对它有了基本认识，然而却没人可以交流。接着还要花大量时间读文档，看教程，写代码，进展非常缓慢。然而在全职加入开源项目开发之后，在大牛的无私帮助下，在与用户交流沟通中，通过不断解决开源项目运行的实际问题，他发现，自己的开发水平有了显著地提升。姜宁第一次体会到开源共同体的魔力。

他经常以此鼓励程序员加入开源社区，一步一步跟着项目走，像走阶梯一样，会很扎实地成长起来。“在开源社区，会有很多大神级程序员扮演导师的角色，无条件地把经验传授给年轻的程序员，帮助他们找到技术拓展的空间。”

他反复提到一个词，办公室政治。“在开源社区，程序员只要专心研究技术，而不需要考虑办公室政治。”

“很多程序员都是在晚上写代码。白天在干啥？被拉着开会。”他看到，国内很多企业，项目出问题后，第一时间是开会，说是定位问题，其实往往是在互相甩锅。“踢皮球踢了半天，问题一点没解决。真的感觉是在浪费生命。”

开源社区不是这样。在姜宁眼中，发现问题后，社区成员会主动 debug，不会出现推诿扯皮的情况，而且大家都是通过邮件列表公开交流，目的也都是为了解决同一个问题，所以工作效率很高。

他希望这些企业在开会这件事情上，能向 ASF 的董事会学习一下，会前大家通过异步的方式处理相关的报告，每个月开一次，一次不到一个小时。“把开会的时间省下来，大家会更纯粹一点，把自己手上的事情做好，做精，做尖。长期积累精进之后，效率可能提升十倍，百倍。”

他想，如果大家都具备开源协作的能力，工作效率会提高很多， 996 这种事情也会少很多，程序员的生存状态也能变得更好，会有更多的时间去创新，做一些更有意思的事情。

这支撑着姜宁要当好开源导师，即便他知道，要改变这些事情可能没那么容易。“我没有那么强的能力，但我要告诉大家，在开源社区，你会更自由一些，更高效一些。”

姜宁认为，很多公司低效运作的一个因素，就在于中间管理层。但开源社区是扁平化的，“在这里没有项目经理，只有 Technical Leader”。

大公司需要有中间层来运转，但不代表没有弊病，他很清楚这些。姜宁一层一层看下来，中间层把下面的人做的事，包装起来去维护他自己的位置，消耗了很多资源。做项目，代码还没写，前期规划设计就花了一半的资源，剩下一半，大部分都放在协调沟通上。

姜宁认为：“长期下来，会让人练就另一种能力——包装。在企业，干得好可能还没有说得好。”在开源社区，所有内容都是公开的，把代码写出来，交给用户做验证就可以了，不需要准备精美的材料向上层做汇报，就算要写材料，顶多写一些用户手册、设计文档。

而且，国内做得比较好的开发人员，可能过个三五年，就会转行做管理，“变成大家都讨厌的中间层。”这跟他在国外看到的情况恰恰相反。在 ASF 举办的年度社区会议上，他见到过很多很有技术激情的白胡子老爷爷，让他对程序员的职业生涯有了不一样的认识：“给人感觉就是，程序员这口饭，可以吃很长时间。不像国内，认为 35 岁就不行了。”

姜宁说，更大的问题是，没有长时间的一线编程经验积累，管理层容易脱离开发层，做技术决策的时候，很难一针见血地指出问题。“如果这个人有 20 年的开发经验，他设计出来的框架会很稳定。初级开发人员可以直接在框架基础上进一步修修补补，迭代更新，不会把整个框架推倒从来。”但这样的人在国内很稀缺。

对程序员来说，开源还有一个好处就是，可以长期专注于一个领域，从而沉淀自己的技术能力。姜宁认为这种长期积累是很有必要的。

他提到了具有 15 年历史的 Apache Camel ，从诞生之日起，很多基础架构一直都没变，因为其创始人 James Strachan 把架子搭得很好。他还补充道，这种能力很难靠走捷径把它学过来，而是要长时间的编程经验的积累。

但国内程序员没有多少可供长期从事的项目。“ 我们的项目生命周期可能就是三年，过了三年就会被推倒，换一波人重新写一遍。这么一来，我们只能做一些低水平的重复劳动。 ”这样的情况，姜宁见的不少。而且，大部分代码服务于应用层面，只关注业务实现，没有人关心这些代码是否写得精巧、是否易于扩展，是否易于维护。

“不可能会有积累。”他说。

如姜宁所言，开源项目的代码生命周期会很长，从 1.0 到 2.0，再到 3.0，不断迭代，经过十几二十年，还一直在那儿，正如 Linux 一样。因此，国外程序员专注一个项目十年二十年都是比较常见的。姜宁曾把八年的时间用在了 Apache Camel 项目上，他有一个同事，从 2006 年开始，一直在做 Apache CXF 项目，到现在已经 16 年了。

当然，开源项目也会有推倒重来的时候，但是他认为二者是不同的，这是基于之前积累的经验、知识进行的重构，而不是低水平的重复劳动。

姜宁在很多场合说过，不喜欢码农这个词，那代表了重复，没有创造力。“程序员应该去创造一些没有的东西，比如工具，来提升自己的工作效率，降低自己的开发强度。”

此外，他还站在现实的角度，细数开源能带来的好处。比如在面试时能证明你的技术能力，社区用户帮你测试代码、完善文档，有的还会直接修 bug 打补丁······

03 难以逾越的大山

布道，没有开发那么容易。从进入华为那天起他就知道。

以前，姜宁跟机器打交道，只要利用好网上资源，沉下心来就能学到技术获得成长。但现在不一样，这个新角色，要求他具备更多的软技能，比如演讲能力、表达能力、说服能力，还要去思考如何影响更多人。华为需要懂开源社区的人，而不是参与过某个具体项目的人。

他都走过来了。就连谈起身份的转变，姜宁现在都能笑呵呵说：“哎呀，其实是被逼无奈。”

但面前还有一座难以跨过去的大山。

“观念的转变是最难的。”姜宁说，“很多人只是把开源当成免费的、能让他快速交活的工具。”

他能感受到，国内大部分的开源参与者都是搭便车的心理。把东西拿来用，用的过程出问题了，要么在社区问一下，要么自己埋头修一修，修完了也不回馈上游。“大家不习惯和上游社区进行任何交互，而是把开源项目代码当一个成品，直接拿来用就完了。”

姜宁认为，参与开源要有交朋友的心态。大家是在公开的场合进行协作开发，稍微转变观点可以学到更多，而不仅仅是把开源项目当作完成日常工作的工具，因为那只看到了开源表层的东西。

“开源最大的魅力是可以跟开发者交流，他们会给你带来很多惊喜。你会发现，开源项目居然还能这样用。”做开源项目维护者期间，姜宁最享受的事情就是回邮件。在帮助他人的同时，也加深了他对问题的理解，就像在玩打怪升级的游戏一样。人与人之间互动产生的思想火花的碰撞，会让人成长更快。

在开发 Apache Camel 项目时，只要与他互动的人在北京，姜宁就会想办法跟对方见面。不过最终见面的只有两三个人。他觉得有点奇怪，明明有很多人下载软件，却看不到他们。

他鼓励更多人跟上游交流互动，这是一个深度参与开源的机会。“要勇敢迈出第一步，只要参与进来，会有很多热心的人帮助你。”

Apache Meetup（2018 年 10 月上海）

对姜宁而言，在进行 ASF 项目孵化的时候会比较轻松，因为大部分开发者对开源运作流程有所了解，只要稍微引导就可以。“告诉他们，要公开透明，要用邮件列表交流，再进一步解决流程、合规等问题，最后是社区建设，把门槛降低，鼓励更多人参与进来。这些方面做到位，项目自然就发展起来了。”

但要在公司内部推广开源，姜宁说，太难了。

技术上实施起来并不难，难的是如何让大家主动地参与开源。姜宁看到，虽然已经把代码放在内部公共仓，也鼓励大家把技术用起来，但还是有很多人觉得，自己知道代码的执行细节就行了，不需要告诉别人开发相关的背景和知识。“他没有体会到，公开与代码相关的上下文信息，沟通成本会更低，协作会更容易。”

姜宁说，大量的开发者都没有开源经历，难以理解开源协作是一种怎样的方式。没有实际的体验，大部分人都是机械地按照公司要求来做开源，领导关注事情就能落地，领导不关注的，往往做不到位。如果决策者或者推动者也没有经历过开源，就连沟通开源这件事本身，都可能存在很大阻力。

在很多大公司，跨部门协作也比较难。虽然每个人能力都很强，但各部门都有自己的地盘，人与人之间，就形成了一堵无形的墙。“我不跨过去，你也不要踏进来。得用各种各样的手段才能让各部门协同。”这让姜宁颇为苦恼，因为在开源社区，加入进来的人都有共同目标，所以在做一件事的时候，大家都是尽量相互配合，给予鼓励，而不是设置障碍。

不管是社区开源，还是公司内部开源，遇到的这些难题，归根结底还是观念问题，大家缺乏开放式协作的意识。

“只能一步一步来。”姜宁说。他能想到的解决之道，就是让更多人参与到开源中来。“只要参与到开源社区里面，就会发现，协作是一个很自然的做事方式。你帮我，我帮你，自然而然地，就能把事情做好。到时候就不需要再去改变大家的观念了。”

“但这个过程可能要花很长时间。”他补充说，最好的方式就是，大家直接参与开源项目，边看边学，成长会很快。

04 开源滋养了他

在经历过开源的暗面之后，姜宁仍然能看到开源美好的一面，坚称“开源共同体是程序员的乌托邦”。作为程序员，他真真切切获得过开源的滋养，经历的开源是美好的、轻松的、自由的。

那是 2005 年，姜宁离开国企，进入海纳（IONA）亚太研发中心，参与开发 CXF 项目。一年之后，公司把 CXF 捐赠给了 ASF。作为 Apache CXF 的初始 committer，姜宁很轻松地加入了 ASF。

毫无波澜地，他的开源之旅就这样开始了。“没有人专门给我做培训，就把我扔到社区里面。别人怎么做，我们照着那个样子做，很多时候就是边看边学。我们从公司的 nobody 变成了公司的 somebody。”

在大部分人的眼中，开源都是与“志愿”联系在一起，意味着要占用大量业余时间，且没有收入。而姜宁早期经历的开源却不大一样，他是拿着工资做开源，跟正常上班什么区别。

姜宁说，自己是幸运的，没有经历过做开源还要考虑生计这样的事。他曾在播客中提到：“过去十到十五年，我国开源充满了悲壮的个人英雄主义，大部分开源项目都不赚钱，主要靠情怀。然而光有情怀，很难持续下去。“

真正让他有成就感的，却是另一个项目——Apache Camel。当时，Camel 想集成 CXF，作为 CXF 核心开发者的姜宁，正好也想多参与一些 ASF 项目的开发，于是就开始接触 Camel。

为了成为 Camel 的 Committer，他老老实实地按照 CXF 中的“ Getting Involved ”提示，一边熟悉 ASF 的工作方式，一边不断用提交补丁的方式“骚扰” Camel 项目中的其他 Committer，花了半年时间，最终为自己挣足了信用，在 2008 年初成为了 Committer 。姜宁说，这让他“赢得了大家的认可，再次体验了一下成为 Apache committer 的快乐”。

这一次他经历的开源，跟之前很不一样。用他自己的话说，之前成为 Committer 是占了 CXF 的便宜，因为初始 Committer 不需要走 ASF 的惯用流程。而这一次，是姜宁一步步走过来的，是丰满的，具体的。

在此期间，姜宁结识了 Apache Camel 的创始人 James Strachan。几年后回过头来看，那时国内开源环境并未形成，没有什么可借鉴的开源经验，一切都要靠自己摸索，而 James Strachan 称得上是姜宁的开源引路人。“他真正地扩展了我的视野，带领我去追求新的前沿技术。”多年后，姜宁还在各种公开场合多次提及这位引路人。

也正是在 2008 年，IONA 被 Progress Software 公司收购，北京办公室解散，20 多个员工都找工作去了，姜宁和另一个开发同事作为“善后”的留守人员，继续维护这两个项目。姜宁记得很清楚：“我们当时有 12 个开发人员，分成了两拨。我们两人留下，另外十个人，大部分都去了红帽公司。”

没了办公室，姜宁就在家上班，做的还是那些事儿，只不过，给他发工资的，变成了 Progress Software。两年后，他所在部门从 Process Software 独立，成立了开源创业公司 FuseSource，几年后， FuseSource 被红帽收购，姜宁也就顺势成为了红帽员工，和 IONA 的前同事汇合了。

Apache Camel 这个项目，见证了姜宁完整的成长，从 committer 到项目 maintainer，再到 ASF member。在一则媒体采访的视频中，他回想起收到 ASF 的 member 邀请邮件，填完信息注册表的那一刻，不禁笑了起来：“我好高兴。这相当于 Apache 软件基金会对我的认同。成为 member 之后意味着一件事，就是我可以 mentor 项目。”那是 2011 年 1 月，距离他加入 Camel 开发已近 4 年时间。

2015 年，姜宁从红帽离职，结束了七年专职开源，在家办公的生活。他现在经常怀念那时候——既能自主选择工作时间和内容，又可以照顾家庭。

“我不能保证八小时全情投入，但有五六个小时，肯定是专注的。”上午八点开始工作，中午休息两小时，之后接着工作，一直到下午四点半，这时候姜宁就要去幼儿园接孩子，然后做晚饭。

占用了一个半小时的工作时间，姜宁就在晚上补回来，“晚上八点到十点，在线 2 小时”。尽管白天工作五六个小时，已经基本把重要的事情都处理完了。

妻子周末加班，周四才能休息，姜宁就跟着调整自己的工作计划。“周四出去玩，比周末要好，因为时间错开了，景区也没那么拥挤。”他说着说着，就笑了。

在家能把工作做好，姜宁也备受公司信任。“领导考核看的也是你交的活儿，而不是你具体什么时间在上班。”

这与现在很多中层管理者的做法恰恰相反。“他会特别关注你是不是在摸鱼，如果是在摸鱼，那你肯定有问题，要不然就是工作不饱和，使劲给你加活儿。这就导致大家都没有太多留白的时间。管理者在努力扇鞭子赶着员工往前走，员工就没有时间去想，我下一步要做哪些事情去提高能力。这样大家的能力提升不了，干活的效率也越来越低。”

唯一不足的是，工作和生活分不开。邮件驱动他加班。只要用户邮件一来，姜宁就赶紧回复，已经形成了习惯。然而邮件一直来，一直来，妻子说他，“永远有干不完的活”。

十多年前，姜宁的手机还不能收发电子邮件，直到诺基亚 720 手机出来。姜宁记忆深刻：”全键盘的手机，当时就觉得，哇塞，这个手机好好，终于可以随时随地回邮件了，爽很多。”手机到手后，陪妻子逛街时，他就找个角落，隔几秒就刷一遍收件箱，盯着邮件列表上那些问题，抓自己知道的，随时回复。

有时也会有些小小的孤独。他专注工作，对外的连接并不多，跟别人的语言交流很少，更多的是写邮件，而且很多时候是跟老外交流。“在家时间长了，懂我的人比较少。当时在微博上认识了一票人，周末活动的时候见面，特别开心，可以说好多话。”

总的来说，那几年，能够专心做开源项目，是姜宁非常享受的一段时间，因为工作内容比较单纯，自己的技术能力也在不断增长。

05 履新之后

今年 3 月初，Apache 软件基金会（ASF ）公布了新的董事会成员名单，姜宁名列其中。他说自己曾经是一个佛系的技术宅，然而 ASF 董事这个新身份，却是他主动争取的。20 个候选人竞争上岗，最终只有 9 个人脱颖而出。

这次竞选董事的宣言，姜宁花了很长时间去思考，到底要讲哪些东西。最终出来的稿件，没有什么夸大的言辞，只是把他做过的几件事，以及为什么要做这些事讲了出来。“让大家去相信，我就有这样的能力参与基金会治理。”

唯一一句口号式的句子，是他说，“希望能够帮助 ASF 打破地域、文化、语言的障碍。”多年 ASF 开源项目孵化的经历，给了他说出这句话的底气。这些年，他先后帮助孵化了近 10 个来自中国的 Apache 项目。他深知语言和文化隔阂带来的沟通问题。

一年一度的 ApacheCon 是 Apache 项目开发者相聚一堂的好机会。但 ApacheCon 在北美举办，不是所有人都有机会参加，比如他自己在办理签证时就遇到过一些问题。于是他开始拉着 ALC Beijing 的小伙伴，把 ApacheCon Asia 办了起来；了解到很多人不理解开源文化和 Apache 之道，他发起成立 Apache 本地社区，邀请国内外开源人士一起科普，办活动，做交流，写文章，开播客；随着越来越多国内项目进入 ASF , 语言和文化成为中外开发者交流的一个阻碍，于是，姜宁主动担任起导师和桥梁的角色，减少双方之间的隔阂，让他们更好地了解彼此。