# 前言

Pion是一个基于Go语言实现的全新的webrtc标准库，只要是webrtc协议涉及的，它全部用Go语言重写，cgo都不带的那种。包括TURN/STUN服务器、DTLS、SDP、ICE、SCTP、DataChannel等等。Pion有着良好的扩展性、较低的维护成本、全平台的兼容性，能有效提高实时音视频从业者的工作效率，能帮助开发者脱离Chromium环境进行WebRTC开发。它是一个Google官方标准的libwebrtc库的强有力的竞争对手和替代品。 笔者也是通过gomobile实现了在Android上运行Pion WebRTC项目，编译一个WebRTC只需要10秒钟，这种开发效率的提升是巨大的。

Pion的第一作者Sean Dubois曾就职于亚马逊和苹果公司，从事音视频方面的工作，其它几十位成员也都各有来头（比如Facebook员工）。

此外，Pion有着活跃的社区和生态，其中ion子项目是基于Pion开发的分布式实时通信系统，它包含了SFU媒体服务器、room房间服务器、signal信令服务器以及多端的SDK等等，分布式架构设计、功能齐全、架构清晰。其中SFU支持单端口模式，解决了像MediaSoup中没去解决的UDP多端口导致的安全问题；它还支持了基于发送的拥塞控制TCC。

目前，已有多家公司基于Pion开发音视频项目（参考awesome-pion），其中100ms.live在2021年获得了450万美元的融资。

本篇文章是webrtcchacks网站的编辑Chad对Pion作者Sean的采访记录。通过本篇文章，你可以了解到原作者和WebRTC的渊源，他是怎么被逼上梁山的，为什么使用Go语言，Pion和libwebrtc的对比，以及Pion的发展现状。

原文地址：webrtchacks.com/how-go-base…，发布于2021年4月6日。

基于Go的Pion库是如何吸引WebRTC爱好者的？ - 和Sean Dubois的Q&A

Pion貌似在不知不觉间已经成为了最大、最活跃的WebRTC社区。Pion是一个基于Go语言的一系列WebRTC工程的集合。Go是一个有趣的语言，但它并不是一个最流行的编程语言，所以Pion的优势在哪里呢？为什么如此多的开发者对这个项目感兴趣？

为了更多地了解这个项目，以及了解它是怎么成为最活跃的WebRTC组织的，我邀请了它的创始人 - Sean Dubois。我们了解到了Sean的背景，以及他是怎么开始聚焦在RTC方向的。我非常想了解他为什么决定持续投入大量的空闲时间来开发一个WebRTC项目。

我们还谈到了一个基于[Pion的云游戏项目](Open Source Cloud Gaming with WebRTC - webrtcHacks)，它体现了Pion项目的各种可能性。通过这次采访，我想更多地了解到，在众多的WebRTC开源项目中，开发者为什么会选择Pion。以下主要是我们聊到的话题：

• Pion项目是怎么启动的？

• “无名小卒写的WebRTC项目是不会有人用的”

• Pion是一个蛮大的WebRTC工程

  • Go有什么优势？

• 如果重开项目是否仍然会选择Go？

• 社区需要其它的WebRTC技术栈实现吗？

  • 为什么不直接fork来改善libwebrtc项目呢？

• Pion是否比libwebrtc好？

  • Pion适用于终端用户吗？

  • Pion在移动端的情况

  • Pion内部会做多媒体处理的事情吗？

  • Pion现在还缺少些什么？

  • Pion的性能表现

• Pion和其它的WebRTC技术栈有什么不同？

• 你是怎么建立这么大规模的社区的？

• 这个项目有没有给你带来收入？

• 如果没有Sean，Pion会是什么样？

• 为什么你对WebRTC这么痴狂？

• 开发者为什么要开源？

• Pion的下一步计划是什么？

• 如何参与到Pion

Pion项目是怎么启动的？

一个我觉得Sean比较有趣的点是他相对来说是一个实时通信领域的新人。他并不是来自传统的VoIP领域，他仅仅是不断壮大的WebRTC生态中的一员——一个WebRTC专家，他对VoIP不甚了解。

Chad：你能讲一点你自身的背景吗？

Sean：我是Sean，我已经在RTC领域工作了大概六七年了。我无意中发现了RTC，因为我去了一家招聘C开发者的初创公司，他们没有预算去招聘音视频人才。我很幸运，那时候我很廉价，很想学音视频，而他们也正在招这样的人。然后我就应聘了。离开了那家公司之后，我就开始在我的空闲时间开发Pion项目。

Chad：为什么你把Pion定位于WebRTC方向？

Sean：有一个叫做video-dev的Slack空间，由Mux和其它几个公司运营。它是一群视频开发者交流的地方。基本上这里每个人都会说“我很想用WebRTC，但发现Google这个开源做的太辣鸡了，太难用了。我不想去编译libwebrtc库，我想去传输自定义的媒体流，而不仅仅是只能从摄像头采集。”因此，这个争论无止无休。

然后我说，“应该得有人用go写一个WebRTC的实现。”然后这个项目就启动了。

libwebrtc库是一个Google开源的VoIP库，用来支持WebRTC。我们接下来会更多地讨论这个库，当然，也会讨论Go语言。

Sean：当时，有另外3位Pion的开发者。一个月后他们都离开了这个项目，我呢还是继续开发。

Sean早些时候在他的第一份工作中有一些Asterisk拨号计划的项目经验，这可能是有助于他接触到开源RTC。不过，在文本中编写PBX扩展程序离端到端的WebRTC技术栈还是有十万八千里的技术沟壑。

“无名小卒写的WebRTC项目不会有人用”

我们稍候再讨论这个问题。但Sean没有从Pion中获得任何收入、那么他为什么要继续这个项目呢？采访过程中的这段摘录很有启发性：

Sean：在最开始，我在这个项目上投入了大量精力，但结果却是让我很受打击。在2018年的时候我去参加了Kranky Geek开发者论坛，其中一个Google的开发正在演讲。我很激动地展示了Pion。它是我写的，它和我的身份息息相关，它是我引以为豪的东西。演讲结束后，我走到他跟前说，“哈喽，看我的这个项目”。具体他说了什么我已经忘记了，大概来说就是，“没人会用一个无名小卒写的WebRTC，他们只会选择用libwebrtc。”

Sean：这对我的打击太大了，几个星期以来都准备着和某个人分享Pion项目，结果人家说你的东西是垃圾，这太伤人了。我被怼的话都说不出来，我很想去解决一下这个问题。我想去成为一个平易近人、能够回答问题的人，这对Pion的发展来说很有必要。

随着时间的推移，我找到了很多的大佬。尤其这3位对我来说意义重大 —— Bernard [Aboba], Tim Panton, Peter Thatcher [and Lorenzo Miniero]。我和他们一一谈过，他们在WebRTC领域比我早，他们鼓励我继续Pion项目。总的来说，好的不好的，一开始我确实是受到些挫折。

Chad：那是过去的事，现在应该对结果满意了吧。即使你没有Google的资金支持，没有像Google那样能付钱给Kranky Geek来做WebRTC的推广，但你有最多的代码贡献者，或者说更多的代码贡献者，更受欢迎，至少在Github上和其它大量的开源项目相比是这样的。所以，这是非常值得称赞的。

真正的艺术家只关心自己的创作，而不是别人的评价。

我要指出的是，在2019年，因为Pion在Github榜单上的杰出表现，我们邀请Sean去Kranky Geek演讲。事实证明，很多人都会信任或者使用这个WebRTC的实现，即便它的开发者是一个“无名小卒”。

youtu.be/BYtNI4esj1I

后面我们会再去了解Sean的项目动机，但首先让我们先来回顾一下Pion项目本身。

Pion是一个蛮大的WebRTC工程

Pion项目囊括了很多内容，它包含了所有WebRTC需要的主要元素。让我们来回顾一下主要的代码仓库。Sean首先从TURN开始（应为他就是从TURN开始开发的），然后回顾了一下ion(一个完整的WebRTC会议系统)，以及其它的一些东西。

Chad: 你能介绍下Pion的大纲吗？

Sean：Pion是纯Go开发的RTC软件集合。

我们首先编写了一个TURN服务和客户端作为API。因此你不需要去搭建一个TURN服务器，而是可以直接在代码中调用turnserver.Start，然后它会有回调，可以用来做身份验证，监听用户连接，或者记录使用了多少带宽。这就是我们写的第一个东西。

然后我们用Go写了一个WebRTC的API。

Chad：你们先从TURN服务开始？

Sean：因为这更容易，对于TURN服务来说，我们不需要DTLS实现，不需要SCTP。

Chad：那时候你脑子里想的是要写WebRTC的整个栈，还是只是找一个好做的先来实践一下？

Sean：不是的，那时我们打算创业，运行一些自己的业务。我们的后端可以和我们的TURN服务紧密结合。我们不必在Redis中增加身份验证之类的东西。总的来说，我们是希望把每个事情都做的完美。

因此我们就这么做了，然后就开源了。

开发TURN服务是个很好的起点，因为几乎每个WebRTC实现都需要它。没有说明的是，所有的TURN服务都会包含STUN服务的功能。STUN用于交换终端位于NAT之后的公网能访问到的IP地址，如果这个链路不通，则会使用TURN做数据转发。

Chad: 聊一聊项目的其它部分。

Sean：TURN做完之后，我们开始做WebRTC的实现。大概有10%的代码是Go写的。它使用到了libSRTP、OpenSSL、usrsctp，所有这些Chromium用到的库都是用C写的，我们使用FFI（Foreign Language Interface）来调用。

之后我们就一直在迭代，慢慢地，有了一人关注到了这个项目，说“哈喽，我很想在嵌入式设备上使用这个项目，因此我不能使用OpenSSL之类的东西，”因此我们就继续迭代。

大概一年之后，下一个重大的Pion项目启动了，它就是ion。它是一个基于集群的RTC系统。因此，你不必去直接运行SFU/媒体服务器、做一些复杂的配置和设置，而是可以直接在Docker容器中运行这些服务。SFU有专门的Docker容器，SIP到WebRTC的桥也可以有专门的Docker容器。

这个项目我了解的不是很多，是其它开发者做的。我着手于TURN服务和WebRTC相关实现，然后其它的后来的开发者决定启动ion项目，因为他们不想要用低级语言或组件来开发服务器，Adam和Terrance以及其它的开发者都想要这么一个纯Go语言的服务器。

用于实现多方会议的SFU通常被认为是WebRTC最难的部分。我们经常会在博客上看到Jitsi、Janus、mediasoup、Medooze等。那Pion的SFU到底怎么样呢？

Chad: Pion的SFU有多复杂？它是一个成熟的SFU吗？相当于Janus、Jitsi、MediaSoup?

Sean: 我认为它具备了你所期望的所有功能。它有拥塞控制，发送端拥塞控制，它有发送端和接收端报告。你可以创建DataChannel，它拥有轻量的JS SDK。而且它对原生客户端也提供了支持，有Android和iOS SDK(通过Flutter实现的)。有几家大公司也正在使用它们。

说到底，由于我不是主要负责ion，所以我不能代表ion项目，也不知道它的具体的roadmap，但我知道一些使用它的公司正在推动这个项目。相当于这些公司在这个项目上押注了，所以我感觉这个项目前景很不错的。

Pion更像是制作SFU的积木。Sean还分享了一些基于Pion的SFU项目——ion SFU、galane、peercalls.com和kraken。

Pion还有大量的其它的仓库，在本地采访中没有提到的一些我关注的工程有：

• obs-wormhole – 用于Open Broadcast Studio的WebRTC广播工具

• rtwatch – 使用gstreamer实现同步的暂停/播放控制

• Offline-browser-communication – 使用mDNS和预先设置的ICE Credentials、DTLS证书来进行端到端通信，而不需要任何信令服务器

Pion · GitHub这里可以看到pion相关的仓库。

Go有什么优势？

Pion是一个Go项目，在Pion之外，开源WebRTC项目中使用Go的情况相对较少，那为什么Pion要使用Go呢？实际上，Go的使用仍然相对较少，它并没进入Github最受欢迎的10种语言的榜单。

Chad: 你可以解释下Go语言的特殊性吗？为什么它比你本来可以使用的其它语言要好?

Sean: 我本来可以用C/C++做另一个RTC实现。但是它不会有任何新奇之处，我当时也很擅长Go，并且用Go做过很多项目。

OK，所以说Go语言对Sean来说是有意义的，那对其它人来说呢？

Sean: Pion的一个大的目标是让初学者可以使用它。它不仅要是一个可以用的东西，还得是要人们能读懂源码、能够贡献代码，并参与到社区中来的，而Google设计的Go是一门对初学者很友好的语言。所以这给Pion带来了毕业生，他们可以为复杂的代码做出贡献。相反，C++非常复杂，可能得有好几倍的难度，并且对每个开发者来说C++都不太一样。

Go很容易部署。只需要一个命令，就可以构建一个静态的二进制文件并把它复制到服务器。Galene就是一个很好的例子，配置只需要一个JSON文件。因此，我可以在mac上为Linux构建一个二进制文件，并将其发送到Linux服务器，而无需Go的参与或其它任何设置。

另一个比较大的问题就是语言的安全性。我不必去担心缓冲区溢出，不必去担心比如内存泄露这些问题。而C和C++开发者则必须要去担心这些事情。

Go不是最流行的开发语言，但在GitHut2.0项目显示，Go在2020年第4季度的Github pull请求年增长率排名第四。这在JavaScript、Python和Java的后面，但在C/C++等传统语言的前面。

不过，还会有其它流行的、快速增长的语言，Go仍然是一个不错的选择吗？

如果重开项目是否仍然会选择Go？

Chad: 现在有没有比Go更好的新语言？如果项目从今天重新开始，你会选择使用什么语言？

Sean：我仍然会使用Go，但我认为其它语言的实现也是100%可以的。喜欢Go，可以用Go的实现；喜欢用Rust，可以用[webrtc-rs](GitHub - webrtc-rs/webrtc: A pure Rust implementation of WebRTC)。如果你在做一个HTTP项目，你不会说“哪种语言有最好的HTTP库？”而是会说“我喜欢什么语言？”然后就用什么语言开发。

Chad：如果我不是一个Go开发者，那我应该使用Pion吗？还是应该去看看别的实现？

Sean：我想应该用Pion。我认为Go这门语言非常容易学，非常容易使用。它有一个内置的包管理器。可以构建静态二进制文件。你可以在一秒钟内构建整个Pion的源码树。在你投入使用前，很难去感受到那种生产力的提高。因为我白天工作使用C++，我能告诉你这浪费了多少时间，这就是我喜欢Go的原因。

社区需要其它技术栈的WebRTC实现吗？

WebRTC栈的多样性有利有弊。Chrome、Edge、Opera、Brave、Vivaldi和其它项目都基于libwebrtc，这极大帮助了这些浏览器之间的互操作性（假设libwebrtc版本相同）。然而，它确实让人们更加依赖该项目，缺乏多样性可能会扼杀创新。同时，尝试与libwebrtc实现功能的一致性也是一个巨大的挑战。我想知道，从0开始一个新的WebRTC栈是否明智，或者fork其它WebRTC栈来使用就可以了？

Chad: 你之前说，你想在Go上开发一些WebRTC相关的东西，但我想为什么不围绕谷歌已有的libwebrtc库做一些Go语言的封装库呢？为什么要重写一个？

Sean：Pion比libwebrtc更容易使用。你想编译WebRTC，需要几个小时。有移植的兼容性问题，由于libwebrtc使用OpenSSL，它在嵌入式平台上无法工作。在所有权这方面，我不能主导libwebrtc。作为外部开发者，我没有发言权。因此，他们有可能会决定大幅改动他们的API，因为libwebrtc是为他们内部自己的需求服务的。但如果这和我想要的不一样，我该怎么办？所以我不想费时间去表达我的意见，这可能不会被他们看见。这是一个大问题。

为什么不直接fork来改善libwebrtc项目呢？

Chad: 你有没有做过尝试？你有去表达自己的观点，有没有尝试去作为一个libwebrtc贡献者，但没有成功，然后转向了Go？我想我会在这方面做出权衡，因为很明显，这对你来说是一项艰巨的工作。你可以选择投入在libwebrtc上，或者fork它的源码，或者做一些其它的事情，为什么会选择Go而不是上面的路线？

Sean：回头来说...如果我做了libwebrtc的封装，我仍然需要处理一些安全问题。libwebrtc有RTP解析的安全漏洞，有SCTP问题。这些问题都是无法被解决的。你仍然有很长的编译时间，这些浪费时间的事情。今天结束，我就能做一个Go版的libwebrtc库的薄薄的封装库，但这能给社区带来多少好处呢。

而且，这么封装出来的项目，也不是一个社区主导的项目，它只是把WebRTC包装起来，没多少事情可做，没太大意义。

公平地说，任何系统都会有问题，用的东西越多，潜在问题就越多。Sean给了我一个例子，说的是Pion早期的一个bug，由于DTLS漏洞，远程攻击者可以在握手完成后注入任意未加密的数据。尽管如此，在全新的实现中，查找错误和防止bug可能会更加容易，尤其是一个从前辈的错误中吸取了教训的实现。

Pion是否比libwebrtc好？

Pion确实比较特别，有一个社区，但它更好吗？和libwebrtc比怎么样？（libwebrtc是Google开源的WebRTC项目，WebRTC生态的基础）

Chad: 有很多开发者犹豫是否应该深入WebRTC栈，弄清如何构建它，以及WebRTC如何完成整个过程。这里面会有很多逆向的工作。这当然是不简单，但它是世界上最流行的音视频协议栈。那么你能详细介绍下Pion和libwebrtc的比较结果吗？

Sean：所以说Pion是诞生在libwebrtc编译的挫折中的。对于Pion，我想你会注意到的第一件事是，它应该是最容易运行和编译的。我们有一些例子，展示了媒体保存到磁盘、从磁盘播放、构建SFU，所有这些事情，你可以在5分钟内完成并运行。

这些工程都是纯Go写的，只需要下载，然后构建，这是一个现代化的环境，非常容易编译。不必处理不同的构建系统之间的事情。这是第一点。

第二点是，它是根据libwebrtc的经验设计的，libwebrtc面向移动端和桌面端，它是为Chromium创建的。凭借10年的经验，libwebrtc有着在构建SFU和其它方面的痛点，Pion就是针对这些而设计的。

我曾经与几家公司合作过，他们已经使用libwebrtc来开发了SFU。这些公司中的一个在把libwebrtc切换成Pion后，有了25倍的性能提升。libwebrtc设计的很好，但用它来做项目是很痛苦的。比如说当你只需要使用它的DataChnnel来做通信的时候。

Chad：我想这其中有几个部分 -- 你是围绕一些特定的用例（比如SFU）来设计的Pion吗？

Sean：不是，Pion是积木一样的设计，你可以用这些积木来实现你自己关心的用例。

Pion的一大特点就是拦截器的概念。你的PeerConnection它会有媒体输入和输出，它可能是RTP包或者媒体流。默认情况下，它会有一些基本的逻辑。比如NACKs，发送和接收报告。有了拦截器，你可以关掉这些功能；你可以发送自定义的数据，比如在高性能环境下；或者添加自己的东西，比如添加一个拥塞控制器，读取接收报告，提高比特率等。Pion也有一个getUserMedia实现。

Pion的设计就是不会强迫做任何事。整个媒体管道都是可以控制的，而不用你去fork，修改代码。它就像一个设计良好的公共API，你可以随心所欲地添加插件或修改。

Chad：那么和libwebrtc相比，我猜你是说，对于Chromium项目，很难把libwebrtc提取出来做定制化开发，因为Google不想你这么干。

Sean：是的，这个事情更像是，Google为什么要放慢Chromium的开发速度，去帮助开发者开发SFU，这毫无意义，为什么要增加Chromium的复杂性呢？

这些都是Pion和libwebrtc非常不一样的地方。

当人们使用libwebrtc进行一对一通信的时候，我看到了libwebrtc的成功。当你在上传一个视频，比如YouTube，他们用的libwebrtc。或者，如果你在做游戏流媒体，它是一对一的，你希望服务器端的编码器对媒体进行编码，也可以用libwebrtc。但当你需要更加细粒度的控制时，比如从磁盘播放内容或者进行协议桥接，这些都不符合libwebrtc的设计，这种情况下使用它就会很困难。

总结一下Sean所说的，与libwebrtc相比，Pion是用Go写的，更模块化，更透明，更适合用于脱离Chromium进行开发工作。

Pion适用于终端用户吗？

Pion适用于终端用户吗？比如移动端支持的怎么样？

Pion在移动端的情况

Chad：我还想到了移动端。我不认为Go是一种适合移动端的开发语言。Go怎么在移动端工作？怎么去调用硬件加速并且访问编解码器？这里面有很多工作要做。

Sean：如果有人说“我想要支持移动端，我只是想做一个移动端APP。”我会说使用Flutter webrtc吧。你使用Go会有什么好处？

但我在一家机器人公司工作。他们想要易于部署。他们想要使用DataChannel来控制机器人。他们想要发送机器人已经通过硬件编码好的音视频。

我不能把libwebrtc库放在在这个嵌入式设备上使用，它不能运行。Pion对于嵌入式设备来说很有意义。如果你的用例对应的端已经有了libwebrtc的实现，那使用libwebrtc就可以了。

如果你的用例和libwebrtc不一致，那使用它就是个错误的选择。

Pion内部会做多媒体处理的事情吗？

Chad: 你说你有一些媒体捕捉的选项，但这不是真正的重点。你会处理编解码之类的事情吗？

Sean：是的，Pion有一个媒体设备相关的实现。你只需要调用getUserMedia。我们有很多人都在做IoT，家庭安全系统之类的事情，他们只是在树莓派或者其它嵌入式设备上运行Go代码。

我看到很多桌面共享的实例。我们有这些运行安全系统的公司，所以部署起来超级容易。它调用本机API来实现这一点。媒体捕获或者硬件加速并没有什么问题。这没什么不同，只是Pion的设计更具组合性，所以我不会限制用例。强制人们去调用不相关的媒体库（比如他们正在做WebTorrent），这会耗尽所有的磁盘空间和CPU使用率，我不希望这样。

Pion现在还缺少些什么？

Chad: 和libwebrtc相比，Pion缺少了什么比较重要的东西？ Sean: 第一个是拥塞控制，libwebrtc的拥塞控制是最好的。如果你关注RMCAT，可以发现他们在GCC算法上已经取得了突破，思科和爱立信也是一样。

Pion仅仅有一个基础的由发送端报文驱动的拥塞控制。在Pion项目的下游，ion基于TCC（transport-wide congestion control）实现了自己的拥塞控制。但这个API还不是稳定版，所以我暂时还不想去推广这个项目。所以我认为拥塞控制是一个最大的阻塞点，但我们正在积极地改进。

另一个大的问题是Pion的TURN服务和coturn存在一些差距。有一些事情，比如测量带宽，并没有在代码中实现，需要用户去写一些胶水代码。

这就是两个比较大的问题，但都不难解决。

Pion的性能表现

Chad：你有没有做过性能对比？有没有数据可以分享？

Sean：有的，有一个rtspbench应用，它能启动上千个PeerConnection。你可以看看它的用法。它在Pion仓库组里。我忘记了它的最大阈值，但我想你可以连接30000个PeerConnection。事实上，来看下数据...15000个PeerConnection只占用了25%的CPU使用率。

Chad：和libwebrtc对比过吗？还是只是...

Sean: 只是Pion自己做的测试。

Chad：我真的很好奇，它和libwebrtc比会怎么样？

Sean：有一个公司使用libwebrtc搭建了SFU服务。他们声称，使用libwebrtc时，它们只能同时启动1000个PeerConnection。

我猜大概是15倍的性能提升。

Sean: 说到底，数据很有趣，但它们并不能真实地反应实际的应用情况。因为你的需求可能截然不同，你会修改libwebrtc并删除一些内容。说到底，我启动一个项目，不仅仅是去看"谁比谁好"这样的广告。

Pion和其它的WebRTC技术栈有什么不同？

Chad：和其它项目相比呢？比如aiortc和GStreamer。和这些相比，Pion在这个生态中处于什么位置？我知道你不想和其它项目对比，但如果有人要选择一个WebRTC方案，你认为决策的标准是什么？

Sean：我认为第一个问题是你的系统的其它部分是用什么做的。如果你是一个资深Python开发者，而且你也喜欢Python，那你可以选择aiortc。

这是我给Pion定的目标。这也是我为什么为Go开发者做了Pion。我想让WebRTC更易用，能用来搭建他们自己的应用。对我来说，这个事情的目的就是让WebRTC更加容易使用。我很高兴看到了Rust实现的webrtc-rs，它把WebRTC带到了其它的群体中。

我想让人们看到的是，你能以多快的速度融入社区，从而说服他们使用Pion。去看看Github上的issue，看看我对他们的问题响应的有多快。去Slack看看，我多有亲和力。我认为你在大多数其它开源项目都得不到这样的支持力度。

我试图给GStreamer贡献代码，我提供了了AV1编解码的插件，但我没有得到想要的回应。我没有感觉到我被那个社区所接纳。所以Pion项目能做的更好，因为我不是一个专家，我没有被认可。我没有用什么眼光看别人。所以不管你是谁，你的Github没有头像，你没有发布过开源项目，这些我都不在乎。我相信每个人都有参与的权利，而且他们真的是一群非常聪明的人，只是没有机会参与那些项目罢了。这就是我的立场，正因为这个Pion比其它任何项目发展的都要快。

Sean后来澄清道，他对gStream并没有什么歧视的意思，只不过这是一个长期存在的社区，想融入太难了。这是一个很好的借鉴，来让Pion社区变得与众不同。

你是怎么建立这么大规模的社区的？

除非你已经读过了这个文章，否则你很难理解社区对Sean的重要性。与其它开源项目相比，他在短期内建立了一个庞大的社区。我想让他解释一下他是怎么做到的。

Chad：我们来谈谈社区。我最初发现Pion，是我偶尔会在Github上做一些人气PK的事情，我会去做一些WebRTC相关项目的指标。我突然发现Pion出现在了所有项目的前面。不久之后，我们开始了沟通。你是怎么做到的？如何在很短的时间凭空建立起一个如此庞大而活跃的社区的？你不是知名大佬，不是来自Google或者任何一家VoIP公司。你是怎么做到的？

Sean: 对于Pion，第一部分是任何人贡献代码都会得到commit鼓励，我认为这是对他们的认可。所以有人参加，他们会提一个PR把RTP marshall的性能提高5%。我会说，这太棒了，我给了他们一点commit鼓励。现在，开发者可以批准另一个开发者，他们完全可以把我从这个“commit”循环中拉出来。因此我不仅抽离出来，还告诉开发者，我相信你，我重视你的判断，我让你成为这个项目的一部分。这对我很重要。

Chad：这种事情看起来对你不会太糟。

Sean：不会，因为一天结束的时候，我有一个CI自动程序运行，你不能合并代码，除非你要么保持测试覆盖率不变，或者改善它。我们有linter在跑着，有测试在跑着。所以我想我的态度是人不会犯错，电脑会犯错。所以如果一个问题漏掉了，我会写工具解决它。

Chad：所以你一定花了很多时间来写这个工具。

Sean：是的，每次有提交，我们都会打开Chromium和Firefox来做测试，确保DataChannel工作正常。我们还会启动一个WebRTC互操作工程，以确保Python、C#、Rust和其它的几个实现在每次提交代码时都能正常工作。所以我就在做自动化，自动化，自动化这样的事情，然后逐渐把我从这个循环中带出来。

Chad：所以你让开发者很容易提交代码，并成为共同的代码贡献者，还有呢？

Sean：我重视每个人的观点，这对我很重要。我确保任何进入社区的人，我不会无视他们的意见。如果他们贡献了代码，而且代码很混乱，我也会把它们带进来，因为这对我很重要。即使我知道英语不是他们的母语，而且我们很难交流，我也不会拒绝他们的代码和意见。我认为这和其它项目有很大的不同。

我最喜欢的数据是，我有11个开发者通过给Pion贡献代码获得了工作。

对我来说，Pion不仅仅是一个软件，它也是让WebRTC社区变得更好的一种方式。

上图是2020年H1，10个WebRTC库的受欢迎情况。

这个项目有没有给你带来收入？

Chad: 这肯定花了你很多时间。有人给你提供报酬吗？

Sean：没有，我一分钱也没赚到，而且也从来没想过。因为我会被驱使...有人给我付报酬会说“帮我实现这个需求”，但它可能不是最重要的事，这会阻碍我去做正确的事。因此，我会推后deadline，因为我要做正确的事。我希望Pion不是由商业需求驱动的，它应该是社区的，是立场正确的。

Chad：所以，你的老板没有参与到这个项目。你曾经在Amazon工作，你的LinkedIn显示你现在在Apple工作。你肯定不能谈论Apple，但你真的不会为你的公司做Pion相关的事情吗？他们不会在意吗？

Sean：不会。Pion对他们来说无关紧要。Go是一种许多人认为不相关的语言，他们认为这是一种玩具语言。所以这很有帮助，我把知识带了回来。因此，参与开源的好处是我与所有这些公司进行了交谈，我很清楚发生的一切。

此外，如果我向所有人展示自己的Amazon的员工的身份，Amazon的竞争对手就不会参与到项目。因为我是开源的，我可以和每个人自由说话，这让每个人都更容易。

如前所述，Sean不再是Amazon的员工，Amazon也没有参与Pion项目。

Chad: 有公司性质的支持者吗？

Sean：有一些公司发的邮件，你可以说他们是公司性质的支持者，但没人给我打钱，也不是说所有这些公司工作的人都会贡献代码。

Chad：有能公开的吗？

Sean：这不太好。

Chad：好吧，我一会看看能否从Github找到答案。

Sean：那行。这很难说出口...很多人问我有哪些公司在用Pion。这是一个Pion有效性的标识。但与此同时，也让Pion处于危险境地，如果这些公司不用Pion了，是不是也会说明Pion不好用？

有时我会忍不住想把Pion的可信度绑定在一起，看这个很酷的公司使用了Pion，这证明了一切。所以就像开源项目在走钢丝。戴上徽章很有趣，但如果没有徽章了呢。我更担心的是项目的质量，而不仅仅是谁在使用它。

我确实查了一下，Github将其个人资料设为代表个人，而不是代表为组织工作的员工，但你可以通过交叉搜索搜集公司信息。然而，你无法确定Github用户是出于个人或者专业目的贡献的代码。话虽如此，但我确实在43位现在的Pion成员名单中看到了几家大型科技公司的名字，比如Facebook，一些机器人公司也在里面。不过，还有很多贡献者不在这个列表里面。

Chad: 你认为这是一种好处还是风险？

Sean：你指的是我没有公司性质的支持者？

Chad：这当然是一个风险，如果有公司的支持者，而且有人持有股份，你要确保它是最新的。但这样做的缺点是，项目将朝着企业支持者的方向发展，他们所需要的，并不一定是更广泛的社区所需要的。那么，你是如何做到的呢？

Sean：我不想被企业支持者所驱使。我希望Pion能比企业支持者认为重要的东西活的更久。如果它深深根植于一家公司，而该公司改变了roadmap，Pion就会死。但我希望这是一个持续性的项目。我宁愿它变得无关紧要，因为WebRTC的技术无关紧要，而不是它所属的公司无关紧要。

如果没有Sean，Pion会是什么样？

没有公司支持的开源项目的一个风险是，当项目背后的社区领导者决定退出的时候，或者由于某些情况放弃的时候，会发生什么？如果没有Sean的支持，Pion会有风险吗？

Chad：如果你得了新冠肺炎，会发生什么？比方说你病的很重，几个月都没能完成项目。会发生什么？如果你不能参与这个项目，会怎么样？

Sean：从技术上来说没什么问题，我们有超过100个人在贡献代码。他们做的事情对他们也很重要。在所有这些子系统中，我认为有人比我更聪明。比如SCTP，我们有比我更了解它的Yutaka。这个家伙他...他对RTP和多媒体子系统有更多的了解，他是这个领域的专家。

我是个在更高层次做鼓励大家创造凝聚力的人。所以会有问题。人们必须要学会在没有我的情况下合作，这将是最重要的一点。

还有就是外展工作。我想我是唯一一个真正做任何外展工作、与人交谈都充满热情的人。有人会在这方面站出来，但我认为这将是唯一缺失的部分。

为什么你对WebRTC这么痴狂？

Chad：说到热情，你非常热情，你绝对是一个WebRTC的爱好者。是什么让你对WebRTC这么痴狂？在使用Go和你的技能可以做的所有事情中，为什么会选择WebRTC？为什么能坚持下去？

Sean：有几件事。我觉得WebRTC之所以引人注目，是因为它是一些公司所需要的技术。他们需要它来做媒体服务器。他们需要它来进行会议。WebRTC是一种非常棒的点对点技术，它可以让我们做像WebTorrent这样的事情，做像IPFS这样的事情。我喜欢帮助那些人。然后，我觉得我从那些赚钱的人那里得到了能量，我们可以把能量重新分配给那些做我觉得有吸引力的事情上。

ps: IPFS是IP文件系统。

Sean: 而且互操作性也很棒。如果你看RTMP或者SRT之类的东西，总有一个地方它们不能工作。它在浏览器中不能工作，或者只有一个实现。我认为WebRTC很好，因为我可以交换SDP，可以让浏览器和服务器，或者浏览器和另一个浏览器互相通信，这很酷。

Sean：开始时，我知道的唯一实现是Lennart的rawRTC。然后，gStreamer和aioRTC也出现了。你看，我本可以做一个新的JSON解析库，但世界并不需要它。我当时觉得，世界需要在go中实现WebRTC，需要更多的社区主权。这是一个目标和使命，我找到了我觉得需要的东西。

开发者为什么要参与开源？

Chad：你的生活中花了大量的时间在支持这个项目，或者至少没有直接的商业化，没有直接的收入，并且要求其他人也这么做。为什么？他们为什么要这么做？为什么开发者要花大量的时间来帮助开源，而不是去做赚钱的事？

Sean：首先，我认为参与开源给我带来了很多乐趣，与你互动的人的数量。我在libwebrtc社区交了朋友，我和SFU的其它共同创作者Lorenzo等人交谈。我把他们当做朋友，你知道，我们谈感兴趣的事情，这对我来说意义重大。

所以我丰富了一些人生体验。我要去伦敦的Commcon,如果我不做这个项目，我永远都不会去。然后是你能帮助别人。我曾与一家公司合作，在机器人上安装Pion，用于建筑工地和其它类似的地方。

通过编写这个软件，你实际上可能是在拯救人们的生命。甚至从自私的角度来说，更应该参与开源，它对你个人来说更好。

如果你只是在一家公司工作，就像没有什么能阻止经济衰退中的变化而被解雇一样。但有了Pion，我发现我的工作机会要多的多。任何其它参与开源的人，应该也是这样的。

所以我发现我更快乐，我发现我的职业生涯中更加稳定。对我来说真的没有坏处。所以我会鼓励它，它很有趣，你会变得更好。很难逐条列出发生的一些大事，你做的越久，发现的好处就越多。

Sean：我鼓励人们做的另一件事就是用你自己的品牌和名字做一些你认为很酷的东西。因为你会把很酷的东西上传到Pion，说"我发现了这个bug"。但同时，你会有动力，这是你自己的东西。你有自主权，这很令人兴奋。所以很多人来找我说“我想研究Pion。”我会说，“你认为你想研究Pion，但你不知道研究Pion是什么感觉。你必须编写测试代码，整个过程很慢。没那么有趣，去做你自己的事情吧。”

去做你自己的事情，这是一种更有益的体验。

Pion的下一步计划是什么？

Chad: 你的下一步计划是什么？

Sean：现在我正在研究拥塞控制。现在，浏览器是负责拥塞控制的一方。你会发送接收端报文和Pion产生的TCC报文。然后会估计出带宽。Pion和IETF都没有一个可选的拥塞控制器，你可以用GCC、SCReAM和NADA，还有BBR。所以我在研究这个，我想写一个很好的Go库，你可以提供一些输入，它会输出一些很好的图表，告诉你所有这些东西。我认为这是目前最大的一件事。是的，我没有想做的大事。

我真正想做的是确保其他人更好的用Pion，更有利他们的职业生涯。我可不想把所有这些都消化掉。我不希望这是一个我的虚荣计划。我希望每个人都去用他们需要的东西，他们会说，“嘿，这个人是Pion X的作者”，或者“这个人有一个Pion之外的项目”。这是我的目标，我想为其它事情做出贡献，希望其他人拥有他们。

Sean不仅满足于为开源社区贡献代码。他还启动了一个WebRTC文档项目。

Chad: 你在做非Go项目？或者Pion以外的项目？

Sean：我有一本WebRTC的书，是为了满足我刚开始的好奇心。webrtcforthecurious.com我想从实现者的角度去写WebRTC协议。所以我解释了TURN是如何工作的，DTLS如何工作的，SCTP如何工作的。它与Pion或libwebrtc或其它任何东西无关。这本书仅仅是讲这些协议的工作原理。

Sean：它还教人们如何学习，它给了你一个粗略的总结，然后说，看看IETF或者W3C来了解更多东西。这就是我填补WebRTC社区空白的另一个项目，因为我觉得大部分WebRTC资源都是关于如何使用WebRTC API的。

如何参与到Pion

Chad: 感兴趣的开发者或者不怎么感兴趣的开发者，是怎么参与到项目中的？

Sean：我会鼓励他们加入Slack频道。目前我们有1500名开发者。

进去之后，你可以看到其它人在讨论Pion。或者你感兴趣可以直接找到，然后我们还有一个Wiki页面。

Chad：有什么我应该问你的，或者你想说的话？

Sean：我想最重要的一点就是鼓励人们加入，因为学习这些东西是一种真正的乐趣，你可以从中找到一份好工作。你可以拥有自己的东西，你会很有动力去做。

我希望这能鼓励你加入每年向WebRTC项目提交代码的大约10000名开发人员队伍之中！这个数字一直在上升——我应该在几个星期后在KrkkyGeeEk Spring 2021更新。

完结！