Protocols and competitive advantage: Winning in open and decentralized ecosystems
How to compete when users have zero switching costs and all code is forkable
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 protocols, we're moving into a new era of competitive advantage. Scarcity shifts again, and so does the basis of competition. This essay (part of our recently launched Web3 builders playbook) 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 protocols similarly heralds a new era where ecosystems may be organized without centralization and extraction.
The scarcity is shifting again!
Protocols: Tracing the new new scarcity
The rise of protocols changes a lot of assumptions on scarcity. Data is portable and no longer a basis for competition. Users may switch services easily and user attention and data may no longer be accessed, harvested, and managed the way it was in the platform world.
The open ecosystems of protocols also erode the vertical integration advantages that BigTech platforms benefited from. For instance, the competition for user interfaces (and hence user attention) will increase with protocols as user interfaces get unbundled from the underlying platforms. Marketplace platforms vertically integrated into the search interface, guaranteeing a monopoly across both. Protocols that manage market transactions will likely support many search agents, as I explained earlier.
For instance, a marketplace like Ebay bundles seller onboarding, seller analytics, buyer onboarding, buyer decision support, search functionalities, and exchange infrastructure. All these components will be unbundled in a Web3 world.
As a result, we move away from central market-maker architectures to decentralised agent-based architectures, all coordinated by a shared, common protocol. Think Hollywood-style talent markets minus the relationship-based gatekeeping.
So where then will the new scarcity lie?
Developer engagement will be the new scarcity in an era of open ecosystems.
As I explained in Unbundling the unbundlers, developer engagement is a core value driver in protocol-based 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 protocol-based 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.
If you’re enjoying this post so far, go ahead and share it with others:
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 protocol 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 platforms engaged developer ecosystems. However, the core platform value proposition was built and delivered by internal developers. Most 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.
They increase token value (increasing the attractiveness of the project) and attracting even more developers in a self-reinforcing cycle.
They increase defensibility (ensuring it becomes more difficult to unseat the associated project).
This is part of a series of articles included in our recently launched Web3 Bootstrapping Playbook. Get your copy now:
Disclosure: I am an advisor to Boson Protocol.