Defensibility and the Requirement of Ongoing Value

Winter is coming. Or is it almost spring? No one knows, but we do know we’re in a cycle. The crypto cycle unlike astronomical seasons does not turn automatically due to gravity. We need Product Market Fit and traction to get out of this slump. However, finding Product Market Fit isn’t only about creating business traction. It is also about Defensibility.

In case you missed it, one of the largest 0x Relayers, DDEX has decided to fork the 0x protocol causing heated conversations about the nature of defensibility in crypto.

In the article, Tian Li of DDEX explains the reasoning behind this decision. Naturally, this announcement from Ox’s largest platform relayer came as a huge blow to the 0x team, whose thoughtful response is noted here. And they weren’t the only ones shocked by the move. The team at SKALE are big supporters of 0x and believe that they have been a boon to the ecosystem. Whether or not this fork is the case of a disappointed customer or it is an aggressive move to take over market share in a down market, it all boils down to one key point that tech companies in B2B software have been dealing with for decades. Defensibility.

As tech business models evolved over the past few decades so has the challenge of defensibility. Let’s take a minute to look at a brief history of enterprise software and how we’ve evolved to this business model.

On-Prem

Initially, the business model was straightforward — create source code and sell it outright. These ‘On-Premise’ software systems presented themselves as any system that had to be run locally. As a caveat to being run locally, they had glacial development cycles which required huge budgets in order to make adjustments, improvements, and customization tweaks so they could remain relevant. And every five or so years, a new major version was launched by software companies and another wave of consulting spend and feverish work would begin.

This sluggish model of development was used both in the shipping of the original product as well as any customizations needed by businesses to tailor the software for their industry.

Defensibility: At this point in software business models, defensibility was based on creating the best foundational codebase and then following through with the best services ecosystem to assist companies in implementing and customizing the stack.

The Cloud

The second major wave of software was “Cloud Software” or “Software as a Service” (SaaS). With SaaS, a business hosts multiple versions of its software with configuration options for customers to pick from — eliminating the need for customers to host the systems on their own infrastructure.

With this new model came a number of added benefits. For one, buyers of cloud software were provided with upgrades included in the licenses to the software — this allowed customers to immediately access the same versions of software and configuration options as they were rolled out. With this added configuration, businesses no longer had to hire consultants to change the core codebase for them if they wanted to alter the software to better fit their workflow — allowing for much faster development and iteration lifecycles.

With the cloud came software that could be easily configured without the prior pain points of customization that come with On Premise software. Systems were designed to constantly evolve and changes happened seamlessly without requiring a complete restart.

Defensibility: Defensibility in SaaS was based on not just the code but the promise to continually support and improve the code with future features + competitively host the software in the cloud.

Open Source Software

The next wave of business model innovation was Open Source Software (OSS). With OSS, businesses were now giving away what was previously the most critical component of their sales model — their code! Which begged the question — how can a business possibly make money like this? And why would they do it?

The counter-intuitive thing here is that by giving away your code, you actually propel both your product and go-to-market forward. By opening up, you grow your codebase contributors from a few to many (sometimes exponentially so), spark massive awareness, and shift community growth into overdrive. Once the wall comes down and the codebase is publicly auditable, quality skyrockets and the best code is always pushed forward.

In this model, what is sold is not the code, but rather a service whereby you package it up and host it. As a customer, you are effectively licensing the latest (or recent) hardened version with configuration ability, the servers it runs on, and the support of the system. Companies still have all of the same profit motives of any SaaS business, but OSS provides them with greater reach due to larger communities developed around it. In doing so, they also open themselves up to more competitive attacks because the code is not the differentiator and is available to all of their competitors. This obligates businesses to stay more competitive with their differentiated services than typical SaaS platforms in order to gain and keep market share.

Defensibility: With OSS, defensibility is all about providing differentiated service and support on an ongoing basis. The code is not the differentiator but the way you package it, host it, service it, and price it differentiates you from competition. You can also create a moat by gaining clout and growing community by contributing to the codebase and with thought leadership.

Crypto — The Evolving Model

We now find ourselves with an evolved version of Open Source Software — the Crypto model. The major difference that this model brings is that there is typically no central entity with a profit motive. Instead, the value provided by the network is distributed amongst its users in the form of tokens which are utilized to incentivize actions and pay for services from network participants. As the network becomes more valuable to users, the token will also increase in value — this allow for a profitless dynamic where all holders of the token gain individual profit instead of value being aggregated by a single centralized business. Great description here by Chris Dixon.

Such a profit model aligns the incentives of all participants and further magnifies the effects of Open Source community development. Additionally, no one has to “trust” a central party that has a different set of incentives (growth and EBITDA don’t often vibe with a great customer experience).

Defensibility: While this is all great for creating network effects, defensibility becomes even harder. As previously noted, Crypto systems, like their Open Source brethren, have no moat in terms of code once it is released. And because of the immediate profit potential from a successful fork of the software, individuals are frequently trying to fork or replicate the token economics with aggressive network takeover tactics (read Andy Bromberg’s thoughts on it, here).

So, where does defensibility in crypto come from? Is it state stored in the history of the chain and value derived with each transaction? This is critical. However, I think that the key component is that the crypto networks must deliver a similar differentiated value on an ongoing basis that their Open Source enterprise counterparts must provide.

• Code: They must show they are the best “shepherds” in terms of providing ongoing innovation, maintenance, support of the code base. The shepherds must also continue to lead evolution of the code so that it solves the problems of the customers and allows for configuration (detailed more below).
• Network: They must provide the best network — the best community of validators, the best token economics, the best and most reliable performance, greatest security, etc.
• Governance: They must demonstrate that they will be shepherding the best package in terms of governance and evolution of the network.

Ultimately, customers need to see the value in staying with package A because they know it will be better, more secure, more performant, and evolve in the most optimal manner as they continue to access it.

In short, they must create strong communities and educate these communities in their ongoing value, then continually deliver on the promise. If they fail to do this, they face the possibility of being replaced by a copy / fork of their code from customers or competitors.

Where Projects are Falling Short

Even though decentralized networks are “in the cloud”, they feel more like On Premise systems — everyone uses the same version and most networks offer little to no configuration options. The challenge here is that just a small change to a network requires herculean effort both from a governance and tech execution perspective. So we end up with static systems that are one size fits all. And as we noted before, such a dynamic is harmful to any project in this space, leaving them open to subversion by systems with faster development lifecycles that do provide these options to users.

Ethereum is obviously struggling with this now, but is making good progress in addressing the issue. The strategic approach in partnering with other networks and pushing Layer 2 partner solutions forward are great examples of this in action. Efforts are also being apportioned to solving these issues from within with Ethereum 2.0. I believe Ethereum’s ultimate success is going to stem from interoperability with systems that augment functionality outside of its core such as SKALE, Cosmos, Parity, Ox, and others.

Back to the case of 0x. Regardless of whether this fork is a legitimate call to action by a customer or an aggressive market tactic, if 0x wants to retain customers moving forward, they are going to have to continue to add more ongoing value than customers can provide on their own. They are taking a good step in the right direction with their developer community building here with CoinList. And they’re not alone — I’m quite sure other Projects are going to be learning these lessons as the decentralized future continues moving forward.

In the old world, companies began as value providers and matured into value extractors. In Crypto, this is nigh impossible as there is roughly no switching cost for users to transition to any of the forks / copies of the platforms they currently use. In short, defensibility in Crypto is all about providing ongoing value.

With the rapid pace of development in this space, static systems simply won’t survive. It is essential that software be designed with configurability and modularity in mind from day one. To win in this space, you need to be aligned with your users and constantly improving on their feedback.

Enjoy the Holidays!

— -

SKALE’s mission is to make it quick and easy to set up a cost-effective, high-performance sidechain that runs full-state smart contracts. We aim to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization.

Want to learn more? Start here.

Join us on Telegram here.