In the software world, SaaS is the air we breathe. It's everywhere, but so are the huge, unresolved problems that come with it. We need solutions, and cryptoeconomics may help us build them.
We all know and love SaaS: the $1-100 per month web apps that do useful things like send emails, stream movies, back up our photos, manage schedules, and so on.
Sometimes SaaS is exactly what customers need. But normally businesses choose to build SaaS because they know it lets them:
- Earn revenue proportional to value by charging for continued usage
- Protect their digital assets from theft by placing them on a secure server
- Simplify service delivery by using a standard browser interface
Those are great things, and without any better alternatives, we will continue to build and buy SaaS (I've done both). Unfortunately, most traditional SaaS products come with serious side effects.
Fragmentation
First, SaaS fragments data for users. SaaS protects digital assets like source code and user data by placing them on a secure server. As a result, each SaaS product tends to create its own data fiefdom, with its own data types and storage technologies. There is no general language which these fiefdoms use to securely and intelligently communicate with each other. That means every SaaS product has incomplete, redundant, and inconsistent versions of customer data.
Sometimes we attempt to fix this by gluing together different SaaS products with software integrations, but this is hard to do correctly. Even worse, the complexity of integrating multiple SaaS products, each with its own quirky API and data types, increases rapidly as the number of systems increases. The high cost of each integration means that most potential integrations are economically unviable.
We've grown accustomed to the balkanization of our own data because SaaS has taught us that there isn't any other way. For example, my wife and I just moved to Palo Alto, and now I need to let the world know that we've changed addresses. Of course the Post Office and Amazon know already, but how many other records in other databases do I need to change? 100? Why isn't it simple for me to update my own address? The truth is that I cannot cleanly update my address, and SaaS creates the same class of problem for every single bit of your data that it stores.
It is self-evident that every person and every business would appreciate a good unified interface to their important data and functionality. But traditional SaaS can't deliver the goods.
Trust
Second, SaaS centralizes data for bad actors, reducing the privacy and security of users. Somewhere in the unread Terms & Conditions of a SaaS product there generally lies a clause like this:
In exchange for your momentary and fleeting access to the Service, you agree to give us all of your data. We'll keep it forever and might sell it to anyone. How would you know, anyway? We promise to keep it secure. Trust us. You don't really have a choice.
The problem is bigger than the perverse incentive for a SaaS provider to abuse customer trust by taking customer data and quietly using it in ways that customers would not expect or approve. SaaS eliminates any structural guarantee that customer data is fairly secure and private. It's easy for me to audit access to the hard drive I am holding in my hand. But when I put my data on your server, it becomes your data, and I cannot audit what you do with it. When a million other customers put their data on the same server, it becomes an attractive target for many kinds of bad actors. We've created an ecosystem where a small number of keys unlock the doors to a lot of valuable data. Is it any wonder that bad actors get the keys?
complexity
Finally, SaaS adds huge amounts of non-essential complexity to support the SaaS business model. Consider a typical SaaS product like a to-do list and scheduler for small businesses. Let's say the target market just needs a good way to make lists or schedules and share them with co-workers. The core functionality to do this might be 2500 lines of code that took a month for a single person to build. But to bring this to market as SaaS, this code must be transformed into a startup replete with:
- People: marketing, sales, operations, management
- Costs: personnel, facilities, legal, contractors
- Systems: cap tables, payment processors, unemployment tax reporting
Maybe the startup will do well and result in a billion-dollar acquisition. More likely, it will self-immolate and in a year or two the customers will move on to another solution. Either way, turning a relatively simple piece of code into a startup increases the stakes and complexity by orders of magnitude.
But fifty years ago, the customer might have solved their scheduling problem with a chalkboard. Even if the SaaS solution is ten times as convenient for the customer, it's easily a thousand times more complex and inflexible than just using a chalkboard. Is this tradeoff truly necessary? Perhaps we are missing big opportunities to create economic value with software defined in units smaller than the SaaS startup.
KICKING THE SAAS HABIT
Traditional SaaS is complex, balkanized, and filled with security and privacy pitfalls, but there is reason to hope. Cryptoeconomics, a novel field of study that combines adversarial game theory, modern encryption, and networks of connected machines, is a promising avenue to explore.
Using the tools of cryptoeconomics like blockchains, peer-to-peer routing, and public-key encryption, we can create protocols that unify data for users and protect digital assets from bad actors. Software providers can use the same protocols to build simpler, more trustworthy units of software functionality, securely deliver them to customers, and receive compensation proportional to the value they create. That's all we need to start building a different kind of software ecosystem.
In short, I suspect that SaaS is not the end game for software.