Bitcoin is an amazing technology with an insane potential. But there are four things that must appear for that potential to materialize. This is the first in a series of four articles, where we address usability.
Bitcoin has been quoted as being to legal tender what BitTorrent was to the copyright monopoly. I believe it has that potential. But it is far from there today. The wild rally in Bitcoin value, the way I see it, is speculation that the potential will materialize. But I will draw on 25 years’ professional experience in software development here and add a few opinions about probable blind spots in the project.
This is an article in a series on what Falkvinge identifies as Bitcoin’s four hurdles, which will be followed by a series on Bitcoin’s four drivers. This is the first article on usability. The others are transactions, escrow, and exchanges.
The current developers are, I believe, very technically skilled. And that is also their Achilles’ heel. A person who is great at making complex logic work flawlessly is never great at making that logic easy to use and understand. It’s two completely different skill sets that don’t — can’t — exist in the same person. And most technical people don’t realize this, as they are building stuff that they understand themselves.
Let’s take the BitTorrent analogy again. Bram Cohen created the technology. How many here have used Bram Cohen’s BitTorrent client? Nobody? Not one? Thought so. Everybody is using Transmission, Deluge, µTorrent, Azureus… other clients built by people who took the working technology and made it usable. Case in point: Nobody is using Bram Cohen’s BitTorrent client.
This is how you send money. I mean, come on.
It may be theoretically possible that a person skilled in crafting logic can also be skilled in usability, but I haven’t encountered one in 25 years. However, I have met scores of deepcore coders who thought they were.
The current Bitcoin client can’t be regarded as more than a proof-of-concept prototype. What the coders need to do to make the ecosystem pick up steam is to hand over the usability tasks to other people. Create libraries! Template code! PHP libraries, .Net assemblies, Windows DLLs, WordPress plugins!
When this happens, the people who love usability but don’t grok cryptoplumbing will start to create a real ecosystem.
Just to name a few use cases that need to be solved as a minimum to make the Bitcoin ecosystem succeed on its potential scale:
- Why can’t I combine two wallets easily?
- …or partition the one I have?
- Why can’t I subscribe to a service, which may change its pricing enroute (think electricity bill), with just one confirmation action?
- …or create a service that others can subscribe to?
- …and bill them for one-click confirmations?
- Why can’t I add more bitcoins with a single button in the client and a credit card number?
- Why can’t I create a shared wallet for a workgroup with individual spending limits?
- Why can’t I write server-side code for my WordPress blog that accepts bitcoin?
- Why can’t I pay with my phone without risking loss of my money through theft or loss of my phone?
- Why can’t I easily integrate bitcoin acceptance into my commerce website?
- Why can’t I write server-side code in my organization management program that accepts and sends bitcoin?
The list goes on and on. What is direly needed right now is not solutions to the problems above, but the enabling of other, new people to solve them. And to do that, the developers need to limit and clarify their role in the ecosystem: they need to be maintainers of the technology and libraries, but not gatekeepers of the end-user experience. There is so much value invested into Bitcoin already, there is no shortage of people who have a vested interest in seeing it succeed and who want to add to the ecosystem.
The proof-of-concept is here, and it works fine, but we need to move on towards a full ecosystem to realize Bitcoin’s potential.