Simple, Durable, Yours

_{When designing and building software, I take inspiration from tools like this. I've owned one of these watches for years. They're simple and elegant, indestructible, and run for years on a single battery. Sometimes, less is more. (Photo by Adriano Pucciarelli on Unsplash)}

Software today is a total mess. This may be an unpopular opinion, but it’s something that I’m sure of. In fact, it’s probably the thing I believe the most strongly that the greatest number of people would disagree with.

This is true for several reasons. Software today is overly complex. It’s unreliable. It’s slow. There’s hardly any interoperability. It’s too hard to design, build, and maintain. And, of course, software companies spy on us, exploit us, and deceive us. These companies take our data away from us and make it difficult or impossible to get it back or move it somewhere else. They actively and intentionally cripple their software, remove functionality, and make it hard to do what we want, to their benefit (and our expense).

Software is quickly becoming one of the most important technologies in the world for the billions of people that rely on it every day. In this respect, it’s following in the footsteps of the automobile, which became a mainstream technology a hundred years ago. Software has only been in the mainstream for about 30 years, and relative to where it could and someday will be, it’s about as mature today as the automobile was in the fifties. We have a long way to go.

When I suggest that software can and should be much better than it is today people often ask, then why don’t users demand better software? Users today seem pretty happy overall with software from Google, Apple, Facebook, and other tech giants, and they’re not clamoring for open source, self-sovereign, P2P, Web3 alternatives.

While this may be true, I’m confident that in the end the best software will win because software is a tool. We use the best tools we can, and when better tools come along, we use them instead. In order to be useful, tools need to be both durable and customizable. In the early part of the previous century thousands of people bought and drove the Model T because it was the best car available at the time. When better, faster, cheaper, more reliable cars came along, people bought those instead. Over time the same thing will happen with software.

I’m not the only one thinking about how software can be better. Lots of smart people are thinking about this problem, and they’ve come up with things like the New Tech Manifesto and the Can’t Be Evil engineering principles. My own attempt is the Web3 Bill of Rights.

The more I think about it, however, the more I realize that it doesn’t need to be so complicated. Think about the tools you use in your daily life. Think about your refrigerator, your washing machine, your car, that old lamp in the corner. Think about tools large and small: doors and cupboards, hammers and nails, airplanes and buildings. What do they all have in common?

It boils down to three fundamental properties: simplicity, durability, and ownership. What the tools we rely on the most heavily have in common is that they’re all simple, durable, and ours. Software that has all of these properties also satisfies the criteria in the above lists.

Software needs to be simple so that anyone can use it. It needs to be possible to explain what an application does, and its purpose, in just a few words. And a user without any special skills or training needs to be able to figure out how to use an application in a few minutes without an instruction manual. If it’s not simple, then only tech savvy users can use it, which reduces network effects. Software should also be simple to develop so that there’s a huge marketplace and an ecosystem of developers and applications.

Software needs to be durable for the same reason that all tools need to be durable: by definition a tool is something we can rely on, and we shouldn’t have to replace our tools often. We can’t constantly learn or invest in new tools. When I put a screwdriver in a drawer, I know that it will still work in a year. If I don’t start my car for a week or two, I know that it will be fine, and modern automobiles can go hundreds of thousands of miles before breaking down. The same should be true of our software: an application I haven’t run in a year should still just work when I run it again. If I invest a lot of time in customizing an application, or in learning to use it like an expert, I have to know that I’ll be able to use that application indefinitely and that someone won’t suddenly decide to shut it down or change in it a way that removes features that I rely on.

The third property is a bit more nuanced. Software needs to be yours because something that’s not yours is by definition not durable because someone else can take it away from you. But it’s more than this. Software isn’t a simple tool like a screwdriver that you pick up and use from time to time. It’s more like an automobile or, better yet, a home. It’s a place you spend time. Increasingly, we spend more and more time in digital spaces, and these spaces are accordingly more and more important in our lives. What do we humans do to our spaces? We customize them to make them more comfortable, familiar, and livable. We hang art that we like on the wall. We rearrange the furniture. We change the paint color. We expand and reconfigure them. All of this needs to be possible with software as well.

When we look at modern software through this lens, it becomes immediately obvious why most of it fails to meet these criteria. Most of the software we use is not meaningfully ours because it’s controlled by its publisher, not us. It runs on someone else’s servers, not on our devices. The data that lives in the apps we use is not ours. The digital devices we buy and use are not ours. Even software from the most trusted, privacy-conscious publishers spies on us. And most of the software we use is not durable. It’s fragile, constantly breaking, constantly requiring us to update, to re-authenticate. If we’re unlucky, if the publisher of an app is malicious, negligent, or lazy, or if their plans change, an app we rely on may stop working entirely and we’ll have to start over completely. Apps and services get shut down, acquired, and assimilated all the time.

There are a number of approaches to make software meaningfully ours, and to make it durable, such as the approaches taken by the P2P, Web3, and blockchain communities. These approaches are promising since they rely on decentralization, and it’s axiomatic that software that’s durable has to be decentralized in the sense that it doesn’t have a single operator that can shut it down unilaterally. However, these types of software currently have another problem: they’re not simple. It’s currently very difficult to run a blockchain full node, to safely manage a set of private keys, or to access most P2P networks.

How do we get all three properties?

I don’t think anyone has quite figured this out yet, because if they had, we’d all be using their software. Part of the answer is that we need to go much deeper down the software stack than most projects are prepared to go. Managing keys, identities, accounts, and network connections is complicated but it’s not a new problem: operating systems have been doing all of these things for decades. Our access to the software we use is mediated by low-level tools like web browsers, operating systems, and hardware devices. While these tools and devices have become much more powerful and user-friendly in recent years, they’re all tightly coupled to the existing, broken model. As long as the only accounts I can add to my mobile and desktop operating systems are accounts owned by Google, Apple, and the like, software can’t get much better. Without meaningful control over our applications and data, software won’t be durable, and without support baked into the operating system, it won’t be simple.

The only project I’ve found so far that takes this bottom-up approach is Urbit, which reimagines computing all the way down to the layer of the VM and the programming language. Indeed, this post was inspired by a post on the Urbit blog. Urbit is still very limited in what it can do, and it’s far from simple to configure and run, but it’s rapidly getting better and easier, which gives me hope. In time there will be other approaches. Some of them may go even further than Urbit, and reimagine hardware as well as software.

As I continue to envision and work towards better software, software that’s a tool that solves real problems for everyday people, I continue to be inspired by this vision: simple, durable, yours. We’re not there yet, but we will be. Every day we get closer.