Pion seemingly came out of nowhere to become one of the biggest and most active WebRTC communities. Pion is a Go-based set of WebRTC projects. Golang is an interesting language, but it is not among the most popular programming languages out there, so what is so special about Pion? Why are there so many developers involved in this project? 

To learn more about this project and how it came to be among the most active WebRTC organizations, I interviewed its founder – Sean Dubois. We discuss Sean’s background and how he got started in RTC, so see the interview for his background.  I really wanted to understand why he decided to build a new WebRTC project and why he continues to spend so much of his free time on it.

We have touched on a Pion-based cloud gaming project once here that highlights what is possible with the project.  In this interview I as more about why a developer would choose Pion over the many open source WebRTC projects out there. See the linked outline below for the major topics we cover:

• How did Pion get started?
• “No one would trust a WebRTC implementation by a nobody”
• Pion is a big WebRTC project
  • What is so special about Go?
• Would he choose Go if he started over?
• Does the community need another WebRTC Stack?
  • Why not fork & improve libwebrtc?
• Is Pion better than libwebrtc?
  • Pion for user endpoints?
  • Pion on mobile
  • Does pion do media capture?
  • What doesn’t Pion have?
  • Pion performance
• How is Pion different from the other WebRTC stacks?
• How did you build such a huge community?
• Are you getting paid for this?
• What happens to Pion without Sean?
• Why do you get so excited about WebRTC?
• Why should a developer get involved in open source?
• What’s next for you and Pion?
• How to get involved

 

{“editor”, “chad hart“}

How did Pion get started?

One reason I find Sean interesting is that he is relatively new to Real Time Communications. He didn’t come from the old VoIP world and is among the growing group of WebRTC natives – WebRTC experts who have never known VoIP other than WebRTC. 

Chad: Can you give us a little bit of background on yourself?

Sean: I’m Sean. I’ve been working in the RTC space for, I guess, six or seven years now. I stumbled into it because I went to a startup that was looking for C developers and they didn’t have the budget to hire video people. I was lucky enough that I was cheap and I wanted to learn video, and they were looking for someone. And then I got in. I left that job and just started working on Pion in my free time.

Chad: Why did you decide to work on WebRTC?

Sean: There’s a Slack workspace called video-dev that’s run by Mux and a couple other companies. And it’s just a bunch of video developers discussing stuff. And basically, everyone was like, “I really want to use WebRTC, but I find the software is difficult to use. I don’t want to build libwebrtc. I want to send pre-recorded media instead of just my webcam.” And so, it was this arguing back and forth.

I said, “Someone should just make a WebRTC implementation in Go.” And that’s how it started.

libwebrtc is the VoIP library Google open sourced that kicked off WebRTC in the first place. We’ll talk more about that. We’ll also talk about Go.

Sean:At the same time, there were three other [Pion] developers.. they all left after about a month, and then I just kept going.

Sean has kept going. He did actually have some earrly experience writing Asterisk dial plans of all things at one of his first jobs, so perhaps that helped to expose him to open source RTC. Still, managing PBX extensions in a text doc is a long way way from an end-to-end WebRTC stack.

“No one would trust a WebRTC implementation by a nobody”

We touch on this later, but Sean doesn’t make any income from Pion. So why does he keep going with this project? I found this excerpt illuminating:

Sean: At the very beginning, I got written off a lot, which hurt me a lot. So I actually went to Kranky Geek in 2018, and one of the Google devs was talking. And I was really excited to show off Pion. I just started it – It was deeply tied with my identity. Here’s something I’m proud of. And I went up to him after his talk, and I said, “Hey, I built this thing,” and I forget exactly what he said, but to summarize, he said, “No one would trust a WebRTC implementation by a nobody. They’ll just use libwebrtc.”

Sean: It was this destroying moment, where someone you wanted to talk to for weeks says your thing is garbage, and they didn’t even know about it. So that hurt. I wanted to then refill that void. I wanted to be the person that was approachable and would answer questions; I felt like there was a need for that.

As time has gone on  there’s more great people I’ve found. The three that have meant a lot to me – I’ve gotten Bernard [Aboba],  Tim Panton, and Peter Thatcher [and Lorenzo Miniero]. I’ve talked to all of them one-on-one. They’re people that started in this before me, and they’ve all encouraged me to keep going and stuff like that. So good and bad, but that was something that hurt.

Chad: Well, you can’t argue with your results now. You don’t have the financial backing of Google, or you can’t go and pay Kranky Geek to help promote WebRTC with Google behind that, yet you have the most contributors, more contributors, more popularity, at least on GitHub, versus any other open source project. So that’s extremely commendable.

It seems the true artist cares more about making art than any criticism.

I should note we asked Sean to speak at Kranky Geek in 2019 after Pion jumped out on my  GitHub tracking radar because of the community it had. It turns out a lot of people would trust a WebRTC implementation a nobody – or at least was a nobody.

We will come back to Sean’s motivations, but first let’s do a review of the project itself.

Pion is a big WebRTC project

There is a lot to the Pion project – it covers all the major elements you need in a WebRTC project.  Let’s start with a review of the major repos. Sean starts with TURN since that is where he started, but then we review ion – a complete WebRTC conferencing system – and some others.

Chad can you just give us a quick overview of what Pion is?

Sean: Pion is a pure Go collection of RTC software.

We [first wrote]  a TURN server and client as an API. So instead of standing up a TURN  server that takes ini file, you actually call turnserver.Start in your program, then it has callbacks for authentication or someone connected, or you can record how much bandwidth is being used. So that was the first thing [we wrote].

And then we went and wrote the WebRTC API in Go.

Chad: You started with TURN first?

Sean: It was easier. For TURN, we didn’t need a DTLS implementation. We didn’t need SCTP.

Chad: Did you have it in your head at that point you were going to write the whole stack, or do you just look for something to play with?

Sean: No, I think at the time, we were going to do a startup, and we thought we want to run our own things.  Our backend was tightly coupled with our TURN server. We didn’t have to put the auth[entication] in Redis and stuff like that. So it was, we wanted to do everything “perfectly.”

So we did it, and then we just open-sourced and threw it over the wall.

A TURN server is a good place to start since it is needed in almost every WebRTC implementation. It is not stated, but STUN server functionality is included with all TURN servers. STUN sends an endpoint its public IP address for the majority of us that sits behind NATs and TURN provides a direct relay when that doesn work. (For those of you that are newer to WebRTC, see here for my video on that)

Chad: tell me more about the rest of the stack.

Sean: When TURN was almost done, I then started the WebRTC implementation. It was maybe 10% Go. It used libSRTP, OpenSSL, usrsctp, all the same libraries that Chromium uses via C we used via FFI.

I just iterated on that, and then slowly, people came and they’re like, “Hey, I really want to run it on embedded devices. So I can’t use OpenSSLand stuff like that.” So we just kept iterating.

After about a year into the project, the next big Pion project started called ion. It’s a cluster based RTC system. So instead of running an SFU or a media server and configuring and setting I want this many rooms and stuff like that, you actually have a Docker container for each one of your things  – you have a Docker container for your SFU;  You have a Docker container for your SIP to WebRTC bridge.

That was a project that I was totally unaware of and other developers went and built it. I had my hands in TURN and WebRTC and all this stuff and then a group of developers that started after me just decided to build this thing because they didn’t want low level components. Adam and Terrance and all these other developers wanted a pure Go server.

The Selective Forwarding Unit (SFU) element that helps handle multi-party video conferencing is generally considered to be the hardest part of WebRTC. We cover open source SFU’s all the time on this blog – think Jitsi, Janus, mediasoup, Medooze. What about the SFU in Pion?

Chad: How sophisticated is that SFU piece? Is that a full fledged SFU, that’s equivalent to Janus or Jitsi, Media Soup?

Sean: I think it has all of the constructs you’d expect. It has the congestion control, transport wide congestion control, it has sender and receiver reports. You can do data channels, and they give you a little JavaScript API or a little JavaScript SDK, so you can build channels and join them. It also has clients for native.  They have Android and iOS SDKs that are, I think, through Flutter. And we have a couple of large companies that are using them.

At the end of the day, I can’t take credit for that [ion] project, and I can’t also speak to the roadmap, but I know the companies that use it are the ones that are driving it. So they’re betting their companies on it. So I feel pretty good about it.

Pion provides more of a building block to make an SFU. Sean did share a few projects that include Pion-based SFUs – ion SFU, galene, peercalls.com, and kraken.

Pion has a lot of other repos too. Some ones not mentioned elsewhere in this interview that caught my eye include:

• obs-wormhole – WebRTC broadcasting tools for Open Broadcast Studio
• rtwatch – cowatching using gstreamer with synchronized pause/play controls
• Offline-browser-communication – uses mDNS and pre-set ICE Credentials and DTLS Certificates to connect 2 peers without any signaling server

See all 62 repos (as of publication) here: https://github.com/pion

What is so special about Go?

Pion is a Go project. Outside of Pion, the use of Go in open source WebRTC projects is relatively rare, so why is he so committed to it? In fact, use of Go is still relatively rare – it does not make the top 10 most popular languages on GitHub.

Chad:  Can you help explain what makes Go so special? Why is it inherently better than any other language you could have used?

Sean: I could have written another RTC implementation in C or C++,  [but] there wouldn’t have been any novelty to it. I was also strong in Go at the time. I had multiple jobs before that had used Go.

Ok, so Go makes sense for Sean, but what about everyone else?

Sean: one of the big goals with Pion was to make it accessible to beginners. Not just to be something you can use, but also something that people can come and read and contribute and be part of the community, and Go is designed at Google to be a beginner friendly language. So they bring new grads, and they can contribute to complicated code bases because it doesn’t have all of these… C++ is very complicated. It has multiple generations. C++ looks a little different for every developer.

Go is delightful to deploy. With one command I can build a static binary and copy it to a server. A good example of this is Galene. It just requires one JSON file for config. So I can build a binary for Linux on my mac, and ship it to a Linux server without Go or anything else setup on it.

Another big one is just the safety of the language. I don’t have to worry about buffer overflows. I don’t have to worry about all of these memory issues and leaks and stuff like that. That C and C++ developers have to worry about. So those are the big ones that I think…

Go isn’t the most popular language, but the GitHut 2.0 project (which uses the same public dataset I use in my GitHub WebRTC analysis), does show Go as having the 4th largest annual increase in GitHub pull requests in the fourth quarter of 2020. This is behind of JavaScript, Python, and Java, but ahead of more traditional languages like C and C++.

Still, there are certainly other popular, fast growing languages. Is Go still a good choice?

Would he choose Go if he started over?

Chad: Is there a new language now that’s better than Go, that if you were to start from today, what language would you use today?

Sean: I would still use Go, but I also think that there is 100% validity to every other implementation. If you like Go, you should use the Go implementation. But if you like Rust, you should go use webrtc-rs. If you’re doing an HTTP project, you don’t say, “Oh, what language has the best HTTP library?” You say, “What language do I like?” And then you build on that. So that’s my goal with WebRTC.

Chad: If you are not a Go developer already, should I still care about using Pion? Is it still for me, or should I move on and look at something else?

Sean: I think so. I think the language is incredibly easy to learn. It’s incredibly easy to use. It has a built-in package manager. You can build static binaries. You can build the entire Pion source tree in under a second. Those are the kinds of things… It’s hard to appreciate the productivity improvements until you really dive yourself into it. Because I work on C++ during the day, and I can tell you how much time is lost on all the little paper cuts. And that’s why I like Go.

Does the community need another WebRTC Stack?

There are pros and cons to having diversity in WebRTC stacks. The fact that Chrome, the new Edge, Opera, Brave, Vivaldi, and many other projects are based on libwebrtc dramatically helps in interoperability between those browsers (assuming the same/similar versions). However, it does give greater dependence on that project and the lack of variety could stifle innovation. At the same time, trying to get feature parity with libwebrtc is a tremendous undertaking.  I wanted to understand if one guy starting a new stack is a good idea vs. just forking another WebRTC stack.

Chad: You said earlier, you basically wanted to build something in Go, and you wanted to do WebRTC, but I guess why not just build some wrappers around the existing libwebrtc stuff from Google? Why’d you go out and basically rebuild a WebRTC stack from scratch?

Sean: Pion is dramatically more approachable than the libwebrtc. If you go to build WebRTC, it’s going to take a couple of hours. You’ve got portability issues. Since libwebrtc uses OpenSSL, it’s not going to work in embedded platforms. And it’s also the ownership part. I can’t drive libwebrtc. As an outside developer, I don’t have a voice. So if they decide to dramatically change their API or they… they’re serving their needs. And if that doesn’t line up with mine, where does that leave me? So I don’t want to spend time voicing my opinion if it’s not going to be heard. So that was a big one.

Why not fork & improve libwebrtc?

Chad: Have you tried that? Did you try to voice your opinion – did you go down the route of trying to be a libwebrtc contributor, it didn’t work out, and therefore you went with Go? I guess I’m curious to trade-off there because obviously, this has been a lot of work for you. You could have spent that time on libwebrtc or forked that or done something else. And why’d you go with the Go route instead of that?

Sean: It comes back to the… If I had done the libwebrtc wrapper, I still would have to deal with the security issues. [libwebrtc] had a remote exploit from RTP parsing [1, 2]. They’ve had the SCTP issue. So you have all those issues, which wouldn’t have been fixed. You still have the long build times, you would still have all those things. So at the end of the day, I could do a thin wrapper in Go, but I don’t know how much benefit it would actually provide to the community.

And then again, at the end of the day, it wouldn’t be a community owned project. It would be, let’s just wrap the WebRTC things. There wouldn’t be much there to do.

To be fair, no system is without issues and the more something is used the more it should be checked. Sean did give me this example of one of Pion’s early mistakes that “allows remote attackers to inject arbitrary unencrypted data after handshake completion” due to a DTLS vulnerability. Still, I could see how it might be easier to hunt down bugs and prevent issues in a “fresh” implementation – particularly one than can learn from the mistakes of its predecessors.

Is Pion better than libwebrtc?

Ok, so Pion is different and has a community, but is it better? How does Pion compare to libwebrtc – the main WebRTC project originally open sourced by Google that is the basis for much of the WebRTC world?

Chad: There’s plenty of developers out there who are trying to figure out if they should dive into WebRTC stack and figure out how to build it and go through all that process. There’s a lot of reverse engineering work there. That is certainly not simple, but it is the world’s most popular Voice over IP stack. So can you elaborate a little bit more on how Pion compares to libwebrtc?

Sean: So Pion was born out of frustration of building stuff with WebRTC. With Pion I think the first thing you’ll notice is that it should be the easiest thing to run up and build. We have examples that show things like saving the disk, playing from disc, and building an SFU – all of these things – and you can run them in under five minutes.

It’s all in pure go. So you download it, you go build. It’s a modern environment. That’s super easy to build. There’s no having to deal with different build systems and stuff like that.

So that’s like the first thing you’ll notice.

The second thing is it was designed with the lessons of libwebrtc. libwebrtc is targeted at mobile and desktop. It was built for Chromium. With this 10 years of experience and libwebrtc pain points with building SFU’s and other things – Pion was built in reaction to that.

I’ve worked with a couple of companies that have built SFU’s with libwebrtc. One of them saw that I had a 25 times increase in performance by switching to Pion, just because you spin up all these threads and other things like that. libwebrtc is great for what it was designed to do but bending it to do other things is very painful. Such as bending it to do data channels and stuff like that. So that would be the big overarching theme.

Chad: I guess there are a few parts in that –  you’ve built it around specific use cases like an SFU?

Sean: Not so much. It is designed in building blocks so that you can go do the use cases you care about.

So one of the big things with Pion is this concept of interceptors. So you get a peer connection that has media in and out, and it could be RTP packets, or it could be media. By default it does the basics. It does NACKs, and it does sender and receiver reports. But what you can do is you can turn those off and you can just send stuff – in like a high performance environment – or you can add your own things. Like you can add a congestion controller and read the receiver reports and ramp up the bit rates. Pion does have a getUserMedia implementation as well.

The idea is I don’t force you to do anything. I let you control the entire media pipeline and it’s not like you have to fork and do that.  It’s like a public API that’s well-designed and you can plug and modify as you wish.

Chad: Then compared to libwebrtc, I guess you’re saying that’s meant to go inside Chromium. Therefore it’s not so easy to pull stuff out because [Google] wouldn’t want to do that in Chromium.

Sean: Yeah, so it’s more like, why would you slow down Chromium development to empower developers that are building SFU’s.  It doesn’t make any sense. Why would you add this complexity to Chromium?

These are made for very different things.

I’ve seen a lot of success with libwebrtc where people do one-to-one experiences. So, if you’re uploading a file – like YouTube streaming – they use libwebrtc.  Or if you’re doing game streaming – it’s one-to-one and you want the encoder on the server side to respond. But when you need to have more nuanced control, like playing stuff from disk or doing protocol bridging, I think those fall out of the design of libwebrtc and why it becomes challenging.

To summarize what Sean stated: when compared to libwebrtc  Pion is written in Go, more modular, more transparent to work with, and designed to work outside of Chromium.

Pion for user endpoints?

Does it work for user endpoints? What about mobile?

Pion on mobile

Chad: Okay. I’m also thinking of mobile. I don’t think of Go as a mobile language. How do you play there? How do you play with hardware acceleration and getting access to the encoder / decoder? There’s a lot of work there.

Sean: If someone comes to me and says “I want a mobile experience, and I’m just trying to build a mobile app”,  I would say use flutter-webrtc. What benefit do you have from using Go?

But, I work with a company that does robotics. They want something that’s easy to deploy. They want access to the data channels to be able to control the robot. They want to send media from the robot that’s already encoded by the hardware.

It’s not like we can drop libwebrtc on this embedded device and it just hooks up. Pion makes more sense for them. If your use case directly lines up with something that the creators of libwebrtc are doing, you should go with that.

If your use case doesn’t line up, then you’re probably making the wrong choice.

Chad: How would you describe those use cases?

Sean: I would look at things that Google is shipping today. If your needs line a Duo or Hangouts line or something like that, then yeah, I think it makes sense. You’ll go along for the ride and you’ll get those improvements.

If you don’t line up, then you’re going to be fighting upstream.

Does pion do media capture?

Chad: Okay. You said you do have some options for media capture, but that’s not the real focus. Do you deal with codecs and all that?

Sean: Yes, there is a Pion media devices implementation. So you just call getUserMedia. So we get a lot of people that are doing IoT, home security systems, and stuff like that. They just run the Go code on the Raspberry Pi and other embedded devices.

We see a lot of desktop sharing. We have these companies that are running security systems, so that’s super easy to deploy. It calls into the native API to do that. There’s not really a problem with having the media capture or the hardware acceleration. It’s not different, it’s just that Pion is designed to be more composable so I don’t lock out those use cases.  Forcing people to do all the media libraries when they’re doing something like web torrent – that would blow up all the disc space and the CPU usage and we don’t want that.

What doesn’t Pion have?

Chad: What would you say are some of the big pieces that Pion doesn’t have compared to libwebrtc?

Sean: I think the biggest one is congestion control. So libwebrtc is way better than anyone else. If you follow RMCAT, they’ve pushed the edge with Google congestion control. Then you have Cisco with their implementation [together] with Ericsson.

Pion just has a real basic like receiver report driven congestion controller. And then downstream, ion has implemented their own congestion controller using transport-wide congestion control reports and stuff like that. But that API hasn’t been stable so I don’t want to push that into the project itself. I would say that’s the biggest one today that I think is blocking people. It’s actively being improved.

The other one – there’s still a gap between Pion TURN and coturn.

There are some things like measuring the amount of bandwidth that isn’t built in-tree – we require people to do some glue code and stuff like that.

So those are the two big ones, but neither of those is intractable.

Pion performance

Chad: Are those blockers for people running in production applications? What would you say are some of the bigger blockers there that you see?

Sean: When it comes to scaling, it’s understanding what it’s going to take and how far your application can go. Pion does have some built in load testing and benchmarking tools. But even then it’s so nuanced – like when you explain to people what quality their stream is going to run at?

And then you explain WebRTC uses adaptive bit rate. It’s not just like, you’re not just going to have 300 720P streams and stuff like that. I think that’s the biggest blocker I found for WebRTC adoption today for WebRTC users.

Chad: Have you done a performance comparison on this? Do you have any data you can share?

Sean: Yeah. So there’s an application rtspbench that will show you how to spin up thousands of peer connections. And you can look at the usage. It’s on the repo I did… I forget the size of the box, but you can spin up, I think, 30,000 peer connections. And actually, let me just get the numbers…

So it’s an M42X large, and 15,000 peer connections takes 25% CPU usage.

Chad: And did you do the comparison against libwebrtc, or is that just…

Sean: That’s just Pion itself.

Chad: I’d be really curious, how does it compare against libwebrtc?

Sean: There was a company that built an SFU off of libwebrtc, and that’s where this all came from. They claimed that with libwebrtc, they could only hit 1000 or something because you have all those threads spinning up and all those things.

So you think, yeah, but I guess basically, it’s a 15X performance improvement or something like that? And least for… we’re not going through all the test details. I’ll link to that.

Sean: I think at the end of the day, these things are fun to talk about, but they don’t really reflect on what a real world application looks like. Because your needs could be dramatically different. So you can tune libwebrtc and rip out everything and be like, “Oh look, it runs really well, but it’s missing.” And the same with Pion. I can spin up an application. At the end of the day, don’t just take the marketing of “this thing is better than that”.

No disagreements there.

How is Pion different from the other WebRTC stacks?

Chad: Any other comments on how Pion compares to other projects – like an aiortc or GStreamer?  Where does Pion fit in the ecosystem compared to those? I know you don’t want to beat up on any other project, if somebody is starting out and they need to pick, what are the decision-making criteria in your mind that you see in picking a stack?

Sean: I think the first one is what is the rest of your system built on. If you’re like a really strong Python developer and you really like Python, I think aiortc is the right stack.

That was my goal with Pion. And that’s why I did Pion [for Go developers]. That’s why I did WebRTC for the curious, I wanted to make this stuff more accessible and I wanted people to build their applications. For me, it adds a purpose to this mission making WebRTC more accessible. I am excited to see webrtc-rs, the Rust implementation, because it brings [WebRTC] to a whole another group.

The thing that I would want people to look at the most to convince them to use Pion would be how quick that you can get involved in the community. Go look at GitHub issues and look at how I respond to people. Go look at Slack and see how accessible I am. I don’t think you’re going to get that in most other projects.

I tried to contribute to GStreamer. I contributed the AV1 plugin and I didn’t get the responses that I wanted. I didn’t feel that I was included in the community, so Pion was a reaction to being excluded because I wasn’t an expert I wasn’t recognized. I don’t purposely do that to other people. So no matter who you are, you come in and you don’t have a GitHub avatar, you have no projects uploaded – I don’t care. I believe everyone has a right to get involved and there’s really, really smart people out there who just haven’t had a chance yet. So that’s what I would judge Pion on, because the velocity of Pion is gonna be faster than anything else because of that.

Sean clarified after he has nothing against gStream, it is just a long-standing community he wasn’t able to figure out how to penetrate. That is a good transition to how he tries to make the Pion community different.

How did you build such a huge community?

Unless you have been skimming through this, it is hard to miss that “community” is important to Sean. Compared to other open source projects, he has been able to build a huge community in a short period of time.  I wanted him to explain how he did that.

Chad: Okay. That’s a good segue into the next thing. I’ll talk about the community a bit. And I originally discovered Pion, I do this GitHub popularity contest stuff occasionally, where I go and just do some metrics based on which WebRTC projects are doing best. And I saw Pion show up all of a sudden ahead of everybody else. What is this thing? And it’s probably not so long after that is when we first started talking. How did you do that? How’d you build such a big and active community in a really short period of time out of nowhere. You’re not a known – you didn’t come from Google or anyone of the old VoIP stack companies. So how did you do this?

Sean: With Pion, the first part is anyone who contributes gets a Commit bit, so I think that’s empowering. So if I have someone who shows up, they make a PR that improves RTP marshall performance by 5%, I’d say, that’s awesome. I give them a commit bit. Now that developer can approve another developer and they can completely take me completely out of the loop. So not only do I remove myself from the path of others, but I tell developers, I trust you, I value your judgment, and I let you take part in this project. That was important to me.

Chad: That obviously hasn’t blown up on you too bad.

Sean: No, and I don’t think it will because at the end of the day, I have CI running that you can’t merge code, unless you either keep test coverage where it is or improve it. We’ve got linters running, we’ve got tests running. So I guess my attitude is humans don’t make mistakes, computers make mistakes. So if an issue slips through, we write tooling to catch it.

Chad: So you must have spent a lot of time making that tooling.

Sean: Yeah. Every commit, we spin up Chromium and Firefox and test against it and make sure data channels still work. We are also starting a WebRTC interop project to make sure the Python, the C#, the Rust, and a couple other implementations work every commit. Yeah. I’m just like, automate, automate, automate to take myself out of the loop.

Chad: So you make it really easy for people to commit and actually be co-contributors. What else?

Sean: I value everyone’s opinion, which is really important to me. Because I had been written off when I started off early in the project by other people. And so I felt this stinging rejection from people that I really wanted to like Pion. And in that same sense, I wanted to turn and do the opposite. So I make sure anyone that enters the community, I don’t disregard their opinion. If they contribute some code and it’s messy, I make sure to bring them in because it’s important to me. If I can tell that English isn’t their first language, and it’s difficult for us to communicate, I don’t write people off. It’s just really important for me to not do that. I think that’s a big difference with me and other projects.

One of the statistics that’s my favorite is we have 11 developers who have gotten jobs [through] contributing to Pion.

Pion isn’t just a piece of software, but it’s a way for me to make the WebRTC community better.

 

Are you getting paid for this?

Chad: This must take a tremendous amount of your time. Is anyone paying you to spend this time?

Sean: No, I have not made a single dime, and I don’t ever plan on it. Because I worry that it will, that it will stop me from doing what I think is important. Because I’ll be driven by… Someone pays me and says, “Go do this thing,” but it’s not the most important thing, it will stop me from doing what I think is right. So I push deadlines. I always do what’s right. I like that there’s no business needs that drive Pion. It’s just community owned. I just do what’s right.

Chad: So, really your employers haven’t been involved. You used to work at Amazon, your LinkedIn profile says you work at Apple now. You certainly probably won’t be able to talk about Apple, but you’re really not doing any Pion stuff for these guys?  They don’t care?

Sean: No, I don’t think so. Pion to them is irrelevant. It’s in a language that many people consider not relevant. They consider it a toy language. So that helps. I bring that knowledge back. So the nice thing about being involved in open source is I talk to all these companies. I’m well aware of everything that goes on.

Also, if I represented myself as an Amazon employee to everyone, Amazon competitors aren’t going to talk to me. Since I’m open source, I have free dialogue with everyone. It makes everyone easier.

As mentioned before, Sean is no longer an employee of Amazon and Amazon wasn’t involved with Pion.

Chad: Are there any corporate backers?

Sean: Go ahead and cruise through and aggregate the emails – you can say they’re corporate backers, but there’s no one that gives me money or… It’s all individuals that work at those companies that contribute code.

Chad: Are any of those public?

Sean: I don’t feel comfortable sharing.

Chad: Okay. I’ll take a look and see if I can figure it out from GitHub.

Sean: Yeah. Then it’s fair game. It’s hard… a lot of people ask me what companies are using Pion. It’s a sign of validity, but at the same time, it puts me in danger because if those companies leave Pion. Then all of a sudden it’s a sign of invalidity if they leave.

I’m tempted sometimes to tie my credibility to look, this cool company uses Pion and that proves everything. So it’s this tightrope you walk as an open source project. It’s fun to put the badges, but then by not putting the badges, I’m more worried about the project’s quality and not just who uses it.

I did look into this. GitHub sets up its profiles to represent individuals, not as employees working for an org, but you can glean employer information by cross referencing public bits. However, you can’t tell definitely if a GitHub user is contributing for personal or professional purposes. That being said, I did see a few big tech company names in the list of 43 current public Pion members – Facebook for example. A few robotics companies are in there too. There are many contributors outside of this list though.

Chad: Okay. Do you see that as a benefit or a risk?

Sean: That I don’t have corporate backers?

Chad: It certainly could be a risk – if there’s corporate backers, and somebody has a stake, you’re going to make sure to maintain it and it’s up to date. But the downside of that is the project is going to go in the direction of the corporate backer – what they need, which is not necessarily what the broader community needs. So, how do you manage that?

Sean: I think I don’t want to be driven by the needs of the corporate backers. I’d like [Pion] to outlive whatever a corporate backer thinks is important. If it was deeply embedded at a company, and that company changes its roadmap, Pion dies. But I’d like it to be a project that lives on. I’d rather it become irrelevant because the technology WebRTC is irrelevant, not because the company it’s owned by is irrelevant.

What happens to Pion without Sean?

One risk with open source projects that aren’t backed by companies, is what happens when the community leaders behind the project decide they don’t want to do it anymore, or can’t do it anymore due to some circumstance? Is Pion at risk without Sean championing it?

Chad: what would happen if you got COVID and you were really sick? Let’s say you got really sick, and couldn’t work on the project for say months or something like that. What would happen? What you think would happen  if you couldn’t be involved anymore?

Sean: Technically, it would be fine. We’ve got over 100 people that have commit access. They work on the things that are important to them. In all the subsystems, I think we have people that are smarter than me. In SCTP we have Yutaka who knows it way better than me. The guy who works on… He knows way more about RTP and media sub systems, and he is an expert in this area.

I’m this person that encourages cohesiveness at the higher level. So we’d miss out on that. I think people would have to learn how to work together without me, but that would be the big one.

And then also the outreach. I think I’m the only person that really does any outreach or talks to people or is enthusiastic. But I think someone would step up in that regard, but I think that would be the only part that would be missing.

Why do you get so excited about WebRTC?

Chad: Speaking of enthusiasm, you are very enthusiastic… You are definitely a WebRTC enthusiast. What makes you so excited about WebRTC? Of all the things you could have done with Go and your skills, why did you pick WebRTC? Why do you keep doing it?

Sean: A couple of things. So, why I find WebRTC, the technology, compelling, is it’s a technology that these corporations need. So they need it to do their media servers. They need it to do their conferencing. But at the same time bundle up is this really great peer to peer technology that will let us do things like web torrent, that will let us do things like IPFS. And I love helping those people. And then, so I feel like I get the energy from the people that are making money, and I get to redistribute that energy to the people that are doing the things that I find compelling.

IPFS is the Internet Planetary File System. At first glance I thought of Pied Piper’s decentralized Internet, but I digress…

Sean: Also the interop is great. So, if you look at something like RTMP or SRT or anything else, there’s always one place it won’t work. It won’t work in the browser, or there’s only one implementation. I think WebRTC is great because I can exchange an SDP, and I can have a browser and a server or a browser and another browser talk to each other. So that’s cool.

Sean: Another one is there’s just a vacuum. When I started, the only implementation I was aware of was Lennart’s rawRTC. And then, at the same time, other ones popped up, so gStreamer and aioRTC, but it was a vacuum. You look, and I could’ve done another JSON parsing library, but the world didn’t need it. I felt like at the time, the world needed a WebRTC implementation in Go, and it needed more community ownership. It’s a purpose and a calling. I found that thing that I felt like needed me.

Why should a developer get involved in open source?

Chad: You’ve spent a very significant portion of your life supporting this project, or at least no direct monetization, no direct income and you’re asking other people to do the same. Why? Why should they? Why should a developer take a big chunk of their time and go help out on open source projects versus stuff they do or get paid for.

Sean: I think first it comes down to I find a great deal of happiness that comes with being involved in open source. The number of people you get to interact with.

I’ve made friends in the libwebrtc community. I talked to the other co-creators of SFU, the Lorenzo, and stuff like that. I count them as my friends, you know, we talk about things that interest us and that means a lot to me.

So we’ve built up those life experiences. I got to go to Commcon in London, which I never would have done if I didn’t do this project. Then the people that you could help. I worked with one company that put Pion on these robots that goes out to construction sites and other stuff like that.

By making the software, you’re possibly actually saving people’s lives from injury. Like you’re taking humans out of situations that might be dangerous. And then even selfishly, especially like you should get involved in open source because it is better for you as an individual.

If you just do work inside of a company, like there’s nothing stopping a change in an economic downturn to be laid off. But with Pion, I’ve found that my job opportunities are way greater. Anyone else that gets involved in open source that’s what can happen for you as well.

So I find that I’m happier, I find that my life feels more stable in my career because of it.  There are really no downsides for me. So I would encourage it, then it’s fun and you get better. It’s hard to even itemize all the great things that you discover, the longer you do it, the more benefits you find.

Sean: The other thing I encourage people is go build something that you think is cool and is under your own personal brand and name. Because you’ll upstream the cool stuff to Pion because you’ll be like, “Oh, I found this bug.” But at the same time, you’ll be motivated because it’s your thing that you own. And you have autonomy, and it’s exciting. So I think a lot of people come to me, and they say, “I want to work on Pion.” And I’m like, “You think you want to work on Pion, but you don’t know what it’s like to work on Pion. You got to write tests and it’s slow. It’s not as fun. Go do your own thing.”

Because you get to talk to people. When there’s bugs and accolades, they come my way just because I’ve been doing it for a long time. But go do your own thing, and it’s a way more rewarding experience.

What’s next for you and Pion?

Chad: What do you plan to build next with this?

Sean: Yeah, so right now, the thing I’m working on is a congestion controller. And so right now, the browser is who does the congestion control. So you’ll send the receiver reports and the transport wide congestion control reports that Pion generates. And then it’ll guess the bandwidth. Pion doesn’t have one in-tree, and the IETF hasn’t picked a congestion controller either. So you have Google Congestion Control and SCReAM and NADA, so you have all those out there, and then you have BBR. So I’m playing with that, and I want to get a nice Go library that you give some inputs, and it gives some nice graphs and tells you all that stuff. So I’ve been playing with that. I think that’s the biggest one right now. And yeah, I don’t really have big ones that I want to do.

A thing that I really try to do is make sure that other people own things because it’s better for their career. I don’t want just to soak up all this. I don’t want this to be a vanity project about me. I want everyone to go have their thing. And they’ll say, “Hey, this person is the person that did Pion’s X,” or “This person has this project that’s completely outside of Pion.” That’s my goal. So I try not to… I don’t want to own anything else. I want to contribute to other things, but I want other people to own them.

Sean isn’t just content to add code and coordination for the the open source community either. He also started a WebRTC documentation project. 

Chad: Are you working on non-Go projects too? Or non-Pion projects?

Sean: I have a book called WebRTC for the Curious that I’ve started. It’s just webrtcforthecurious.com. I just wanted to write about the protocols, from an implementer standpoint. So I explain exactly how turn works, exactly how DTLS works, exactly how SCTP works. It’s vendor agnostic, so it has nothing to do with Pion or libwebrtc or anything. It’s just how these things work.

Sean: It also teaches people how to learn. So it gives you the rough summary and then says, go look at the IETF or go look at the W3C to learn more stuff. And yeah, it’s another community project that I want to fill that gap, because I feel like most WebRTC resources are how to you use the WebRTC API. And then you’ve got webrtcHacks, but beyond that, I can’t think of any ungated WebRTC resources that are targeted at the protocols and not just the APIs. So that’s what I’m solving now.

How to get involved

Chad: How do interested developers, or maybe even not interested developers, get involved?

Sean: I would encourage them to go join the Slack channel. We’ve got 1500 developers in there at this point.

Sean: Just go in there, and you can see other people talk about Pion. Either PM me because you’re interested in getting involved and then we also have a Wiki page on contributing.

Chad: Is there anything I should have asked you or that you wanted me to ask you that I didn’t? Or anything you want to say – here’s your chance.

Sean: I guess the big one is I encourage people to come join because there’s a real joy in learning this stuff, and there’s a real joy in the autonomy that you can bring yourself. You can learn the stuff. You can get a great job out of it. You can own your own thing. The great thing about being involved in open source is I freed myself career-wise. So instead of being tied to my job performance at a certain job, I work on Pion, and I love it. And I’m very motivated to do it. And it gave me this mobility to go do what I enjoy.

It’s the best thing I’ve ever done. And I encourage people to get involved in open source because it created my career. I didn’t have a college education. I got into this because of open source. So, if you’re watching this and you feel frustrated in your career or anything, come work on Pion or any open source project. It’s the best thing you can do.

Chad: Thanks so much, Sean. I’ve been doing this WebRTC stuff for a long time and sometimes I feel it’s getting a little long in the teeth.. and perhaps maybe it’s time to look at something else. And I see you and your enthusiasm – it is always contagious.  It helps to keep me going, I hope you keep doing what you’re doing!

I hope this encourages you to join the roughly 10,000 or developers who commit code to WebRTC projects every year! That number has been going up – I should have an update on that at Kranky Geek Spring 2021 in a couple of weeks.

{ 
  “Q&A”:{ 
    “interviewer”:“chad hart“,
    “interviewee”:“Sean Dubois“
  }
}