Objections to Blockchains remind me of objections to Git

On the HN thread.

It’s just really hard for people to see beyond the present. Innovators in one cycle are often blind to the opportunities in the next. I see it in a couple of my successful friends that built their own companies on the web and mobile when it comes to crypto.

I’m reminded of the quote about the radio:

“The wireless music box has no imaginable commercial value. Who would pay for a message sent to no one in particular?” — Associates of David Sarnoff responding to the latter’s call for investment in the radio in 1921.

And then a couple of years later, for someone that made their stake in radio:

“While theoretically and technically television may be feasible, commercially and financially it is an impossibility, a development of which we need waste little time dreaming.” — Lee DeForest, American radio pioneer and inventor of the vacuum tube, 1926

And remember TV didn’t really come into its own until decades after 1926.

Yesterday, I was reading about past objections (circa 2007) to using Git vs CVS or SVN, and most of the objections were things that turned out to be unimportant. The objections focused on how their team doesn’t have a decentralized workflow that the Linux Kernel does, so they don’t need git. Or that the interface sucked, so they don’t need git.

Turns out everyone mostly uses git in a centralized way (via Github), to coordinate, but the decentralized design reveals secondary affordances that are really useful in practice. The decentralized design allows you to work and commit offline–great as laptops became more pervasive and more people worked on them. (You use to have to be online to commit, and can sometimes take minutes) The decentralized design also used content hashing with parent chains, which allows for inherent self-checking–no object modification can escape detection. Git’s data structure makes commits fast, which in practice makes fine-grained commits possible. And the decentralized design gives everyone a backup of the repo, so the central repo getting nuked by the intern doesn’t take down the org. Nowadays, in saying these things, I’m preaching to the choir. But back then, it was completely non-obvious.

The only people that got it right back then are the ones that dug into the technical details, and then actually tried it out. Notably, the guy at X.org.

And I think it’s a similar thing with cryptocurrencies, in the way that the fundamental different design and architecture of blockchains allows for secondary effects that are harder to see (until you’ve actually used or programmed in it) that aren’t available to you at all otherwise.

The trap most people fall into is that they compare the new X with what the old Y does very well. But they never consider that if it’s actually got a new underlying concept, it might suck at what the old Y has had time to get good at, but it allows for some other thing that we just couldn’t do at all before.