What we mean when we say software should belong to you

Ownership is not a feeling. It's a property of the system: the source, the keys, the data, the right to walk away.

Most people, asked whether they own their software, would say yes. They paid for it. They use it every day. It sits on their phone or their laptop. What more could ownership mean?

Quite a lot, as it turns out. Ownership is not a feeling about a thing. It's a set of properties the thing either has or doesn't.

When you owned a book, you could lend it to a friend, write in the margins, sell it secondhand, leave it to your kids. The book worked the same the day you bought it as the day you died. Nobody took it back. Nobody changed what was on the pages while you slept. Nobody charged you a monthly fee for the privilege of opening it.

Most software fails every one of those tests.

The cloud document you wrote last month is hosted on someone else's computer. If they decide to change the format, you adapt. If they decide to raise the price, you pay or lose access. If they decide their terms now allow them to train a model on your work, your only option is to stop writing. The file isn't yours. It was never yours. You were renting a seat at someone else's desk.

Real ownership of software has a small handful of concrete properties. None of them are about how the software feels to use. All of them are about what would happen if your relationship with the company that made it ended tomorrow.

The source. You can read the code that runs your software, or someone you trust can. This isn't about whether you'd ever read it; it's about whether anyone could. Software you can't inspect is software that can do anything to you, and you'd never know. It's the difference between a contract you've read and one you've signed without reading.

The keys. When the software encrypts your information, you hold the keys, or your access to your information depends on someone who isn't you. End-to-end encryption where the company holds a copy of the keys is theatre, not encryption. The test is simple: if the company received a court order tomorrow, could they hand over your unencrypted data? If yes, the keys aren't yours.

The data. Your information lives in a format that other software can read. You can take it out tomorrow, today, in five minutes, and import it somewhere else without losing anything that mattered. Not "exportable to a flat file with the history and attachments stripped" — exportable in a form where what comes out of the export and what was in the system are the same thing. If the export is a pile of CSVs that lose your folder structure, your timestamps, your relationships between records, that isn't your data. That's a souvenir.

The right to walk away. You can stop paying, stop using, stop participating, and not lose what was already yours. The lease ends; the apartment isn't yours, but the furniture you brought in still is. Software fails this test most often through silent dependencies — the photos that only render correctly in the proprietary viewer, the contacts that only sync to one phone OS, the calendar invites that break when you change providers. These are the things you brought into the apartment that the landlord quietly nailed to the floor while you weren't looking.

Software that has all four of these properties belongs to you. Software that has three out of four belongs to you with an asterisk. Software that has fewer than three belongs to whoever sold it to you, and you are using it on terms that can change without your consent.

Almost all popular software fails this test. Almost all of it. The implication is uncomfortable, which is one of the reasons it took us a long time to say it plainly.

The good news, such as it is: every category of software people actually use has at least one option that passes the test. Email, calendar, photos, documents, messaging, browser, operating system, the lot. They're not always the prettiest options. They're not always the easiest to set up. They are always the ones where, if the company behind them disappeared tomorrow, you'd still have your stuff.

That last sentence is the whole thing.

If the company disappeared tomorrow, you'd still have your stuff.

If you can't say that about the software you use, you don't own the software. The software owns you, and the company that wrote the software owns the software, and the math goes the way you'd expect from there.

We help people change that. Not by purity-testing them about the choices they made when the alternatives weren't ready and the information wasn't there. By meeting them where they are, looking at the four properties, and figuring out together which ones matter most for their situation. Sometimes the answer is "stop using this one tool." Sometimes it's "rebuild your whole stack." Sometimes it's "you're already in better shape than you thought, here are the two changes that would matter."

But it always starts with the same question, and it's the question we want you to start asking, of every piece of software you use:

If they disappeared tomorrow, would I still have my stuff?

If the answer is no, the software doesn't belong to you.

It's worth knowing.

$johndoe