An alternative crypto-history

Filesystems, version control, and the blockchain

Image courtesy of Adarsh Kummur

This is the fourth, and possibly final, article in my series on the blockchain without blockchain.

I’ve always had a warm place in my heart for filesystems.

I taught myself shell scripting while automating the installation of Disksuite, Sun’s free but sadistic disk mirroring software. I barely recall the actual work, instead remembering a hallway. I undertook a literal journey to learn programming, a repeated pilgrimage to the desk of a friend who took visible pleasure in explaining to me what I was doing wrong.1 It’s fair to say that if filesystems were less painful in the 90s, I would not be where I am today.

When Sun started advertising ZFS as the (finally!) successor to Disksuite and the filesystem it was built around, UFS, most of its functionality seemed obviously good — make the computers manage the disks, don’t demand people know up front how big a filesystem should be, don’t fail miserably when the server crashes, little things like that. But what was this data integrity thing? I’m embarrassed to say it took me a while to realize I needed it — who really cares if your filesystem is good at storing data, amirite? — and even longer to understand how it worked.

To explain it, I’m going to have to teach you cryptography. Just a little. You’re welcome to skip ahead if you’ve already got this part covered, but I expect most could use a little, ah, refresher. Step 1 in cryptography guides is usually: “Get a masters in mathematics from MIT.” I’m hoping to do a bit better than that. Cryptography really is just a form of math, and while we can’t all understand the details (I certainly don’t) we can at least understand the “algorithms happen here” flow diagrams2.

Cryptography is most famous for its privacy utility: You use it to ensure you and only you can read your files and chat messages. It gets more complex once we need to read them on all of our different devices, but most of it is pretty similar in concept. Even more useful is ensuring both you and I can read some text, but no one else can. It’s more complex, but is essentially an extension of that first use.

Privacy is not the only use case for cryptography. It’s also useful for efficient validation. That is, it can be used to see if a file you have today is the same one you had yesterday. I sent you a document, you think it looks wrong; how do we make sure it did not get changed somehow in transit?

Obviously one way to do that is to just send it again. This is not a great solution, because if you did not trust it the first time, why would you trust it the second? That might also be a bad idea if bandwidth is expensive. You generally want a verification mechanism that takes less space than the original file, and less CPU power than directly comparing the two files.

Cryptography provides just such a capability, usually called a ‘hash function’. It’s an algorithm that converts, say, a large text file into a much shorter string. If you want to ensure the file is not changed in some way, just run it again and compare the output. The short strings are easier to compare than the long documents, and you could even read them over the phone to someone so they can check the file on their end. These algorithms generally produce a string of a fixed length, regardless of input — this makes them efficient for long term storage and comparison, and safe to run on any size file. Here’s an example hash from my files:

03f39f4bfad04f6f2cfe09ced161ab740094905c

As you can see, it’s just a long string of gibberish. It’s not only useful for comparison, not meaningful in it’s own right.

What’s critical about these algorithms is that given a unique input they always provide a unique output. If you and I each have a file that hashes to a given string, then we can be confident we have exactly the same file. Of course, this can’t literally be true: We could design a hash function that only had 256 possible outputs, and there are obviously more than 256 possible inputs. This would produce a lot of what are called collisions, when two files hash to the same output, and, ah, is not terribly useful.

All of the modern hash functions are incredibly long. It is possible in theory but not in practice that a collision would happen. You’d need to execute the function 2^128 times. That’s 3.4 with 38 zeros after it. So, mathematically possible, but you can expect the sun to swallow the earth before the most secure hash functions get compromised. I mean, you can’t. You’ll be gone by then. But your files will still be safe.

Now that you’re at least as much an expert on cryptography as most of the bitcoin hodlers, why does any of this matter?

We were talking about data integrity.

You’d be right to guess that ZFS uses these hash functions to provide it. It goes further than just validating individual files. A little bit of cryptographic genius called a Merkle tree is the key. These don’t just hash the content on disk for later validation; they build a tree of hashes, where the leaf nodes are hashed by the nodes above them in the tree, which are themselves hashed by the root node. If any part of this system is corrupted — because the disk is broken, or someone changed the content some other way — it’s easy to detect. It’s not just that the individual hash will be different; remember each parent hashes all of its children, so now the parent is wrong. And its parent is wrong, too.

If the content is changed by any mechanism that does not also also update the Merkle tree, then it is easy to detect by rehashing all of the content and comparing the results to the stored tree.

This is how ZFS validates data integrity. It can write a block to disk, then pull the block and ensure it still matches the hash. When it writes a block, it updates the parallel tree, and when you ask for the block later, it can tell you if the block is still correct. If it’s not, it throws an error instead of handing it back to you.

When I first learned of this, it seemed overkill, but over time I remembered just how many ways there are for data to get corrupted. The most obvious one is someone changes it for nefarious reasons, but far more commonly you have a failure somewhere in the writing or reading process. The old spinning disks were error-prone, and the new SSD drives degrade eventually. It’s the complexity of reading and writing that really gets you, though: There are multiple layers of caches, drivers, and connections, any of which could introduce corruption.

For the first time on a normal production system, you could at least detect any of those problems. It’s too bad no one ever used it.3

I know, I know, you came to hear about how you could get all the awesomeness of blockchain without using the blockchain and instead I’m giving lessons on two things you could literally not care less about, cryptography and filesystems. Don’t worry. It gets worse from here.

Long after I learned about and promptly forgot ZFS (after all, it’s not like I was using it), I adopted Git. It’s a version control system, used for storing and managing source code. Every geek knows about it, but most of the world only recently learned of it when Microsoft bought Github for $7.5B with a ‘b’. I was an early adopter, switching Puppet to Git in 20084. Eventually I even learned how it works. I was titillated and a bit horrified that I had duplicated in Puppet one of the key features that made Git work: A system of storing files that allowed them to be looked up by their content (or rather, a hash of their content). Normally you store files by a name, but if lots of people (or, in Puppet’s case, computers) store the same file, they might not call it the same thing, so Git and Puppet instead stored them by their hash. This ensured we never backed up more than one copy of a file, saving a lot of space, and made it easy to check for changes in files.

For Puppet, we just used this to back up files we changed, in case people later wanted to revert.

Git did a lot more than that.

Like ZFS, it builds a Merkle tree of the entire file repository, with a similar goal: To understand what files have changed and how. After all, git is used to track and share changes to a collection of files. The sharing is a critical component; you can easily copy an entire git repository to another computer, or another person, and it’s important that they be able to confirm that they have a faithful copy.

Git stores the hash tree alongside all of the files. At any point, you can use the tree to validate every file in your tree. If there are changes (which is pretty much the whole point of a version control system), it can automatically store the new files and update the related tree.

Just like ZFS, one of the key features here is that the Merkle tree allows us to validate every file stored. We can walk the file tree and compare each file to its hash, and then compare the file listing to its own hash, all the way up. Any discrepancy is easily spotted.

This is my favorite kind of cleverness: It’s simple in implementation, yet makes Git more flexible and useful. It has power that other version control systems are missing, just because it relies on this basic mechanism for storage and validation.

Ok. Now we get to the point.

Again, I’m not actually interested in the blockchain. I’m interested in peeling it apart, putting the useful bits to work while avoiding the whole anarcho-capitalist aspect.

It would be easy to see the blockchain as a sudden revolution, a dramatic change in what’s possible. Viewed this way, it’s hard to separate the pieces from the whole. If all you see is the big picture, it’s easy not to notice that every individual component has its own history, its own value.

The blockchain was gradual, for both me and the industry. It was not one giant leap forward. It was part of a story, a sequence, and the most interesting aspect — Merkle trees — is decades old in math and now pushing decades old even in popular usage. Most of the interesting features touted in the blockchain come directly from them. Immutability (which isn’t) and trustless systems derive directly.

It’s worth understanding that history, to see which stages and steps apply to problems you have. The current cryptocurrency tech stack is built to solve problems I don’t think exist. Certainly they aren’t problems I have.

Unlike the blockchain as a whole, though, the individual technical components have been used for years, even decades, in production. Focusing on the current trend can blind you to the opportunity history demonstrates. I think you’re a lot more likely to find broadly applicable solutions there than in trying to replace currency.

Because I got here from the world of filesystems and version control, I see different benefits than you might if you approach thinking of currencies or exchanges. Or chat messages. That does not make me right or wrong, but it does, at least, mean we’re going to work on different problems.

I expect most of you think this is boring. That’s great. It will give me that much more time to build something.

  1. My brightest memory is learning that of course the ‘echo’ command resets the exit code variable. This was a critical early lesson in how your own debugging can dramatically change the behavior of a program.
  2. When people talk about the futility of trying to ban cryptography, this is what they mean: You can’t ban math.
  3. Yes, I know some people use and love ZFS. But never to the extent it should be.
  4. Resulting in one of our critical community members abandoning Puppet in protest, for some reason.

The virtue of a tool

Vendor success should be about customer needs, not its own.

Photo by Philip Swinburn

I am a tool junkie. I love the effortless balance of a well-known chef’s knife, like my hands know what to do all on their own. Heavy usage builds callouses and tunes muscles, its usefulness evidenced by scuff marks and changed infrastructure. Failure leaves blisters or even hospital visits in its wake.

A good tool proves its utility. Knives slowly shrink with sharpening, work pants thin, machines need oil. If they don’t, you’re either not maintaining your tools, or barely using them.

This wear is proof of your usage. They should be scratched. Dented. Aged. Patinas should be acquired from the shop, not factory treatments. Their callouses should pair yours. Tools can not be precious. They’ll just live on a shelf, then retire to your attic. You should seek that perfect middle ground, where you spend enough money that your kids can inherit them, but not so much that you are squeamish about giving them a job.

Tools only deserve the label if they help you work.

You might say I have strong feelings about them. I’m assuming this love led to my focus as a software entrepreneur on helping people people work. Or maybe my experience with tools in the physical world led me to seek them in the digital world, learning to make what I could not buy.

Given my tool fetish, you’d think I’d have a solid grasp of what I mean when I use the word. Apparently, not so much. I was recently pulled up short by a simple question, asked by Jordan Hayles of the Radical Brand Lab: What do you mean by tools?

What do you mean, what do I mean? It’s a simple question, right? The above text gives one example, but I would have thought I could answer it in a bunch of reasonable ways, none of which seem terribly controversial.

But the more I explored, the less simple the question became.

I’ve been describing my goal as building power tools for people. This phrase comes from my time building houses with my dad, and ‘power tools’ just meant the things you plugged in. You know? Because they needed power? It’s a common usage, maybe the word choice here did not mean much.

Except… I’ve spent more than a decade learning product management, describing myself as a product-oriented founder, managing that function in a growing company, and attempting to teach it to others. Yet here I am ignoring both the term and the field entirely. Why am I so quickly dumping my work of the last ten years? Is it just creative branding? Cynicism about my industry?

Why not power products? That’s a motor boat of alliteration: ‘power products for people.’ Awesome, right?

Ok, maybe not.

Product management as we know it began in the consumer goods industry. You’re handed a train car full of dish soap and told to sell it. You’ve got to package it, set pricing, convince a local store to carry it, argue with them about location, move it away from competitors, all that. Every product you see in your local grocery store is loved by a product manager who fights for its shelf space, believes it is beautiful, and wants you to give it a good home.

Tide soap is one of the most commonly stolen consumer goods, but not because it’s soap. The strong brand makes it easy to resell, even allowing it to be used as a stand-in for money in drug deals. I wish I was that good at product management. For all that, it says nothing about the soap.

Product management can also be used for evil. Laser printers had toner cartridges you could just refill. Not very clean, but cheap and reliable to run once you plonked down the cash for the expensive printer. Modern inkjet printers instead use disposable cartridges. To sustain profit margins in a rapidly commoditizing industry, manufacturers started putting rules in place on the cartridges: You had to buy them from the manufacturer, they had to be replaced every year, you could not refill them, you could not print in black and white if any color cartridges are empty.

The user was getting hurt so the vendor could make more money. People got pissed of enough that the US Supreme Court weighed in.

That’s good product management. Well, it’s evil, but you know what I mean. It’s effective. We’re talking big-B revenue effective. Hmm. A moral distinction begins to reveal itself.

These are examples of companies forcing their business model onto their customers. There’s no difference between the dish soap sold at retail and the one sold in bulk, yet they’re separate products, differentiated through packaging, shipping needs, and labeling. You pay much more for the retail package than the wholesale one, primarily because the business model behind them is so different.

But when I think of a tool, these complications are missing. When I use a hammer, it just has to fit my hand and smash stuff. When I pick up my drill, it works with every bit I own, regardless of the logo. The battery and charger are proprietary, but the vendor’s most visible role in my life is color choice. My yellow drill works just fine with bits from the blue or green companies. (You probably visualized brands by my just mentioning colors. That’s still effective here.) It does not matter whether I bought the drill from Home Depot or inherited it from my dad; once in my hands, it just works.

I think this begins to answer the question of what a tool is.

It helps you do your job, without your worrying about the vendor’s needs.

I know that DeWalt and Mikita need to make money to sell me a drill, but I don’t think about it when I’m using their tools. Even after more than two decades without one, I can comfortably recite that “my” hammer is the Estwing 22oz waffle head with a straight claw1, but none of those details mean I need the vendor’s permission to hit a nail with it. I make a decision about the right tool, I buy it, I use it. End of story.

It is small. If you call something a tool, not a product, you’re saying it’s less, it’s not as complete a solution. This can be belittling, insulting, but it does not have to be. It’s also a statement of independence. Of freedom. Of, and this is going to sound crazy, compatibility.

Products have an implicit, ongoing dependence on their vendor. If that’s me, I love it: I want you to pay me all the time, not just once. That ongoing relationship is how I afford to keep improving what I’ve built for you. This can be a great way to ensure we have a long-term, sustainable partnership. But it’s not always a healthy relationship. The more you have to deal with how I make money, the worse the experience is for you.

I think this is what I like about tools. They’re self-contained. Independent. Using them is fundamentally pragmatic, not a lifetime commitment.

That independence has downsides for me as a vendor. You don’t get any of those delicious growth-hacker buzzwords. Your product isn’t “sticky”, there’s no “moat.” Those are examples of my customers being constrained by my business model, and their absence means revenue is harder to build, to protect.

One might argue I’m better off because treating my customers with more respect makes a better business in the long term, and I’d probably agree. This kind of respectful partnership should deliver higher returns than one that traps and mistreats its customers. I think this is often the right answer, but it’s not a popular one. It’s harder to get funding, to get off the ground. I might be accused of not “wanting to build a real company,” or I might have Silicon Valley’s most dire insult hurled at me: “That’s just a lifestyle business”.

Tell that to Adobe. Or AutoDesk. These are great tools companies. They are the behemoths we know today because they knuckled down and solved their customers’ problems. They worried about that, rather than how they could extract maximum revenue over time. It was a different time, but people have not changed.

I don’t think that every product is compromised when the vendor’s needs show up in the customer’s life, but I think most are. Some of it is laziness, shoring up product limitations with business model innovations, but a lot of it is strategy, recognizing the value of painting your customer into a corner.

Honestly, some of it is just survival. A lot of those inkjet printers are unaffordably cheap, but buyers care only about cost, not value. Some markets are intrinsically dysfunctional, with users and vendors slowly killing each through bad deals and cynical behavior. But as a vendor, I get to make a choice about what markets to play in, and how to work with my customers.

I am a simple person with a simple dream: I want to build something that helps someone work. I have to make money while doing it, because that’s the nature of the job, but I’m more interested in my customers’ work than my own. I know I need a business model, a go-to-market strategy, a plan for growing and supporting my business. But my customers should not need to care about that, should they? If they like what I’m building, they should be able to buy it, and use it. And tell all their friends how great it is. They should not wake up one day to find they’ve accidentally gotten married to me.

I just want to build tools. And I’m proud of it.

  1. We told with great pleasure the (most likely apocryphal) story that this hammer was illegal in Florida because the metal haft could cut your thumb off.

Several short sentences

I have plenty to share. I can even write it. I just can’t publish it.

Picture courtesy of Cliff Johnson

Last year I decided to write more. Daily, in fact. One of my first actions was to ask Om Malik for advice. I had been following him since he was writing for Business 2.0, which was an actually valuable business magazine in the tech bubble. I am now lucky enough to know him through True Ventures.

When we talked, he shared a story about his first published piece. I did not find it helpful.

The magazine he was writing for (Fortune, I think) said his article was too long. He shortened it. A lot. It was still rejected. He compressed it more. Again. And again. I believe the original 1500 word piece became 300. Om’s punch line was that they told him it was their best-ever first contribution by an author.

I don’t think I’m cut out for writing 300 word articles. It’s not just that that kind of compressed writing is hard. It’s also about the missed opportunity: If you’re reading one of my articles, I want to take full advantage.

But my lack of desire to write short pieces is not why his story wasn’t helpful.

It’s one thing to say: “Write shorter”. Ok. I can see how that makes sense. Everyone knows the line, “I’m sorry this is so long, I didn’t have time to make it shorter.” It’s intuitive, implying that investing in the quality of writing somehow intrinsically shortens it.

But more than a year after this story from Om, I had still not found a way to put this principle into practice.

I could compress writing a bit. Programming taught me that shorter code is often simpler and clearer. Of course, it still took years to be good at it.

Stephen King had taught me that adverbs often indicate a problem. If you can get rid of them without losing meaning, your work is almost always better. One way to do this is to choose more expansive verbs.

I was able to translate my speaking coach’s advice into writing, too: She helped rid my talks of filler words. You might not think this is useful in writing — I never find myself typing out ‘um’1 — but I am over-fond of long phrases that can be easily replaced with a single word.

I tend to over-qualify. This is an opinion piece. You know that. I can skip all the incidences of “I think”. One “maybe” is enough, I don’t need “should maybe”. Two examples suffice; I don’t need three and an “etc”.

For example, in this piece, I replaced the phrase “was still not able to learn” with “had not learned”. “I had learned as a programmer” became “programming taught me”. Both of them are clearer, simpler, just… better. In particular, the verbs are much stronger.

Again, it’s not that I had learned nothing over the last year. I just… I knew I was using tactics. Simple rules. My writing was shorter, but… not short. The Hemingway app was still harshly judging all my failures.

Then I got lucky. I ran into Lucy Bellwood — a fellow Reedie! — at an Indie.vc event, and we traded book recommendations while her partner patiently slept on his feet. She recommended a new book to me: Several Short Sentences About Writing, by Verlyn Klinkenborg.

It’s amazing.

Of course, I doubt I’ll ever finish it.

It reads more like poetry than prose. I do not like poetry. Nearly every paragraph is a single sentence. Almost none grow to more than one line.

Many books on writing can be summarized as: Sit down and write. Seriously. Now. Keep doing that.

Not this one.

I can’t summarize it for you. It’s, it’s… dense. But I can share a little I have learned. And how it has cursed me.

I received a new term from it: Transitions. I knew what adverbs were long before Stephen King taught me that they’re suspect. Not to be entirely avoided, but hold your nose when you use them.

I already knew my sentences were too long. Even when I broke them up, I knew I relied too heavily on words that connect them (like the phrase at the beginning of this one). This knowledge wasn’t useful, because I wasn’t able to translate it into methods of fixing them.

The first thing Klinkenborg gave me was a name for these words: Transitions.

Like adverbs, they’re usually a sign that you’ve failed somewhere. That you were lazy.

This labeling did not magically fix my writing, but it gave me something to track. An easy measure for how I was doing.

Then he delivered the kicker: Simple guidance on how to eliminate them. Or at least, reduce them.

Knowing sentences should be shorter is not useful if you don’t know how to get there. What makes a great short sentence, vs a crappy long one?

His answer is incredibly dense. I have to slow down when reading it: You should minimize the distance between the period of your previous sentence and the point of this one.

Those long, complex sentences I like to write aren’t bad because they’re long, or because they have too many phrases. They’re bad because their point is so far away from their start. The reader is left to wander through it, holding out hope for a conclusion.

What are you trying to say? Say that. Immediately. Did you leave something important out? Say that. Now. Keep it up until you’re done.

Your old, complex sentence is now a series of short sentences, in order of importance, each getting right to the point.

Of course, that’s not how the book describes it. My description would likely horrify its author. There’s far more to it than this. But it’s a start. And a huge departure from what I was doing.

It’s also why I can’t write any more.

The topics I’m working on now are incredibly important to me. They’re hard to reason about, to capture. And while I’m sitting here struggling with the content, the writing itself keeps getting in the way. The form. The structure of the sentences. The line breaks.

Where I put paragraphs.

It’s not that I’m embarrassed. It’s that the process of writing is distracting me from what I am trying to write.

So please. Forgive me a little writer’s block. I promise I’ll get better.

When I do, I hope you’ll also tolerate experimentation and failure in how to put all this to work. Expect wild oscillations in sentence length. Inconsistency between sentences and paragraphs. Confusion across pieces. I’m in that ’conscious incompetence’ phase of short sentences, and it’s going to be a rough path for a little while.

I’ll come out a better writer, though. And hopefully you’ll gain something from witnessing the process.

I recently updated Om on my progress, sharing how much his story confused me and these tactical lessons I’d just received. Thankfully he appreciated the note, and was happy to see I took his story as a challenge, rather than a judgement. And he didn’t seem fazed in the slightest that it took more than a year to make anything of his help.

  1. Except, obviously, in this case. Not never. Just not usually.

Decentralize Your Data

What does owning your data even mean, and can the Blockchain help?

Photo courtesy of Dennis Kummer

Congress recently required Mark Zuckerberg to defend his lifelong practice of mistreating your private information. Movements to give you control of this critical data took the opportunity to claim they can prevent future such breaches. Blockchain is the new solution in search of a problem, and personal data is in the crosshairs.

But can the blockchain actually help secure your personal data? What would that take? And seriously, what do people mean when they say we should own our own data?

It sounds nice. Too bad it won’t help. The problem is not “ownership” (whatever that even means in a world of infinite digital copies). It’s centralization. Having one person’s data is a small threat, only to that individual. Having everyone’s data is a national crisis.

By now we’re familiar with the huge amounts that Facebook, Google, Amazon, and apparently everyone except Apple have on us. But how did they get it? Mostly, we gave it to them, through using their products. What we didn’t give to them, we gave to someone else who then passed it on.

There have been massive breaches at Equifax, Facebook1, and many others. Even the general public is becoming aware of the real causes. Some of the the largest companies in the world exist purely to collect your information and sell access to you based on it. They might not sell your data, but they definitely sell your attention using it.

These are the problems you know about. Don’t worry; it gets worse from here. If you think your birthdate and pictures of your kids are personal, what about your DNA?

Anne Wojcicki is married to a Google founder, and she liked their data accumulation so much she started her own company to build a huge pile of even more personal data. 23andMe does not scrape the internet — or your cheeks — to get your DNA; no, people pay for the privilege of giving it to them. Yes, they offer a service in return, but do they clean house after? Hah! No. They keep it. (Hopefully somewhat more safely than Equifax does.)

What’s so wrong about there being a database of DNA from a big chunk of the population? Let’s ask the police.

You might not be afraid of the police. You should consider yourself lucky. I know anyone of color in the US is and should be. I know I am; I grew up on a commune, and policed raided us using helicopters and assault rifles in hopes of busting us for cannabis. I don’t mean to imply that hippies have been as systematically oppressed as African Americans (and certainly not in the south); just that I grew up with my own justified skepticism of exactly what that force was here for.

Even if you don’t fear the police, you should fear the consequences of DNA testing. The science behind most parts of DNA are absolutely rock solid2. The police work is another matter. Beyond outright fraud used to wrongly convict people, the messy world of testing DNA at crime scenes just makes it hard to get correct results. Juries inappropriately treat a complicated test as foolproof. It could be compromised anywhere from the crime scene to police handling to the lab itself. The failure rate even without fraud is high enough that I would not want to trust my life to it.

Not to imply that DNA testing is worthless; quite the contrary. It has been used to exonerate many people who were incorrectly imprisoned and put on death row. It’s not that it always fails, just that you don’t want to finding yourself gambling on it against life in prison.

But remember: This is just for cases where someone has a single person’s DNA. Like having just your fingerprint. What happens when someone like 23andMe has a whole database of it?

“If you didn’t do anything wrong, then you have nothing to fear.” Pfft. Yes, it starts with requests for the DNA of individual suspects, but it escalates to doing a database-wide search for DNA that matches. And by ‘matches’, we don’t mean, “is 100% guaranteed”, we mean, “eh, it’s pretty close”. A DNA “match” directed the police to someone they thought was a relative of a suspect, who was then brought in for questioning. So I guess as long as you’ve never done anything wrong, and aren’t related to anyone ever doing anything wrong, you’re fine. Right?

I feel so much better.

I had investors literally laugh at the idea that collecting this data introduced security concerns. They grew up at Google, so it’s not surprising they could not see centralization as a problem. Just like Equifax started out wanting to make it easier to get loans, and now they’ve got so much power you can’t get one without them.

There is a world of difference between giving someone your data, and allowing someone to include your data in a massive pile of it. Any discussion of the risks of data needs to acknowledge that.

Now we see our discussions of owning your own data don’t quite have it right. What we actually want is decentralization of data. We don’t want a single company to have access to this much information about huge groups of people.

And now you see the problem.

New technology can’t break Facebook’s business model. It can’t prevent Google from scraping every web site on the internet and identifying you by connecting everything. Whether you give it to them or not, they’ll know what you look like, where you live, and who you hang out with.

Most importantly, it can’t prevent people from sharing all that data with these services. After all, they’re getting something valuable in return, like connecting with friends and family. Or figuring out their family tree.

The problem is not the centralization. It’s the effectiveness of a business model built on centralization.

So anyone who comes to you and says “The blockchain will allow you to own your own data!”, ask them in return, “How will you make it such a joy to use that Facebook will go bankrupt?” And please, record the conversation, because I want to see them stammer.

This is fundamentally a product and design problem, but the technofuturists are treating it like a technology problem. “Oh, if only those college students had access to better cryptographic tools they never would have shared that data with Facebook!” 🤯 No. People will stop using Facebook, and 23andMe, and Google, when there are better solutions. And unfortunately, they need to work ten times better, not just a little bit.

So talk to me about the blockchain. I really do want to hear how you’ll use it to help people own their own data, and remove the incentive to centralize all of this data.

But talk to me of products. Of user benefits. Of business models built around all of this.

Because people have to want what you’re selling, and the only way to get that is to build something they want to use. Only then will they be able to own their own data.

This is the third article in a series of indefinite length on The Blockchain Without Blockchain

  1. Although technically not a breach, since their usage rules weren’t broken — that’s how little they respect your privacy.
  2. Although we’ve still got a lot to learn about the epigenome, so don’t think we’re done here.

Trusting more with the blockchain

Society is built on trust, and improves or weakens with it.

Photo by Nathaniel Tetteh

I know I have trust issues. I don’t need the blockchain crowd telling me.

Trusting is scary. We’ve all been burned at some point. But we can also look back and see trusting someone helped us develop, personally and professionally. None of us could be who we are if we had not learned this critical skill. Knowing where and how to trust is critical to growth, to life. It’s not even just humans — we can see this in our pets, our livestock.

A cynic might say that trust limits us. That if we only had less, we could do and be more. I’m not exactly known for looking on the bright side, but even I know this is wrong. Trust is the infrastructure for our experiences. Removing it flattens everything, not just limiting what you can do but limiting why you would do it.

Our problem is too little trust, not too much.

We know the stereotype of someone who does not trust. Someone outside of society. We know a person who cannot trust is broken in some way, missing something critical, in need of healing. Many of us also know the allure of not needing to trust, or be trusted. “Ah, to be independent, to owe nothing to anyone…”

This is the dream of remembered childhood. It was always a lie. We were failing to notice the work being done in our name, for us. It was a joyous lie, made more pleasant with the golden tinge of nostalgia. Grown, we miss the lie, we reach for it.

But deep down, we know: More than anything else, life is about trust.

Great companies have been built on this truth. eBay could only exist by creating trust between unknown parties.

Some look at this and see failure. “If only eBay had not needed trust…”

One of the Blockchain’s great claims is enabling commerce between people who don’t trust each other. Never mind that of course you still have to trust something — the code, the packaging of what you’re buying, the exchange, etc. You might scoff and say these are a given, but none of those things can be trusted in the current world of the blockchain. Never mind that commerce has always been done between people with little or no trust. That’s not what matters.

It is philosophical, psychological: Given the recognition that life is enriched by trust, and more riches require more trust, what do you do? Find a way to add trust to your life, or look for a way to get riches without it?

I can’t say the blockchain people are wrong. Maybe they really do need some kind of trustless commerce. I don’t know them. Well, other than the drug dealers. I know why they want this.

But in my life, for my problems? More trust is the answer, not less.

Ironically, the blockchain can actually help with that. Without changing a thing. Its boosters are right about its utility, they’re just wrong about why it works.

I don’t like to trust people with my data. People talk about wanting to own their data, being able to share bits with Facebook but not the whole thing. It’s a nice, if naive1, idea, but that’s not what I mean.

I don’t trust you to touch it. You’ll muck it up.

Heck, I don’t even trust myself. Actually, I was never given that choice. My apps don’t trust me with my own data. They keep it hidden away somewhere, behind an API, in proprietary formats.

Their distrust is reasonable. I don’t know how the app works. The data model is hidden, the storage internal. Most importantly, they can’t tell if I mess with it, and they can’t fix what I break.

Things were in some ways better in the age of documents, but now our data is all hidden. We ask them to give us access, and they sometimes comply with simplistic APIs. But they do not trust us.

What if they did? What if I were allowed access to my own data? What if I could share it with you, my close friend, because I trust you with it?

I mean, not entirely trust. I’m not stupid. We’re not that close.

With the right tools, I could see what you did, understand it, ensure it all makes sense. You could change it, query it, hand it back to me, and I could validate the whole thing. Get the best out of your work, but keep safety lines in place.

Again, a cynic would say call this an example of eliminating trust. But is it?

Is the key to this new interaction really that I don’t trust you?

No. I don’t want just anyone to have my data. It’s for you. My close friend. Who I already trust. Mostly.

This change does not entice me to share with psychopaths, strangers, or, god forbid, the people I went to high school with. It provides just enough of a bridge that I’m willing to give you, my good friend, who I just met on the internet, rights that I’d otherwise hold back.

Of course I know this is not what blockchain people mean when they talk about trust. Meh. I’m not interested in making capitalism even less moral, less human. I don’t even want to hang out with the people who do. But I am interested in making data more useful. And I’m especially interested in connecting with other people.

And this certainly does that.

Now my applications can expose their insides. They can be slugs instead of snails.2 I can use the apps I love, but my tools can fill their gaps. I can script my way around their missing APIs and limited reporting. Heck, I don’t need their interfaces at all. Just because they’re provided doesn’t make them good, and I can get there faster using the tools I already know.

I can pick the best app, without committing to a long-term relationship. I can give you my data, take advantage of what you offer, and if I want to change later, I don’t lose everything.

There’s a great example out there: Github. If they went away tomorrow, I would lose almost no data I care about. They host, but do not control, my most important data: my source code. I get some utility out of they’re hosting it, but they don’t get special rights.3

Github actually created a new kind of trust relationship: Because its users can trust the data store, they began to trust strangers to contribute code. If I were using Subversion, I would have to give you all or no access; in Git, I can give you qualified access. Github calls these ‘pull requests’. “Yes, you can contribute code, but I get to read it first.” That enables a flowering of trust, potentially leading to a deep relationship. That path to complete trust is much narrower, much harder without this infrastructure of gradual trust.

You can choose whether to see this as more or less trust. You can’t argue with the new bonds created, the new groups formed, all through the help of tooling. Almost like how commerce starts with low-trust exchanges of money and can lead to deep and meaningful relationships.

What would a world look like if all of my applications had just as much, or as little, ownership of my data as Github does?

Of course, the apps won’t like it much. Their trusting me with my data also gives me power over it, where today I have none.

With enough usage, our expectations start to change. Given two otherwise equivalent accounting apps, wouldn’t you pick the one that trusted you? That gave you equal access to your data, simplifying automation and reporting?

I would.

This is the world I want.

This is the second article in a series in indefinite length on The Blockchain without Blockchain.

  1. Facebook does not have all of your data because you provided a massive dump at once; they’ve painstakingly collected it over the years, bit by bit. You can be sure they’ll store every little piece you selectively reveal to them.
  2. Honestly I don’t know if slugs are more useful, but they’re certainly more vulnerable. And I could not think of a better analogy.
  3. There is some data that only they have. This is a limitation in git, more than the plan of GitHub. E.g., my follower list is not in my repo, which is probably good, but it’s not anywhere else I can access, which is probably bad.

Blockchain without Blockchain

There is powerful technology hidden in the blockchain. Just strip out the parts everyone cares about

Image courtesy of MemeGenerator

People are very excited about the blockchain, convinced it’s going going to replace cash, or gold, or credit cards, or even the internet. I’ve even read claims that it’s the most important invention since little things like money and democracy. Starving through a failed attempt at utopia has taught me to align with the skeptics who point to the lack of proven use cases (other than fraud and crime), and with the pranksters who make fun of the claims of salvation.

That doesn’t mean I think it’s worthless.

The economic use cases (cash, gold standard, “sound money”, etc.) rest somewhere between unproven and conspiracy theory. None get any love from me. Just because I don’t respect the Austrian school of economics doesn’t mean I don’t understand it. They’re so stuck on their commitment to not learning from history that they can’t let go of the switch away from the gold standard. I am also not silly enough to think that the anti-government libertarians are in it for anyone but themselves.

I’m only here for the tech, people.

The world of the blockchain is in a state of flux. This is normal for movements, and especially so for the definitions of words to be shifting quickly. I experienced this directly as Puppet was helping to create the DevOps space. Today, when we say ‘blockchain’ we mean a specific set of features provided by the code underlying Bitcoin; some might add the requirement for smart contracts, as added by Etherium.

This definition won’t last.

I think that when we look up in five years, the word will mean something quite different. As the conversation inevitably shifts from hype about its universal applicability to finding practical use cases, I am convinced the term ‘blockchain’ will invert from its maximalist form, including all possible features, to a much more minimal form, defining a base set of functionality that is suitable to solving far more problems. Different implementations will layer features onto that base set, but all of these derivatives will be called ‘blockchain’ (which will soon have purists crying we’re not using the “real” blockchain).

It’s that base set of functionality that I’m interested in. I’m hoping the world’s excitement over the complete package can turn into momentum around a more flexible solution. What can we take away, and what can we do once we strip things down?

Let’s start with the most obvious thing we don’t need: Lack of trust. Free markets are built on trust, so it’s silly to try to build one that doesn’t. I just don’t run into many problems that can only be solved if I never trust anyone. Even writing that out makes me cringe.

I’m interested in power tools, user productivity, and helping teams, which inherently means I’m interested in people who know and trust each other. That isn’t to say data validation and simple synchronization are never helpful, but trust between people is not a problem. So take out that whole part of the story.

Next up is consensus. Let’s be honest: You don’t really want the world to have access to most of your data. And most of you who do, well, it probably doesn’t want to see it. This solution for deciding whose copy of data is right? I don’t need it.

That isn’t to say there aren’t important consensus problems; it’s just that the blockchain’s version of them is not useful to me. I do actually struggle with managing conflicts in my own work. I’m writing this essay on one of the six devices I regularly work from, and I obviously want it to transparently synchronize between the rest. I can dream about never having conflicts, but in the real world I need a simple way to handle them when they happen. That’s my consensus algorithm. If I use the Blockchain’s, then one chunk of work wins and the rest of the work gets thrown away. That might work well in some environments, but is obviously a non-starter for my personal work. Instead, I need an algorithm that gives me control over managing my own work streams.

I expect a blockchain hodler would flip at calling this a “consensus algorithm”. It’s not. It’s more like a tool for managing merge conflicts. If you buy into the blockchain, you’ve added a ton of complexity that can and should be handled by a person.

It’s not a big leap from managing conflicts between one person’s devices to managing conflicts within a team. This is still an important problem, one wrestled with by anyone building online collaboration tools, but requires nothing like the level of infrastructure built into the blockchain. After all, I trust myself. I trust my team. I like to be able to verify, but I’m more worried about mistakes and data loss than I am about intentional subversion of the system. And actually, the current solution is horrible for teams. It’s one thing for someone else’s work to cause yours to sit in a queue for a bit, it’s another thing entirely to have your code thrown away because someone is in front of you.

Taking out the trust-less consensus allows us to remove the worst part of bitcoin: Proof of work. This is how parties in a blockchain transaction fight to have their work accepted and others’ rejected. If they win, they are rewarded with a token, which is how they’re “paid” for their work.

We don’t need any of that.

We’ve already established we don’t need an automated, trustless process for deciding who gets to update the database (and we’ve concluded we don’t want conflicting just thrown away). As a result, this whole mechanism can just be removed. Good thing, too, because bitcoin is in the process of consuming all of the world’s natural resources in the name of never trusting anyone. This also simplifies the problem of scaling these databases. Bitcoin is stupid slow because its proof of work system is stupid slow. Remove that, and any iPhone can trivially record new data as fast as you want.

Now that we don’t need proof of work, we also don’t need, surprise!, the currency itself. In a trustless system, tokens are used to compensate the networks recording the transactions. This is now so cheap we don’t need to reward people to do it.

There you go. Now you’ve got the blockchain, except without cryptocurrencies, trustless transactions, consensus algorithms, or proof of work.

The blockchain without blockchain.

It’s important to note: It’s not that I think none of these features are ever useful in any case. It’s that none of them are necessary to get the most important features out of the blockchain, and each of them should only ever be added to a system if they’re truly needed. In most cases, YAGNI.

What can we do now? Well, obviously, now that we’ve removed so much functionality we can do a lot more. General purpose languages are more powerful than specialized ones, and a more flexible database is a more powerful one. The current set of blockchain features can really only be used for a narrow set of use cases, and even those seem to be more theoretical than actual.

What’s left?

A database. That’s what the blockchain always was anyway. It’s built on Merkle trees, which means you can validate every change back to initialization if necessary. This makes it kind of trustless: I can validate your work, rather than just trusting your word of what you did. This ability actually encourages me to trust you more with my data, though.

Check back later for more about what I mean.

This article is the first in a series of indefinite length. I’ll explore the consequences of this stripping away. I will also address some of the potential I see for full current blockchain feature set. I look forward to approaching this topic from a different direction.

The power of better tools

There is a solution to wage and productivity stagnation. Just don’t call it automation

Image courtesy of Washington Department of Transportation

I don’t know what the rest of the world thinks when they use the phrase ‘power tool’, but for me it’s visceral, literal. My experiences using them and watching them transform my family’s work permeated my time building Puppet. These power tools aren’t little plugins to expensive frameworks, they’re large capital investments that dramatically change your job.

I grew up building houses with my dad. The worst task he gave me was trying to paint a set of louvre doors for a closet while in high school; I had to flip the doors over every 90 seconds to catch drips getting through the slats. After three days of misery, my father relented and rented a paint sprayer, with which we finished the job the same day, at a much higher quality.

Around the same time, my dad would rent a pneumatic nailer for big framing jobs. By the time I finished college a few years later, that critical tool went from borrowed to owned and traveled everywhere with him. Initially used only for large jobs, most contractors now have multiple nail guns to cover framing, trim, and every other use case, and the air compressor needed to power it is as important as electricity.

It might not be obvious, but both of these are examples of automation. You replaced a very manual process — applying paint, or nailing things together — with a machine. If this were a factory, these days you’d call those machines robots, but because it’s a construction site, we just call them tools.

And these tools were expensive. Even with how much faster we finished that painting job, I expect it cost more to rent the sprayer than to finish the work manually, because of how little he was paying me. (This does ignore the soft costs of listening to me complain, which were likely high.) Even today paint sprayers and nail guns are often rented rather than purchased, because good ones cost a lot of money and aren’t needed all the time.

It’s no surprise that discussions of tools and productivity are easier to understand from my experience as a carpenter than as a sysadmin. There’s plenty of room for arguments about what is or is not a software power tool, but when it costs more than a week’s wages, it trails a bright orange cord everywhere it goes, and it can nail your hand to the wall while you’re standing at the top of a ladder1? It’s a power tool.

There’s a common story about what robots and automation do to people like my dad (and both of my brothers, who followed in his footsteps): It steals their jobs and ruins their lives.

What utter poppycock.

If you think of your job as driving metal spikes into wood, then a nail gun is a mortal threat. But if this is your value add, your biggest danger was never automation. My dad never sold his ability to join raw materials together quickly; he sold homes, he sold the opportunity to enjoy your house and family more. How did these new power tools affect that?

They were awesome. Painting and nailing are classic examples of menial, low-value work, and yet we spent most of our time on them. All of the differentiation we offered to our customers was packed into a narrow slice of work, because implementation took so much time and money. As we were able to bring more powerful tools to bear, the menial work shrank and larger portions of our time could be spent on design work, customer interaction, and tuning our customers’ homes.

Interestingly, my father’s next career step was even more pointedly about experiences enabled by tooling. He took a job with a state hospital in Tennessee, fabricating custom furniture for severely disabled patients. Suddenly he was using industrial sewing machines for upholstery, and partnering with medical professionals to design multiple beds for each patient, enabling them to be happier and more comfortable (and also avoid bed sores, thus saving hundreds of thousands of dollars per patient). Given the tragically minimal budget allocation for this kind of work, every dollar saved through automation and tooling directly delivered health and happiness to his patients.

It’s no wonder I see the value in power tools, that I am more conscious of the benefit they can deliver than the loss of low-value menial work.

I had a similar experience as I was building Puppet. I would meet executives and salespeople (I don’t know why it was always them) who would say, “Oh, automation? Great, you can fire sysadmins!” No. Beyond the obvious reality that I was selling directly to my users, who would never buy on the promise to fire their coworkers, that was just not why we were valuable.

Puppet gave people a choice between lowering cost but keeping the current service quality, or keeping your costs flat while providing a much better service. “Wait, making things better is an option? I didn’t know that!” Most companies were aware that their IT sucked, but they only knew how to measure and manage cost, so that’s what they did. Once you believed in the power to make things better, power tools turned out to be great investments for both the user and the buyer.

By letting people spend more time on the parts of their work they enjoyed, the work that makes them special, we also delivered higher quality experiences for their customers and constituents. “Spend less time firefighting and doing menial work, and more time shipping great software.” If the heart of your skillset is clicking buttons or responding to outages, Puppet might have been a threat to you, but our users knew where their real value was. We helped them spend more time there and less time on the boring, low value stuff. The sysadmins hated the work, the customers hated to need it, and the executives hated paying for it. Great, done, don’t worry about it.

When you look around the software market, though, power tools are out of style. There are big data companies building for the non-existent average user, minimalist companies building solutions that do little for almost everyone, and there are power tool companies of yesteryear still hanging around. There just aren’t that many modern software companies building large, clunky, expensive tools that just might cut your hand off if you’re not careful.

That’s partially why productivity has stagnated2. The world has not changed that much — some of the greatest improvements to productivity come from making large capital investments in tooling for your workers — but how we spend our money has. People balk at a $5k computer, when the Mac IIci would cost more than $13k in today’s dollars just for the hardware, yet was a powerhouse in desktop publishing. This is to say nothing of how the mobile app stores have driven down what people are willing to spend on software.

Yes, Adobe’s software is expensive, but it’s that price because it delivers so much value. If it didn’t, no one would buy it. Every large market should be so lucky as to have the collection of power tools that graphic designers get. It sounds crazy, but we’re suffering from not enough expensive software. Instead of building the most powerful software possible and finding customers who see its value, companies are building the simplest thing they can and trying to get everyone to use it.

There are bright spots in the industry, like Airtable and Superhuman. I’m hoping they help to shift momentum back to automating away the tedious work and enabling focus on what humans excel at.

More powerful tools improve your life, but they also make you happier even if you can’t buy them. They tantalize you, promising you great returns, if only you can come up with the cash. And they’re maybe just a little bit scary, warning you that buying them is not enough. You must master them.

  1. A friend of ours managed to do this when working alone in the time before cell phones.
  2. Yes, I might be being simplistic to make a point.

The Market Is Wrong About Your Problems

What Voltaire and the Flaw at the Heart of Economics Have to Teach Us About Software That Doesn’t Exist

Voltaire’s Candide juxtaposes an optimistic philosophy with unbelievable tragedy. He was angry at the 19th century philosophers who proclaimed that we lived in the best of all possible world while destruction and death unfolded around Europe on an epic scale.

We might hear the claim that we live in the best of all possible words and scoff. Of course, we’re too enlightened to be such naïve optimists. But are we? Isn’t the belief tempting? Or even, doesn’t the behavior of those around you make more sense if you realize they believe this, at least a little bit?

Economists are theoretically rational, analytical, big picture thinkers, but at the root of modern economics is a belief shockingly close to Candide’s parody of optimism. They have what they call “The Efficient Market Hypothesis” (EMH), which roughly states that all assets are valued fairly. This is built off the idea that asset values in an open market are fair because they include all available information, and all the actors in that market are behaving rationally in regard to both the asset and the available information.

This theory tends not to trigger the cynicism that Voltaire does. Intuitively, it sounds not just right, but defined as so. Isn’t an open market essentially a mechanism for finding the fair value of an asset? It’s not so simple. And when it goes wrong, it does so spectacularly.

Modern economists cannot be as destructive as the great thinkers of the 18th century, whose big ideas justified eugenics and many other horrors. Just because they cannot as easily be used to justify mass murder does not mean they should not be accountable for the downsides of their obviously incorrect theory.

“No”, I hear you say, “the EMH is not wrong; it’s correct by definition.”

Economists have convinced us of what Voltaire was protecting us from: We live in the best of all possible markets, where all information is public and all assets are fairly valued. If the market does not value something, that it must actually be worthless.

But of course, if that were true Warren Buffet would not have become a billionaire buying stocks that were worth more than the market was paying, the finance industry could not have been built on advising clients about public stocks, and you’d have no need for lemon laws or other regulations that fight information discrepancies. Nor would Kahneman and Tversky have won the Nobel Prize for demonstrating that actors in an economic system behave anything but rationally, puncturing the EMH for good. Thankfully, this has forced the field to begin to grapple with its flawed underpinnings, but many modern beliefs are implicitly built around these bankrupt theories.

You might be patting yourself on the back right now for not being silly enough to draw Voltaire’s ire, but it’s baked into the value system of the world around you, especially if you live in the US.

  • The market moves from irrationally ignoring new technologies like the blockchain to irrationally dumping money on them, without any fundamental change to justify the shift
  • Investments are made based on proximity and serendipity rather than rationality and opportunity size
  • We tend to claim that the rich earned their status through hard work, rather than recognizing the role of privilege, inheritance, and luck in their status

Of course, not everyone in the market operates with such optimism, but each of us is biased in this direction. It affects our thinking whether we want it to or not.

“Ok”, you say, “even if I accept some people make optimistic investment decisions, what does that have to do with software?”

Great question. If we live in the best of all possible markets, where all information is public and all assets are fairly valued, then we can trust the market’s assessment of what software should and should not exist. Lack of software to solve a problem is a sign that it’s not worth solving.

If, on the other hand, our world could be better, or if our market is imperfect at valuing assets, then we can’t trust intuitive conclusions about where value resides. This is most true when it comes to valuing unsolved problems. It might be that a given problem has no solutions because it is not worth solving, but mundane reasons are more likely to be at fault.

Most great companies exist because they provided something the market did not know it wanted. Their founders encountered a flaw, and managed to build something great in the opportunity created by it. Henry Ford claimed if he’d have given people what they wanted it would have been a faster horse. The market knew how to value them, but not cars. Before Apple, the market did not value personal computers. Before Google, the market valued directories but not search engines. Before the iPhone, the market valued expensive phones for professional use but not personal.

These value statements were market failures, and their resolution generated billions of dollars for the companies resolving them. Now, of course, the market sees great value in what these founders have created, but not because the market is so smart; it’s because it can no longer fool itself.

It’s easy to grow despondent in the face of such obvious market failures. If the wisdom of the crowds, the great invisible hand of the market, can be so wrong, what hope does a lonely entrepreneur have? I take a different way.

I luxuriate in these misses.

They surround us. We bathe in them. Yes, many great companies have grown into critical market gaps, but even with all these successes, there are untold problems whose solution should be valued but is not.

Only once you reject the market’s flawed opinions about what matters, you begin to see nearly limitless opportunity. There are so many more unmet needs than there are perfect solutions. These are your opportunities.

Of course, just because the market dismisses a space doesn’t mean there’s a great opportunity there. It’s your job to know the problem, your customer, your user, your buyer well enough to draw your own conclusions, to develop enough certainty that you don’t need someone else to tell you what to believe.

Because that’s the real point: Trust yourself, not a bunch of paternalistic optimists.

Owning my writing

It’s the message, not the medium

I did more writing in 2017 than I ever have before, probably more than I had done in my entire life. I stated at the outset my desire to write in order to learn, and publishing regularly has delivered. More importantly, it forced me to capture and share many of the results of my R&D. The writing topics were primarily venture capital, the software startup ecosystem, and founder optimization, but one of my weaknesses is a drive to the meta, spending time on the tools and systems rather than the work itself. Unsurprisingly, this ground is as fertile in prose as it is in code.

I have done all of my writing on Ulysses, which has been a good tool. I do miss much of the power of Vim for managing text, but the usability trade-offs are usually worth it. Plus, Vim is not exactly strong on wrapped text. Ulysses’s most important capability for me is that it transparently syncs between my phone , both of my iPads, and all three of my computers (yes, I know). I can open any document on any device with no worries (given my iPads are on LTE, and thus can always download updates). Second to that is the ease of getting data out. I was able to text a 5k word document directly from Ulysses on my phone to two different people, because it converts anything to PDF and can send out via the share sheet. It publishes directly to most platforms, so I used it to post everything to Medium. I do wish its backend storage was more visible, so I could version control everything in git, but you can’t have everything.

The only time I ran into troubles was publishing my travel writing — I was copy/pasting photos from Apple’s Photos app into Ulysses, then publishing into Medium, and it turned out that no part of this process downscaled the photos, meaning each was about 20MB. This is fine when you’re on solid wifi, but not so good from a campground in Yellowstone. The primary reason I did not write during the second month of my trip is it was just too painful to publish. Ulysses really fell down here, because when it works, it works great, but when it fails it is miserable. I’d just sit and stare at my iPad for ages, with no visibility of failure or success until the very end, and it would often manage to upload the text but not the photos. The only fix for this was to delete the draft from Medium and try again. Not so great.1

Over the year I became concerned, though. I heard about Andrew Chen, who built a following on successive publishing platforms (e.g., Blogger), each popular and well-funded, only to have the companies disappear (because that’s what Silicon Valley does to most companies). He eventually realized that the only way to consistently reach those who were interested was via email; it’s never going away, subscriber lists are easily portable, and of course everyone knows how to use it. He had to move from letting a platform own his audience to taking control directly, and email was the only real way to do that.

I think Medium is pretty good, and at least for now it has no shortage of funding. Even last year, though, it made well-publicized efforts to retool its business, a clear sign that whatever it was doing before wasn’t working. It seems unwise to bet that a follower on Medium will have any meaning in a few years.

It just so happened that I ended the year with an experiment in their new business model. My series on Venture Capital, in partnership with NewCo, was published behind Medium’s paywall. While the experience was positive overall, and I got paid more for those pieces than I have for, um, all of my other writing ever, earning money isn’t my real goal in writing. Yet, paying writers is exactly what Medium has to figure out in order to attract the content and audience it wants. I appreciated the extra attention working within their paywall provided, but I came out thinking it’s unlikely to be the right path for me in the long term. My goal is to maximize the reach of my writing, and it’s more about the arc of all of it rather than a couple of heavy-hitting pieces getting the most attention, which means our respective goals are orthogonal at best, and in direct conflict at worst.

While I have not written about it, I spent a lot of last year fascinated by email, inboxes, and how we consume content. I’ve been a deep fan of RSS from the Bloglines days (Unread is my reader of choice these days), but RSS is mostly dead (thanks, Google!). The kinds of sites that produced great feeds back in the day grew too big for a hobby. They became either wildly profitable for a small team and thus got destroyed with ads and shitty content (hi Boing Boing!) or people had to back away because it was just too much. Mainstream publications like the NYTimes might still publish RSS feeds (I literally have no idea), but RSS is a poor fit for how much content they produce.

When I look around, it seems that the RSS feeds of ten years ago are now awesome newsletters. See how often your favorite sites talk about their newsletters vs their feeds. I’m pretty confident I’ve never heard a podcast ask me to sign up for a feed, but many casually mention their newsletters. (Well, to be fair, podcast feeds are just RSS, so in that sense it’s survived, but I think we can agree it’s a very different use case.) The market has moved.

This shift is not all peaches and cream. The superiority of email as a publishing mechanism has not brought with it a superior reading experience. Long form content from writers I follow does not belong in the same inbox as requests for coffee meetings, yet that’s where we are. (I asked the Feedly CEO if they would please please add newsletter subscriptions to their platform, and he could only say they were considering it. If you want to build the newsletter reading app, hopefully with an index of great letters to subscribe to, count me in as an early contributor.)

Even with its downsides, I’ve decided to move my writing to my own site via a newsletter-first publishing model. From now on, everything will be published first to that site and the newsletter (sign up now!). There will be exceptions, when publications offer enough exposure that I give them some period of exclusivity. I will also indefinitely duplicate each piece to Medium on a delay, to take advantage of the audience I already have there.

There are enough examples out there that I’m pretty confident this is the right long term answer, but it’s early enough that it feels like an unstable experiment. Like most, I love and hate email, and I am a bit bummed about the extra infrastructure involved in this system.

If you’re still an RSS person at heart, you can always just subscribe to the feed, and if Medium is your bag, at least for now you’ll be able to see everything there, too. Of course I can’t promise how this plays out in the long run — else it would not be much of an experiment — but you can bet I’ll work hard to find the right way to talk with the people most interested in what I have to say.

One note before I go: I could not have made this transition without the help of Mike Julian. He helped set up each of the services, mediated the hiring of a consultant to modify the site, and connected all of the services together. He’s got a great book on monitoring, and is available for consulting on monitoring and observability. I can’t recommend him enough.

Thanks for following on so far. I’m excited about another year of writing.

  1. It’s worth noting that Apple’s iCloud Photo Library did wonderfully here; I could upload every photo to my iPad, and it would sync when it had good data, and sit quietly when it did not. I love asynchronous protocols.

Why We Hate Working for Big Companies

Modern capitalism raises the flag of the free market while pitting centrally planned organizations against each other

It’s quite a journey from being born on a commune to raising more than $87m in funding at a software company. This journey forced me to wrestle with existential questions about my true beliefs, and how they intersected my life as an entrepreneur. One’s work is rarely a pure reflection of ideology, but companies need a clear and authentic strategy, which requires a tight alignment between company operations and the founder’s philosophy. I have discovered more about those differences between what I believe and the best ways to grow a corporation while studying economics — that is, how money is made and exchanged — than any other area.

A worldwide conflict between communism and capitalism defined the latter half of the twentieth century. The United States’ ideological battle was the central drama of my childhood, and it was with a combination of glee, pride, and “told you so!” that my fellow Americans watched the wall fall in Berlin, and the USSR dissolve shortly thereafter. I expect few would deny that the US is the standard bearer for capitalism.

Yet, there’s a flaw at the heart of this claim. While the United States operates as a free market economy, the key agent within modern capitalism — the corporation — works more like an authoritarian state. Given how much of our world is built around corporations, this truth and its impacts are critical.

I grew up apart from America’s passion for capitalism. In the era of Reagan, I was living on a commune. My parents did not earn money for their labor, and we didn’t have personal property. My family left the Farm when I was 8, and as I matured, my ideological roots were in conflict with the US’s nonstop pro-capitalism message. As I joined the workforce and eventually started my own company, I found myself attached to neither the communal roots of my childhood nor the Wolf of Wall Street world I moved into. I grew slowly in convictions, as I encountered problems in the course of scaling a company.

The first real conflict came when it was time to hire managers. I founded a company primarily because I did not thrive as someone else’s employee, so what led me to think others would? More importantly, anyone who has ever operated at the front line is aware of the severe costs imposed by the separation between the people who do the work and the people who make the decisions in hierarchies. Hiring managers was just going to make the company do worse, not better, right? Right?

I expect three of you are gleefully shouting, “Yay, holacracy!” right now, while the rest are confused and either offended or think I’m an idiot. I did consider a manager-less world, but a little research provided only examples of disaster, because the only available options just replace an explicit power structure with an implicit one. In other words, it’s still hierarchical with the founder on top, but now decision making is opaque and the system is easy to exploit because of the lack of controls (which looks surprisingly like the cult/commune I grew up in).

Those who are confused or offended by the idea that managers make performance worse would be informed by a deep dip in economics. One of the core principles of the free market is that central planning committees can never be as efficient or as effective as the people doing the work. By definition a free market economy lacks a decision-making hierarchy; the ‘free’ means every agent (individual or corporation) can decide for themselves, without needing permission from a manager above.

While there are many aspects of modern American capitalism I reject, this one I wholeheartedly support1. The downsides of a strong central executive were taught to me early.

Like many other communes, the one I grew up on routinely failed to feed its people — my parents speak with horror of the ‘wheat berry winter’, when we lived on little else. While his people were short on food, the founder of the Farm was off touring Europe as the 3rd drummer in a band, “bringing our message to the world”.

Thankfully none of us starved to death, but the failing was similar to what most communist countries experienced: The central organization could not feed everyone. For years, I assumed this was just incompetence, whether at the scale of the Farm or China. The truth was far more structural. Millions starved during the Great Leap Forward because the central organization was trying something impossible: Managing the productive output of an entire country. The Planet Money podcast tells a great story of how this central planning was walked back in China, but the general point here is that these communist countries did not just nationalize the means of production, they tried to centrally control all of it from within a small group.2

When people talk about communist countries not being a free market, this is what they mean: They tell the farms what crops to produce and in what quantity, rather than letting them decide for themselves. China even went so far as to dictate what hours a farmer should start and stop working, and then directed managers to ring a bell for transition times to control every little group of farmers. Anyone who’s ever had to punch a clock into a rigid, dysfunctional hierarchy is likely getting painful flashbacks about now.

It should be immediately obvious why this fails miserably: The distance between the central planning committee and the farmer is so great that good decisions are nearly impossible. It’s nearly impossible for critical feedback to make it from the edge, where the farmers are working, to the central planning committee in time to affect decisions, and then for those decisions to make it back to the edge in time to be useful. The podcast linked above also points out how unmotivated the farmers were under this regime, cutting productivity even further. Those who have studied lean manufacturing, agile development, and DevOps are likely seeing parallels here.

The result was catastrophe. When a corporation is painfully inefficient it loses money and might have to do layoffs, but when a country fails at growing food, its people starve to death. I don’t mean to imply that central planning was the only cause of famine under communist rule — there were political operations that led to mass starvation, just like in the West — but learning more about these helped crystallize what I do truly prefer about capitalist models. It also converted the phrase ‘the free market’ from a catchy slogan into something meaningful to me.3

The most important feature of free market economies is that each person within them is able to make independent decisions in their own best interests4. If you’re a farmer, you can decide what to grow, how much to grow, and when to work to develop your crop. Heck, you can even choose not to be a farmer any more. Success is merely dependent on your finding a buyer for your work at a price you can tolerate. Any given year might not be perfect, but your decision making gets better over time as you learn to respond to customer demand.

This pattern is easy to understand in any system where the people doing the work make the decisions. If you’re a jeweler, you can decide what to make, how much to sell it for, and what to spend your time on. Same if you run a small restaurant, lead local tours, or are a one-person shop doing house remodeling. It’s a free market, where you can charge what the market will bear, and you can quickly and efficiently respond to its whims, ensuring that you are getting the best use of your time.

This was a powerful organizing principle for a long time. The history of human commerce developed largely this way: One person, or as many people as could fit in one shop, would turn labor into a product, then find a buyer for it. Most large-scale efforts were organized by the state of the time: Monarchs and the landed gentry, who were the only ones capable of marshaling enough resources to build palaces, roads, and other large construction projects.

This began to change in the 17th century when corporations like the Dutch East India Company were able to deliver massive windfalls to investors by pooling money and using it to extract resources from colonies. There was a step change in the 19th century, as corporations went from generating wealth to building and owning infrastructure. It’s one thing to outfit a single ship for a year-long voyage, yet another to maintain railroad schedules across the United Kingdom, or run a telegraph network around the whole US. These aren’t just short-term money-making exercises, they’re long-term commitments with big capital outlays and large returns over years and years.

We still live in a free market economy, but it’s not one Adam Smith would recognize. Instead of individual or small operators, ours is composed almost entirely of corporations. Really big corporations. And these companies, they use the same kind of central planning that we so despise in communist systems. I know. I’ve done it.

By the time my company got near 500 people, we had a multi-week planning process, where the leadership (i.e., me and my lieutenants) set out top-level goals, built a top-down plan to accomplish them, then drew information from the front line to see where it needed change. We called this a bottom-up plan, but it was only bottom-up from the perspective of numbers — how much money we’d have, what our costs were, etc. — rather than from the bottom of the organization. We could see no way to have a system where the people doing the work built a plan for the organization. Even thinking about it now, my reaction is, “How would they know what my goals are?”

That’s the kind of question you can only ask in an authoritarian state, not in a free market economy. My goals became my company’s goals, and the only real way to ensure people worked toward them was providing a plan. You might argue that a corporation should focus on shareholder value, but that doesn’t help make decisions about what the company should actually do.

Great leaders find a way to listen to everyone in the company, but in the end, leadership is about making decisions. That’s essentially the definition of the word. And we all know leaders who did not bother to listen, or just did not need to in order to be great; today’s most vaunted tech leader, Steve Jobs, was famously disrespectful of the opinions of others, yet made a lot of world-changing decisions (not all for the better).

This is exactly why working in a big corporation is so stifling. If you’re in a small company, the executives are close enough to the front line that it’s more like working in a tribe, but in a big company, the leadership is so removed from whose who do the work that executive teams operate like the politburo we so decry in communist countries. Certainly the bureaucracies are no more enjoyable or forgiving.

I find it both ironic and painful that my inability to work for someone else resulted in my creating a company that involved a lot of smart, capable people working for someone else.

I wish I had a solution. If this were an easy problem, its solution would already be pervasive, because the benefits are massive. Just in terms of efficiency, we’ve seen how much better the free market is than planned economies, but it also has a hugely positive impact on quality of life. People are happier when they’re in control.

I know the solution is not more freelancing and contract work, which America’s corporations are addicted to. That’s the worst of both worlds: The exploitative nature of capitalism with the inefficient bureaucracies of communism. Transactions on the free market work because they’re good for both sides, but most people only accept part-time contract relationships today when they have no other real choices.

Holacracy certainly isn’t the answer. It’s fundamentally flawed because of its implicit power structure — Tony Hsieh still runs Zappos, even if he does not use a central planning committee to do it — but the biggest problem is it makes no mention of economics. Without a clear system for scoring the transactions (i.e., money) it’s impossible to build a free market.

This problem of how to handle economics within a non-hierarchical company might lead some to think of using blockchain tokens as an internal currency. This is impossible today, beyond the fact that the world of blockchain is mostly about fraud and black market sales. The biggest problem is that we have no idea how to value most of the work people do. I mean, we might know that what a developer should get paid for a year’s work, but how much is that work worth? The majority of the work done in modern corporations is incredibly hard to value, which is partially why companies are so inefficient and make so many bad decisions.

That brings up an even bigger problem — companies today hire workers to make money from their labor. In other words, they generate profit because they pay their employees less than they’re worth. If everyone could trade their labor for exactly the amount of money it was worth, the corporations that employ them would have a much harder time making money. Instead, in modern corporations the shareholders and the executive team — again, the central planning committee we so despise — make the majority of the money, while the front line does all the work and makes very little. This is true even at the big tech firms; software developers might be well paid relative to hotel workers, but they’re paid a pittance compared to the founders and executives. This might speak to why we have no solution yet — free market corporations would tend to reduce concentrations of wealth, which would be terribly disruptive to the current system.

Like I said, I don’t have a solution. But at least now I know what makes the current system so painful, and it gives me some hope that we actually can come up with a better answer. I know I’ll be working harder in the future to manage the downsides of what we have today.

  1. Although I might stress the “well regulated” part more than most modern economists.
  2. Of course, capitalism is just as capable of killing its citizens, whether through starvation or lack of health care.
  3. Note that I’m not taking the capitalist side of the cold war here; while Americans were decrying the oppression of the Soviets, we were actively clawing back progress on civil rights and knocking over democratically elected governments. This article is about principles, which political regimes rarely show a great track record in following.
  4. But not so independent that you should be as pathological as Ayn Rand.