Competition is the art of accessing and managing scarce resources to create advantage. Changes in technology shift scarcity, thereby changing the basis of competition. The ‘new competitors’ look different from the ‘old competitors’ largely because what’s scarce now is different from what was scarce before.

Openness adds an interesting dimension to competition. Opening out your organization to uncover latent capacity, making it abundant, shifts the scarcity. Similarly opening out what was previously a scarce resource, makes it a commodity and shifts the basis of competition.

With the rise of Web3, we’re moving into a new era of competitive advantage. Scarcity shifts again, and so does the basis of competition. This essay chalks some initial ideas around this new scarcity and how firms will compete in this new era.

Let’s get started!

Competition follows scarcity

To understand where new scarcity lies, we need to better understand how firms access and manage scarce resources.

Resource based competition

In the industrial era, firms competed on the basis of their access to scarce resources. Scarce resources included access to unique sources of supply (oilfields and mines) or unique intellectual property (Coke’s formula).

A lot of this translates into competitive advantage for digital era firms as well. Google’s search algorithm continues to be protected as a trade secret, a critical resource providing them competitive advantage.

When Airbnb successfully piggybacked Craigslist and pulled Craigslist’s user base to itself, Craigslist lost its scarce resource – the listings created by sellers – to Airbnb. In response, Craigslist started doling out cease and desist letters to any startup that tried to emulate Airbnb’s integration.

Resource-based competition is centered around accessing and managing scarce resources. Accessing scarce resources may involve acquiring new sources of supply or getting access to the best innovators who can create unique intellectual property. Managing these scarce resources then involves creating necessary moats (both structural and legal) to prevent others from accessing it as well as leveraging these scarce resources towards competitive advantage.

Web2: Data as new scarcity

With the rise of the social web, firms identified a new basis of competition: user data. Scarcity shifted away from accessing and managing internal resources only towards accessing and managing user data.

Data harvesting – the efforts of Web2 champions to access user data – took centerstage as firms developed new ways to get users to commit data (Remember LinkedIn’s profile completion progress bar?) while also developing an entire backend industry dedicated to exchanging and transacting data.

To stretch the farming analogy around data harvesting to its uncomfortable limits, Data may be harvested when users ‘sow’ their attention. Hence, competing on data was really competing on attention. Firms invested in behavior design to ‘hook’ users and engage them in cycles of increased data commitment. UX dark patterns emerged to extract data surreptitiously. M&A activity followed suit. While firms in the industrial era acquired competitors with similar or complementary scarce resources, firms in the digital era got busy acquiring similar or complementary pools of user attention and data. Facebook acquired Instagram and WhatsApp and Google acquired Waze, all in a quest to hoard more of the scarce resource.

To manage this scarce resource, firms at first invested heavily in big data processing technologies (2008-2013) and then shifted their focus on creating value using AI and machine learning (2010 onwards).

Centralized platforms, empowered by a lax data protection regulatory regime, competed on this new scarcity. But that landscape is increasingly shifting. The rise of GDPR and other data protection regimes makes data extraction increasingly difficult. The rise of web3 similarly heralds a new era where ecosystems may be organized without centralization and extraction.

The scarcity is shifting again!

 

As I explained in Unbundling the unbundlers, developer engagement is a core value driver in Web3 ecosystems because market infrastructure is no longer built by a central platform business but by developers in the ecosystems building modules complementary to the core protocol. Developer engagement is the primary source of value at the infrastructure layer of Web3 ecosystems. On the developers’ part, this requires commitment of developer time, resources, capabilities etc.

There is another reason why developer engagement is scarce. Developer engagement and resource commitment involves high multihoming costs (costs to developers in simultaneously building for multiple platforms). By building and committing resources to a particular ecosystem, developers are implicitly opting out of committing their limited time and resources to other (competing and non-competing) ecosystems.

Feel Free to Share

Not all developer ecosystems are the same

Managing developer ecosystems was an important consideration for Web2 platforms as well. So how exactly do things change with Web3.

To understand what’s different about Web3 developer ecosystems, we need to revisit the Building Blocks thesis laid out in my earlier newsletters.

In any developer ecosystem, developers perform two key categories of activities: they may contribute to solution development (value creation) or they may create diverse integrations that drive solution usage (value distribution).

 

 

Open source projects primarily rely on developer ecosystems for solution development. The software is then packaged, delivered, and supported through traditional firm-owned channels (e.g. Redhat’s relationship with Linux). This is shown in the top left quadrant.

 

 

Many Web2 platforms engaged developer ecosystems. However, the core platform value proposition was built and delivered by internal developers. Most Web2 platforms relied on developer ecosystems either to create complements to the core platform technology or to set up integrations that drove platform usage. The latter is particularly evident in the case of firms like Stripe and Twilio, which offer API-based capabilities (as-a-service). These firms invest heavily in engaging developer ecosystems, but primarily to drive solution usage (value distribution). This is shown in the bottom right quadrant.

 

 

What’s unique about Web3 ecosystems (and for that matter, any ecosystem that follows the Building Blocks Thesis) is that these ecosystems engage developers both for value creation, through solution development and for value distribution, by driving solution usage. This is shown in the top-right quadrant.

 

 

For instance, Lens Protocol’s developer engagement initiatives span both solution development and solution usage. Similarly, Boson Protocol’s Bug Bounty Program leverages developer engagement on solution development and security, while Boson’s Road to V2 Roadmap scales out developer engagement across solution development and solution usage.

 

Value and defensibility in Web3 ecosystems

As shown above, Web3 ecosystems are unique in that value creation across the entire value chain is driven by developer ecosystems.

Web3 projects need to set up developer engagement programs towards solution development to accrue value into their token. As the solution becomes more comprehensive, the value of the token increases.

Equally important, Web3 projects need to set up developer engagement programs to encourage solution usage through integrations. As the solution gets integrated across a wider number of projects, the defensibility of the solution increases. New competitors forking the code base may replicate the code base but will find it difficult to replicate the myriad integrations set up through a thriving developer engagement program that drive solution usage.

 

 

This is precisely why competitive advantage in Web3 will center around the ability to engage developers.

Thriving developer ecosystems perform two transformative functions.

1. They increase token value (increasing the attractiveness of the project) and attracting even more developers in a self-reinforcing cycle.
2. They increase defensibility (ensuring it becomes more difficult to unseat the associated project).

---

This is part of a series of articles that make up the Web3 Bootstrapping Playbook.

Get the Web3 Builders Playbook