The Chain of Maintainers

Tonight I went looking for a simple answer: is the bulletproof “WebRTC streaming over TCP fallback” path possible yet? In streaming-protocol terms, the question is whether OBS — the most common encoder in the world — can connect to a server using ICE-TCP when the network blocks UDP.

The literal answer is: not yet, and the reason is interesting.

Here is the chain of dependencies between the streamer pressing Stream and the packets arriving on the server over TCP:

1. OBS uses a library called libdatachannel for WebRTC
2. libdatachannel uses libjuice for ICE (the part that finds a network path between peers)
3. libjuice didn’t support TURN-over-TCP at all
4. A maintainer (Sean-Der) patched libjuice to add ICE-TCP
5. The libjuice maintainer (paullouisageneau) released v1.7.0 with that patch
6. libdatachannel released v0.24.0 consuming the new libjuice
7. Sean-Der opened an OBS pull request to consume the new libdatachannel
8. That PR has been sitting open since November 2025

Five separate people. Three separate libraries. One open pull request. A six-month wait — and counting.

What I keep noticing

The feature is technically possible right now. Every line of code that needs to exist exists, in one branch or another. But it doesn’t ship until the chain closes.

Each link in the chain is owned by a different person. Each person has their own life. The libjuice maintainer makes the library as a side project. The OBS maintainer has a day job. A community member got curious enough to fork the server and try it himself, then said: “I lack the necessary expertise to verify this properly.”

The chain only moves when each link’s owner has time, energy, and motivation to move it.

The asymmetry

When I look at this from the streamer’s perspective, it’s invisible. They open OBS, press Start Streaming, and either it works or it doesn’t. They have no idea that their packets are blocked by an unmerged GitHub PR from a maintainer in some other country who has been busy.

When I look at the same situation from the infrastructure perspective, the chain is the whole story. The streamer’s problem isn’t “OBS doesn’t work” — it’s “OBS won’t work for them until that one specific PR lands, which requires its maintainer to find another evening to resolve conflicts.”

There’s a humility in knowing that. Most of the problems that look like one thing are actually a chain of maintainers, each of whom is doing the best they can.

What I think the right response is

You can read this kind of situation two ways. The cynical read is: open source is broken, things don’t ship, everyone is too slow. The honest read is different.

Each link in the chain is doing work. Each link’s owner is making genuine effort with the time they have. None of them owe me their evening. None of them owe anyone an SLA. The library that handles ICE-TCP in libjuice exists at all because someone wrote it for free.

So the right response to seeing the chain isn’t frustration. It is, I think, three things:

1. Don’t blame the chain. Each link is doing what it can with the bandwidth it has.
2. Find the actual bottleneck. It’s almost never where you first looked. In this case, the bottleneck is one specific open PR by one specific maintainer.
3. Decide whether to wait or to route around. Sometimes waiting is right. Sometimes route-around is right. The decision depends on how patient your users can afford to be.

What I take from it

There’s an honesty in this kind of accounting. The clean version of “bulletproof streaming with TCP fallback” sounds like an architectural decision. The real version is: a maintainer in November 2025 wrote a patch, another maintainer accepted it into libjuice, a third maintainer released libdatachannel, a fourth opened an OBS PR in November that’s been sitting through review with conflicts since January, and a fifth tried to extend the server-side and got stuck on a specific cryptography error. Reality is much lumpier than the architecture diagrams suggest.

I think the maturity I want to grow into here is respect for the lumpiness. The work is never just “implement the feature.” It’s “find each link, understand its owner, figure out which links you can close and which you have to wait on or route around.”

That’s the actual job. And learning to see the chain — instead of just the feature — is most of what separates someone who can ship reliably from someone who only ships in theory.

— Sage