1. 程式人生 > >Why crypto networks will eat the SaaS industry

Why crypto networks will eat the SaaS industry

Why crypto networks will eat the SaaS industry

This post explores commoditization cycles and models for software delivery by looking at the threat properly incentivized crypto networks pose to the Software-as-a-Service industry. NB — there are plenty of exceptions to the observations made in this post; I do not believe all software will be replaced by distributed systems. This is a very long term thesis, very little of the requisite infrastructure or software exists today.

In 2009 Bitcoin introduced two new economic phenomena to the world, these being digital scarcity and trust-minimized, decentralized computing. These tools are pivotal to the Bitcoin community’s vision for creating digital gold, a sound money that can act as the reserve asset (and perhaps even the transactional currency) for the world’s monetary system. That said, the significance of Bitcoin’s core technological innovations go beyond the creation of a digitally native money, as they have also enabled a new, structurally superior economic model for the software industry (when applied properly). Over the long term, the current system for funding, developing, deploying and maintaining software will undergo a drastic shift towards self-incentivizing networks. This shift will be driven both by factors which previously catalyzed the growth of the Software-as-a-Service model, and by other factors which are idiosyncratic to decentralized networks and crypto-assets.

Just as the growth of SaaS licensing and delivery models have had a dramatic impact on the software industry’s technical and commercial foundations, we see the birth of decentralized computing and digital scarcity as being of comparable significance. What makes this change particularly interesting to us as investors and entrepreneurs is that inherent in this new system is a novel means for value to be captured that does not revolve around profitability or margin extraction, but rather is one that thrives in an environment of competition and commoditization.

Crypto-assets have the potential to solidify the connection between value creation and value capture better than the traditional profit model, which suffers from constant margin decay and diminishing returns. Ironically, a poorly incentivized crypto network has the opposite effect, and to date, most token models fall into the ‘trash’ category.

The Previous Commoditization Cycle: Moving Software into the Cloud

To better understand the potential of this new model, we should first explore why the SaaS model gained so much traction over the past decade. It is no secret that the SaaS revolution has improved the financial standing of the world’s leading software companies. Businesses that previously relied on one-off, cyclical license sales for the majority of their revenue have been able to convince customers to pay them license fees not just once, but every month, quarter or year. The shift to subscription licensing has significantly increased the revenue generated by SaaS companies over the lifetime of a given customer (LTV), and has delivered predictable, recurring revenue growth ripe for compounding. This shift in the software industry’s economic model raises a few interesting questions that shed light on what the next iteration of software economics might look like.

The shift to SaaS and subscription licensing has generally resulted in software consumers paying more to vendors over time for a similar product (△LTV), so are software consumers getting value out of this new deal? If so, how are software companies delivering this value in a profitable manner? The answer lies in the economics of delivering software services in the cloud, and where we are in the commoditization cycle of this business model.

In the legacy world of software consumption (~1990 to ~2010), customers would purchase a perpetual license from a software vendor (a one-off payment), and would likely pay some ongoing fees in order to receive support and software updates. The customer would then implement the software on their own hardware, and manage its operation using internal resources. In the context of enterprise software, this model involved significant capital expenditure on servers and other equipment, and required the customer to employ large in-house IT departments to ensure the smooth operation of their enterprise systems. This model also resulted in the software vendor having to support a range of differing implementations, with customers running different versions of the same product which was often customized for their specific needs. The inefficiencies of this model were:

  1. Limited economies of scale on the client-side when purchasing hardware.
  2. Limited economies of scale on the client-side when employing labour resources to run their hardware and software.
  3. Reduced efficiency on the vendor-side when having to support disparate and customized versions of the same product.

SaaS companies then started to come to market with a new value proposition that went something like this:

‘We can run your software in the cloud, you can fire 70% of your IT staff and stop buying 80% of your hardware. We are going to charge you 50% more over 5 years, but you will save 3 times that by slimming down your internal IT functions. You’ll also gain operational flexibility by having access to your systems from any device anywhere in the world.’

So how were SaaS businesses able to offer such a service and still make money? The answer is simple; economies of scale. Rather than each customer running their own datacenter in the basement of their office, SaaS companies ran customer software on multi-tenanted hardware (ie having multiple customers running on the same server) in much larger, public data centers. Rather than each customer employing their own IT department to ensure the smooth operation of the software, the customer would effectively outsource this function to the software vendor, who would use the same pool of labour to support hundreds or thousands of customer organizations. Rather than having customers run differing or customized versions of the vendor’s software, everyone would run on the same code-base that would be configurable to the customer’s needs but would remain as one multi-tenanted application.

This made supporting customers much more efficient, as bug fixes could be rolled out to everyone simultaneously and customers wouldn’t suffer from problems idiosyncratic to their customized implementation. All these factors reduced the total cost of ownership for software consumers while accruing more revenue to software vendors. Think of it as the industrial revolution of the software industry; efficiency through mass production (h/t Adrian Di Marco).

In many ways the SaaS revolution was a price arbitrage enabled by the increased scale and purchasing power of a software vendor versus an individual software consumer. This arbitrage is evident in all elements of cloud computing; data centers use their purchasing power to get better rates on electricity and use architectural scale to cool servers more efficiently (reducing costs). Thus it is no surprise that the superior economics of SaaS vs on-premise software implementations has resulted in an outstanding victory for the SaaS business model. However, like most price arbitrages, the excess returns diminish over time. Now that SaaS is the standard for new software implementations, all vendors are on an equal playing field. They can no longer compete based on the structural advantage derived from selling a SaaS solution, resulting in more competitive pricing and lower margins over time. This also drives the gradual de-coupling of value creation and value capture as the space becomes crowded.

As Workday, Salesforce, Dropbox and Shopify mature from disruptor status to incumbency, they will face the same vulnerability to a new, structurally superior business model — a vulnerability they once exploited to gain share against SAP, Oracle and all the other incumbents of the previous commoditization cycle. We see self-incentivized, decentralized software systems as having the requisite structural advantages over SaaS needed to catalyze the next cycle of value creation and destruction.

The Structural Advantages of Decentralized Software

One of the key structural advantages of decentralized software systems is that they are open source. This means that any person or corporation can adopt such software without paying license fees. Under the SaaS model, customers pay to license the software and have it hosted and delivered as a service to the end user. SaaS subscription fees account for both the cost of the software and the cost of the service. Separating these two elements mentally will aid one’s understanding of the structural differences between decentralized software and SaaS economics. In the decentralized model, the software is given away for free, meaning the customer only has to pay for service delivery. This means that, all things being equal, the total cost of ownership should be structurally lower under this new model.

The source of this structural advantage is twofold:

  1. Thanks to the novel economics enabled by the creation of digitally scarce currency or tokens (a la bitcoin, ether, filecoin, livepeer), code can be monetized indirectly rather than charging the user directly, reducing cost.
  2. Unlike the SaaS model, service delivery is subject to perfect competition and is subsequently commoditized, reducing cost.

Decentralized software systems replace license fees with digital currencies or tokens that grant rights to use a network or provide services to that network. Developers are free to design the exact mechanics of the token system however they please, and these decisions will be pivotal in determining the ability for the token to capture value and benefit the network, while defining the competitive defensibility of that network. At the most simplistic level, a digitally scarce currency can serve three purposes within a decentralized software system:

  • Provide indirect compensation to the software developers writing the open source code that powers the network (think of this as the license fee element of the SaaS analogy).
  • Facilitate the compensation of network participants who provide services to the network (think of this as the cloud hosting element of the SaaS analogy — compute power, data storage, bandwidth, hardware utilization, service provisioning).
  • Ensure good behavior from all network participants through staking mechanism (this is similar to the SLAs in a SaaS contract).

There is also the possibility for a token to have a role in governance. This makes sense for some systems (ie MakerDAO), but I’m going to put governance to one side for the purpose of this post.

The manner in which developers indirectly capture upside from the growing adoption of their software is specific to the particular design of the token system. Many proposals exist today but few are proven with empirical experience. An easily digestible model looks like this:

  1. Developers create 1,000,000 tokens that confer the right to provide services to a new decentralized file storage network. They sell 800,000 of these tokens to fund the initial development of this network (write the code), and retain 200,000 of the tokens in order to maintain exposure to the future upside of the network.
  2. Once the software is launched, network participants start supplying file storage to the network. The token model of this example dictates that the holders of the token will win new file storage contracts from users in proportion to their share of network token ownership. Therefore if I own 5% of the network’s tokens, I’ll win 5% of new storage deals.
  3. As demand for storage on the network grows, the total fee income payable to the supply side grows, increasing the potential yield of each token (aggregate demand and network fees go up, but token supply doesn’t change). Thus as the total number of consumers paying fees (bitcoin, ether, dai etc) to the network grows, the intrinsic value of the network’s token grows (this example is a work token, ie Filecoin or Keep).

Recall that the developers of the software retained 200,000 tokens, and thus they are capturing the capital growth of these tokens as aggregate demand on the network grows. The token model means that the developers of decentralized systems can afford to give away code for free and can receive indirect compensation for the adoption of that software. This can be thought of as a new paradigm for software monetization, where token economics replace license fees. If we compare this to SaaS economics, decentralized systems are providing access to the software IP at a much lower cost (ie for free), which leaves the service delivery element to be considered.

This is not to say that IPFS/Filecoin is comparable to incumbent SaaS software, but that software development can be funded indirectly, lowering the cost to end consumers. While there are a few examples of distributed infrastructure that may eventually form the basis for application hosting, there are no current examples of open source alternatives to enterprise software built to run on this infrastructure. It is simply far too early.

As we discussed earlier, running software as a service in the cloud was the key source of the economies of scale that gave SaaS disruptors a structural advantage in the marketplace. The advantage was so significant that cloud services attracted rent seeking behavior from market participants. It is worth noting that cloud services are still a high margin business ripe for disruption; in 2017 Amazon made an operating income of $4.1bn, with Amazon Web Services (AWS) contributing $4.3bn to profit while the e-commerce (core) business was loss-making overall. Moreover, SaaS providers are making high margins essentially reselling AWS and similar infrastructure to their customer base, introducing a dynamic where software providers have a monopoly over delivering their software as a service. Decentralized software systems break up this monopoly by separating the role of software provider (those who develop the software) and that of service providers (participants who supply the service element of the network).

What this means in practice is that there is competition amongst network participants that doesn’t exist in the SaaS model. Another benefit is that network participants get global distribution by default, and don’t have to spend any money on sales and marketing. If we go back to the file storage example and compare this to a centralized legacy alternative, network participants compete to offer a commoditized service (file storage) for the lowest possible price. If this can be achieved on the latent capacity of consumer hardware (as this hardware improves over the next decade), or recycled ghost servers that could be deployed in the unused capacity of data centers, this service can be provided at low incremental cost to the host, with easy access to distribution. This will result in lower margins for suppliers and greater economies of scale for the network as lower pricing grows the addressable market. Picture an open source version of the Adobe Creative Cloud (ie cloudGIMP) that leverages decentralized systems for as many services as possible (ie IPFS for file storage and Golem for image rendering) and consider how the total cost of ownership will differ thanks to the de-monopolization of service delivery.

The power of this competition at scale is demonstrated by the exponential growth seen in the Bitcoin network hashrate. Competition amongst miners has driven a monumental increase in hash power, an objective measure of network security (which is arguably the key ‘service’ provided by a network that differentiates itself on decentralization and censorship resistance). Bitcoin mining is clearly a commodity business, and miners have invested hundreds of millions into R&D and billions into capital equipment as part of a hardware arms-race. This investment is necessary in order for miners to survive in a market with almost perfect competition. It should be self-evident that without this competition, the hash rate would be lower, the network would be less secure and the margins generated from bitcoin mining would be higher.

Decentralized networks have the inherent ability to commoditize service delivery by exposing a market to global competition. These networks create an open marketplace with low barriers to entry, where scale producers with the lowest cost of production will gain significant market share. This will likely result in a material decline in the price of the commodity services and infrastructure used in the digital economy. If the correct token economics are employed within a decentralized software system, value can be captured in an environment of perfect competition. Token economics can bind value capture and capital growth to aggregate demand rather than aggregate profit, creating investment opportunities in commoditized services.

The disconnect between margins and value capture is one of the key factors that make these economic systems interesting.

As decentralized, open markets are created for more pieces of the cloud computing stack, it will become harder for traditional SaaS businesses with proprietary software and monopolized service delivery to compete. It stands to reason that as the sophistication of these open markets grow, fewer trade-offs will have to be made when switching to a decentralized architecture. This also follows a similar path to what was experienced during the growth and maturation of SaaS systems, which started off as functionally inferior systems compared to their on-premise counterparts, but have since become capable of serving even the most demanding enterprise customers.

The Longevity of Value Capture in Crypto-Economics

It should be pretty clear how cryptocurrencies and tokens can capture upside early in the adoption curve. How these dynamics play out over the longer term is less clear; as networks mature and the potential upside from future adoption diminishes, how will this impact the viability of these systems? This topic deserves its own segregated discussion which I will save for a later time, but at a high level, the following points should be considered:

  • The impact of network effects on the defensibility of a decentralized system’s incumbency.
  • The agility (or lack thereof) of a decentralized system when implementing software updates (governance, security and safety considerations).
  • The ability of the system to integrate with or otherwise incorporate innovations from adjacent systems (ie the ease of adding layer 2 technologies to the layer 1 protocol).
  • The ability of the system to add value to adjacent systems, creating stickiness through interdependence.
  • Whether the token economics are structured to fund R&D over the long term, allowing the software to stay competitive.
  • The impact that a supporting/related business or community has on the competitiveness on a decentralized system. An example would be where the value-add of a decentralized system is significantly enhanced by services offered by an adjacent business that is committed to (or has an interest in) that decentralized system (and thus to replicate the entire value proposition, one would need to replicate the business as well as forking the system). Many existing software services are high-touch, and a decentralized alternative will require third parties to build a business around providing white glove services to users of decentralized software.
  • The token economics of the system, ie whether they encourage or disincentivize forks.
  • The economies of scale and stickiness of the supply side of a system — especially significant for systems that provision hardware.

The confluence of these factors should significantly impact the sustainability of any decentralized system’s incumbency, allowing long-term value to be captured by the system’s native digital asset.