Last summer, I wrote an overview of distributed computing projects in which I now believe I got one key point very wrong.
At the time, I believed that a distributed compute project’s core strategy should be to undercut centralized compute providers on price. At the time, I thought developers wouldn’t choose a harder-to-use distributed compute platform unless it was significantly cheaper than its centralized competitors.
I no longer think that price is the most compelling way for distributed compute projects to compete against centralized cloud providers; I now believe that it’s more about beating centralized providers on developer integrity.
Integrity
Like Nick described in a blog post last month, when developers invest their time building apps on a platform, they are trusting the platform to be around and available, and not to turn off access to important APIs and features.
Developers inherently understand that building on closed platforms means taking on the risk that the platform will one day shut down or change its rules. There are 14,600 questions on Stack Overflow mentioning vendor lock-in. Developers are hyper-aware of it.
For the first time ever, blockchains make it possible for developer platforms to be around forever (or as long as a single network node is running), and to do so without there being a single company that can unilaterally make changes to the rules of the platform.
Developers can trust that a distributed compute protocol won’t go away, fall down, lock them in, revoke their access, or become their direct competitor. Developers cannot trust Amazon, Google or Microsoft to promise them the same.
This may not be the first time open developer infrastructure wins over closed infrastructure. Brad argues that the reason why Microsoft missed the web was because they missed building an open source server. In the nineties, developers chose open source Linux over proprietary Microsoft.
What about the developer experience
A small portion of developers may care so much about building apps on high-integrity platforms that they may be willing to forgo the great developer experience they’d get with a centralized cloud provider.
We can see this happening already with the developers choosing to build apps where the core logic runs on Ethereum instead of on a centralized platform. It can be a more challenging experience to build apps on Ethereum because the dev tools and libraries are still new, yet some developers are willing to build on it anyway because they value that Ethereum cannot change its rules on them the way that a centralized platform could.
As a project keeps improving its developer experience over time, its developer market share should grow, the same way that more developers started moving to building on Ethereum as there started to be tools like Truffle and Infura that made it easier to do so.
The core team doesn’t always have to be the ones that make the developer experience better. Sometimes those improvements come from tooling built by the community such as Heroku and Zeit building easier interfaces for deploying to AWS, or Infura and The Graph building easier interfaces for interacting with Ethereum. But still, the same principle applies that as it gets easier to use a computing platform, more developers may use it.
The important bit here is that while distributed compute projects can improve their developer experience until they catch up to the centralized providers, it is potentially impossible for centralized compute providers to improve their integrity to catch up to their distributed competitors. No matter what they do, unless they rebuild their platforms on a decentralized network, they will always have the problem that they are a centralized company running on centrally controlled infrastructure. This is just like how Ethereum may after many years achieve a comparable developer experience to AWS, but AWS cannot catch up with Ethereum on developer integrity because it will always be centrally controlled:
Not just compute!
This strategy may work for other developer services beyond compute. FileCoin may be able to offer more trustworthy storage than S3 ever will. Blockstack may be able to offer more trustworthy hosting than Google App Engine ever will. Similarly, Piccolo for databases, Handshake for certificate authorities, and CacheCash for caching. These are just a few examples but there are many. All of these projects offer more challenging developer experiences today than their centralized competitors, but as they improve over time, more developers may switch over from the lower-integrity centralized solutions:
The Opportunity
Nick calls this the startup-sized integrity gap: what centralized players leave lacking in developer trust is a startup-sized opportunity for a decentralized player to fill.
There seems to be four important pieces to successfully executing this strategy:
The first is to emphasize developer trust and integrity by making the platform governance rules transparent and clear. This transparency around changes and governance seems like a critical piece of cementing trust.
The second piece seems to be time – a project has to stay afloat long enough that it can take years to catch up on the developer experience. There are probably two ingredients to doing this: one is to play in a big enough market so that capturing even a fraction of a percent of the market is meaningful revenue, and the other is to be so capital efficient that even if revenue is low, costs are down enough that the team has runway.
The third is to continuously invest in improving the developer experience, and to almost singularly focus on that rather than branching out and building new products and services. This can be done through efforts in the core team, or by working with the community to develop tools.
The final is to consider that while a project may not need to compete against AWS on developer experience on day one, it probably does want to be leading the curve in developer experience amongst the other distributed compute projects.
Distributed compute platforms, by the nature of being built on crypto, can promise developers a level of integrity that no centralized cloud platform can. That feels like a big opportunity.
“History tells us that centralized wins early, decentralized wins later.” –@BradUSV
— Chris Burniske (@cburniske) February 26, 2019