Web3 network effects: Designing for forkability

Exploring the interplay of composability and forkability in web3 strategy

Composability and forkability are two sides of the Web3 competitive strategy coin. On the face of it, they seem directly opposed.

Composability – the ability for Web3 building blocks to be combined and assembled in different combinations and configurations – enables greater innovation around your protocol, allowing more value to accrue to your protocol as more innovation happens around it.

On the other hand, forkability siphons value away from your protocol by enabling competition with minimal switching costs.

Traditional competitive strategy would recommend that projects embrace composability and design against forkability.

It’s tempting to jump to that conclusion.

Instead, I believe that Web3 platforms need to actively design for both composability and forkability in order to create enduring competitive advantage.

Designing for composability is obvious. Designing for forkability is counter-intuitive.

But that’s where this gets interesting!

Let’s dig in!

Rethinking competitive advantage

Web3 ecosystems are naturally geared towards high competition. Forking is easy and inevitable. A project that validates an opportunity creates an ever growing incentive for competition.

Forking, interoperability, and the possibility of vampire attacks create an entirely new competitive landscape in Web3.

While the innovation possible through composability will drive most of the value accrual to the protocol layer, the competition possible through forkability will fragment this value across multiple competing protocols, preventing outsized value accrual to any single protocol.

Overtly defensive strategies work very well in resource-based competition, where access to scarce resources forms the basis of competition.

Traditional scarcity revolved around asset control (e.g. oil fields) and distribution control (e.g. vertically integrating into a distribution network).

With Web2, what was traditionally scarce (distribution) became abundant, and scarcity shifted to data ownership and harvesting.

In open web3 ecosystems where most, if not all, resources can be replicated (even more so than ever before with forking), applying defensive strategies predicated on scarce resources will likely prove counter-productive.

Web3 communities which disagree with the project’s roadmap can easily fork the project code and shift their liquidity to competing protocols. Vampire attacks enable the financial incentives to do this as well.

Instead, web3 competitive strategy must rely on embracing this lack of scarcity and assuming the inevitability of forking.

The user experience fallacy

In the early days of Web2, software creators who had not yet seen the power of network effects often argued that the best user experience would win. While user experience on traditional products is delivered largely through product design, user experience on platforms is dependent on network effects. Improvements in the user interface and workflow proved insufficient in competing with platforms with well established network effects.

All this seems fairly obvious in hindsight. Except that when strategizing against forking, many Web3 projects still believe that they can outcompete new competitors who fork their code base by delivering a superior user experience that better retains their users or adding features and functionality faster than competing forks.

These moves may work in a few instances but are unlikely to deliver a source of sustainable competitive advantage.

Instead, I believe that actively designing for forkability and embracing new forks back to the parent project will create sustainable competitive advantage for Web3 protocols.

Web3 competitive advantage: Designing for composability

Scalable competitive advantage in Web3 is built through enabling composability and encouraging integrations across a larger ecosystem of partner protocols and applications.

Composability and allowing a larger developer ecosystem to innovate on top of your protocol enables this competitive advantage. The more the value built on top of the protocol (complements to the protocol), the greater the value in using the protocol. The larger the value created through integrations the more difficult is it for a new fork to replicate the value proposition of the original protocol. To dig deeper here, check out my essay on developer ecosystems.

Web2 banking-as-a-service (BAAS) platforms illustrate the value of integrations. BAAS platforms integrate with financial services APIs on the supply side and a wide range of fintechs and ecommerce APIs on the demand side. Replicating this requires significant investment. Integrations are built one by one and require investment and effort.

To insure against forking, ensure composability of your assets. Encourage usage of your assets across other top projects, such that your assets are critical drivers of network effects on other top projects. If usage of your protocol drives value across a larger partner ecosystem and contributes to their individual network effects, these partner projects have higher incentive to keep co-innovating. Conversely, if partner integrations create greater value for your protocol users, their incentive to switch to a fork is minimized.

Integrations and partnerships also provide further insurance against forking. A protocol with a large number of integrations and partnerships in place can organize innovation across its partner ecosystem to rapidly co-innvoate new propositions and  integrations across multiple protocols to compete with the fork. Unilateral innovation may not scale against an ever increasing number of forks but organising a larger ecosystem to co-innovate affords a more compelling response to new forks.

As an example, Boson Protocol engages in integrations across a diverse range of Web3 gaming worlds to drive greater innovation around the protocol and encourage adoption of the core protocol for transactions in these worlds.

Web3 provides a unique opportunity to strategize for composability not just at the level of protocols and ecosystems but also at the level of investment funds. Today’s most prominent Web3 funds – a16z, Outlier, and others – increasingly invest across a larger composable stack and encourage greater integrations and interoperability across investee companies, driving higher value creation for the overall fund.

For a deep-dive on composability, get your own copy of the fully illustrated Building Blocks Thesis.

Download The Building Block Thesis