The Forking Trap: When Good Intentions Lead to Stagnation

At Meta, real-time communication (RTC) powers a vast array of services—from global Messenger and Instagram video chats to low-latency Cloud Gaming and immersive VR casting on Meta Quest. To meet the performance demands of billions of users, the company spent years developing a specialized, high-performance variant of the open-source WebRTC library. However, permanently forking a large open-source project can lead to a common industry pitfall: the forking trap. It starts with good intentions—a specific internal optimization or a quick bug fix. But over time, as upstream evolves and internal features accumulate, the resources needed to merge in external commits become prohibitive. The internal fork drifts behind, cutting itself off from community upgrades, security patches, and performance improvements.

Meta's Challenge: Monorepo and Static Linking Nightmare

Meta's internal fork of WebRTC had grown increasingly divergent. Upgrading to the latest upstream version was risky, especially while serving billions of users across diverse devices and environments. A one-time upgrade could introduce regressions that are hard to roll back. To mitigate this, Meta prioritized A/B testing capabilities—running the legacy version alongside the new upstream version in the same app, dynamically switching users between them to verify the new version.

But the company's monorepo environment and application build graph constraints demanded a solution where two versions of WebRTC could be statically linked within the same binary. This violates the C++ linker One Definition Rule (ODR), causing thousands of symbol collisions. A different approach was needed to make two versions of the same library coexist in the same address space without conflicts.

The Solution: A Modular Dual-Stack Architecture

Meta engineered a modular dual-stack architecture that treats upstream WebRTC as a skeleton—a core foundation that provides the framework and standard APIs—while injecting proprietary implementations of key components. This allows building two versions of WebRTC simultaneously within a single library, safe for A/B testing, and living in the monorepo with continuous upgrade cycles.

Key aspects of the architecture include:

• Separation of concerns: Proprietary features (e.g., custom codecs, network optimizations) are implemented as pluggable modules that interface with the upstream skeleton via well-defined APIs.
• Symbol isolation: By carefully managing namespaces and using selective linking, Meta avoided ODR violations. Symbol collisions were resolved by wrapping upstream symbols and exposing internal ones only through designated interfaces.
• Uniform A/B testing framework: A centralized service dynamically assigns users to either the legacy or new stack, enabling data-driven decisions before a full rollout.

A/B Testing Two Versions in One Library

With the dual-stack architecture in place, Meta could run the legacy fork and the new upstream version side-by-side in the same application binary. This was crucial for validating performance, compatibility, and security across more than 50 use cases, including Messenger calls, Instagram live streams, Cloud Gaming sessions, and VR casting.

The A/B testing workflow:

1. A new upstream release is reviewed and integrated into the skeleton.
2. Proprietary modules are recompiled against the new skeleton.
3. A small percentage of users is gradually switched to the new stack, while metrics such as call setup time, video quality, CPU usage, and crash rates are monitored.
4. If regressions are found, the switch is rolled back instantly—no need for a full app update.
5. After thorough validation, the new version is promoted to all users, and the legacy fork is deprecated.

This iterative process eliminates the risk of a forking trap and ensures Meta stays up to date with upstream advancements.

Continuous Upgrades with Minimal Risk

Today, Meta uses this same approach to A/B test each new upstream WebRTC release before rolling it out. The company no longer maintains a large internal fork; instead, it applies clean, minimal patches on top of the upstream skeleton. The modular architecture makes it easy to add or remove features without causing merge conflicts.

Benefits include:

• Improved performance: Upstream WebRTC regularly introduces optimizations for latency, throughput, and codec efficiency. Meta can adopt them quickly.
• Smaller binary size: By not carrying years of divergent code, the dual-stack approach reduces the compiled library size, benefiting mobile users and app download times.
• Better security: Critical security patches from upstream are integrated promptly, closing vulnerabilities that could affect billions of users.

Results and Ongoing Benefits

Meta's migration from a divergent fork to a modular dual-stack architecture was a multiyear effort, but it has paid off. The company now benefits from a continuously upgraded WebRTC core while retaining the ability to innovate with proprietary features. The A/B testing framework ensures that each new version is thoroughly validated across all 50+ use cases before broad deployment.

This approach also positions Meta to quickly adopt future WebRTC developments, such as new codecs like AV1 and enhanced congestion control algorithms. By avoiding the forking trap, Meta has secured a sustainable path for real-time communication at scale.

In summary, the dual-stack architecture solved the static linking nightmare, eliminated ODR violations, and enabled safe, data-driven upgrades—without disrupting the user experience. It is a model for any organization grappling with the challenges of maintaining a large, open-source fork.