Open Info

Ask someone if they own their photos and they'll say yes without thinking about it. Of course they do, they took the picture. But ask a follow-up: can you get every photo, in its original quality, out of the app it's currently stored in, in a format you could open in ten years without that app's help? Suddenly the answer gets a lot less certain.

That gap, between "I made this" and "I actually control this", is what ownership really comes down to. And most of us have a lot less of it than we assume.

Ownership isn't about who took the picture. Legally, sure, you probably do own the copyright to your own photo. But copyright isn't the same as control. Control means: you can access it whenever you want, move it wherever you want, and it doesn't stop existing just because a company changed its terms of service or shut down a product.

By that standard, a lot of what we call "ours" is really just "ours as long as the platform keeps letting us have it." A note in a walled-garden app. A message in a chat service with no real export option. A photo automatically backed up somewhere, compressed, re-encoded, tagged with metadata you didn't ask for, sitting behind a login you have to keep paying for or keep agreeing to terms for.

None of that is ownership in the way we usually mean it when we say the word. It's more like a long-term loan with very favorable terms, right up until it isn't.

This isn't really anyone's fault in a dramatic sense. Nobody sat down and decided to trap your data. It's usually just what happens when a product optimizes for ease of use and growth, and export tools are neither of those things. Building a seamless in-app experience is a much better use of engineering time than building a clean way to leave.

The cost shows up later, quietly. A service shuts down and you scramble to get your files out before the deadline, half of them not exporting properly. A subscription lapses and years of notes become read-only, or gone. A messaging app changes its backup format and suddenly your years-old conversations are unreadable without the exact right migration tool, which may or may not still exist.

None of these are catastrophic on their own. But they add up to a strange truth: most people's digital lives are scattered across a dozen services that each hold a piece of them hostage in a small, forgettable way.

Real ownership has a few concrete features, and they're worth checking your own setup against:

- You can get a full export, not a summary, not a sample, everything, in a usable format.

- The format is something other software can open, not something only the original app understands.

- Losing access to the service doesn't mean losing access to the data, because a copy already lives somewhere you control

- You decide what happens to it, including deleting it completely, not "deactivating" it into some in-between state.

Very few products are built around all four of these by default. It's usually something you have to go set up yourself, turning on regular local backups, choosing tools that store things in open formats, actually testing an export before you need it in an emergency rather than trusting it'll work when the moment comes.

It's a habit, not a one-time fix. Owning your data isn't a switch you flip once. It's an ongoing practice, periodically pulling copies of things out of the platforms that hold them, favoring tools that don't fight you on the way out, treating any given app as a temporary home for your stuff rather than a permanent one.

That sounds like more effort than most people want to put in, and honestly, most of the time it is more effort. But the alternative is finding out how little you actually controlled, right at the moment you needed it the most, when the service goes down, the account gets locked, or the company simply decides it's done.

You pick a tool, you're happy with it, you don't have any plans to leave, so who cares if your emails are stored in a standard format or a proprietary one, if your notes app uses Markdown under the hood or some private blob? Turns out it matters even if you never plan to leave. Here's why.

Openness isn't really about switching. The obvious argument for open standards is portability, if the format is open, you can take your stuff elsewhere. That's true, but it undersells the point, because it frames openness as a feature for people who are dissatisfied. Most of us aren't. We like our tools. We're not shopping around.

But an open standard does something else, something that has nothing to do with whether you personally ever leave: it means your tool has to compete on being good, not on being the only door out of the room. A proprietary format is a wall disguised as a feature. It doesn't need to be the best option forever, it just needs to make leaving expensive enough that you stay anyway. Open standards remove that leverage. The company has to keep earning your use, not just keep you trapped in it.

The option has value even unused. There's a useful idea from economics here: an option has value even if you never exercise it. Insurance is valuable before the accident, not just after. The same logic applies to data portability. The fact that you could leave, cheaply, at any time, changes the relationship, even while you're staying.

Practically, this shows up in small ways. Support gets better when a company knows dissatisfied users have somewhere else to go. Pricing stays more honest when switching isn't a multi-month data-recovery project. Products keep improving instead of coasting on lock-in, because coasting stops working once users can leave without much friction.

Open standards don't just help you against one company, they let tools work together in ways closed ecosystems structurally can't.

Think about email. It's an open, decades-old protocol, and because of that, you can pick literally any email provider and it'll talk to every other one. Nobody had to build a special bridge between Gmail and a small independent mail host, the standard already handles it. Compare that to messaging apps, most of which use closed protocols, which is exactly why you end up with four different chat apps installed depending on who you're talking to. Same basic function, but one world has interoperability and the other has fragmentation, purely because of a decision about openness made somewhere upstream.

That compounding effect is easy to miss because it happens quietly. Every additional tool that adopts an open standard makes every existing tool on that standard slightly more useful, because the network of things it can talk to just got bigger. Closed formats don't get that benefit.

None of this requires you to be the kind of person who switches tools often, or who cares about the technical details of a spec. What it protects is much simpler: your ability to change your mind later, and your leverage right now.

You don't need to plan to leave for a locked door to bother you. Knowing the door exists, that you could walk out any time, with everything you brought in, and set up shop somewhere else, changes how comfortable you can be staying. Open standards are what make that door real instead of decorative.

There's a specific kind of stubbornness required to get a Linux distro running well on a laptop the manufacturer never intended it for. The Wi-Fi chip isn't supported. The trackpad registers every tap as a right-click. Suspend doesn't wake back up, or it wakes up but the fans spin at full speed forever, or the backlight forgets it's supposed to dim. None of this is documented anywhere official, because officially, this configuration doesn't exist.

And yet, you can usually get there. That fight is worth having, and I want to talk about why.

The first thing to accept is that you're outside the guarantee. The manufacturer tested exactly one operating system on this hardware, maybe two. Everything else is unclaimed territory, mapped out entirely by other people who also refused to accept "unsupported" as a final answer.

That changes how you should think about the process. You're not filing a support ticket. You're doing fieldwork. The people who've been here before you left notes, forum threads with titles that look like error messages, kernel patch sets with names like a chip's model number, a GitHub repo with three stars and a README that saved someone's laptop. Following that trail is less like tech support and more like archaeology.

If you've done this more than once, you start to recognize the pattern. It's almost always one of these:

- Wi-Fi and Bluetooth chips, because manufacturers love to ship whatever combo card was cheapest that quarter, and not all of them have open drivers

- Suspend and resume, because power management is genuinely hard and vendors often only tune it for the OS they shipped

- Function keys and special buttons, brightness, volume, airplane mode toggles, small stuff, but it's the difference between a laptop that feels finished and one that feels like a science project

- The trackpad, especially on anything with fancy gesture support baked into the vendor's own driver stack

Knowing this in advance saves a lot of guessing. When something's broken, it's probably one of these four things, and there's probably already a kernel module, patch, or config tweak that someone wrote specifically because their identical chip was broken too.

Why bother, when the manufacturer's OS "just works"? This is the fair question. If the machine runs fine on what it shipped with, why put in the hours?

A few reasons, and they compound:

- You get to actually own the machine. Not just the physical object, but the software running on it, what it does, what it sends home, what gets updated and when. That's not a small thing on a device you might use for the next several years.

- Old hardware gets a second life. A ten-year-old laptop that's too slow for a bloated stock OS can run a lean Linux setup like it's new again. That's real value, not just a hobby win, it's fewer machines in a landfill.

- You learn how the machine actually works. Fighting with a Wi-Fi driver teaches you more about how hardware and kernels talk to each other than years of just using a laptop as a sealed appliance ever will.

- Somebody has to do it first. Every "unsupported" laptop that eventually gets full support did so because someone stubborn enough documented the process, wrote the driver patch, or filed the upstream bug report. If you get it working, the next person doesn't have to fight as hard.

Here's the actual process, roughly, although it's rarely elegant. You install a distro, boot into a mess, and start eliminating problems one at a time, checking "dmesg" for what the kernel is complaining about, searching the exact hardware model plus the exact error, testing a different kernel version, occasionally cross-referencing a Windows driver's chip ID against a Linux compatibility list to figure out what you're even dealing with.

Sometimes the fix is a one-line kernel parameter. Sometimes it's compiling an out-of-tree driver from a repo that hasn't been touched in two years but still, miraculously, works. Sometimes there's no fix yet, and you either live with the broken thing or become the person who eventually fixes it.

At the end, it's worth it. There's a genuine satisfaction in closing the lid on a laptop that shouldn't run this well, that some spec sheet somewhere declared incompatible, and having it actually sleep and wake up properly. It's not efficient. It's not the fastest way to get a working computer. But it's yours in a way that clicking through an approved installer never manages to be.

Here's a small but telling test: if the company that made your device disappeared tomorrow, could you still fix it in five years?

For most electronics, the honest answer is no. Not because the hardware itself degrades that fast, but because the knowledge required to repair it was never yours to begin with. The schematics live in a proprietary system somewhere. The replacement parts are custom-molded and sold nowhere else. The firmware is signed and locked, so even if you could source a part, you couldn't get the device to trust it.

Open hardware flips that arrangement. And once you've lived with a device that works this way, it's hard to go back to pretending the alternative is normal.

With open hardware, the full design, schematics, board layouts, sometimes even the reasoning behind specific component choices, is published and available. Not a marketing diagram. The actual circuit.

This matters more than it sounds like it should, because it means a problem doesn't have to be a mystery. If a board stops working, someone with a multimeter and the schematic can trace the fault instead of guessing. Repair shops, hobbyists, and future-you five years from now can all work from the same source of truth the original designer used. There's no black box standing between "this is broken" and "here's why."

Closed devices love custom parts, not because the design requires it, but because it locks the repair pipeline to the manufacturer. A cracked screen, a dead battery, a blown capacitor: each becomes a call to the only supplier who sells the exact part, at whatever price and lead time they choose.

Open hardware tends toward standard, source-able components wherever it can. A resistor is a resistor. A common connector is common everywhere. When something fails, you're shopping in the broader market instead of waiting on one company's parts department to decide your repair matters enough to prioritize.

This is the part that actually changes how you think about ownership. A closed device is only as permanent as the company behind it. When that company pivots, gets acquired, or shuts down, the device doesn't necessarily stop working immediately, but it stops being maintainable. No firmware updates, no parts, no documentation, no path forward except replacement.

An open device has no single point of failure like that. The design outlives the company. Anyone can keep manufacturing compatible boards. Anyone can keep the firmware alive. The community that formed around the project can keep going even if the original team scatters. It's the difference between a device that depends on an entity and a device that depends on a design, and designs, once published, are remarkably hard to kill.

None of this is really about a philosophical stance on freedom, even though it gets framed that way sometimes. It's about what happens when things go wrong, because things always eventually go wrong. A part fails. A company folds. A firmware update bricks something. The question is whether you're stuck waiting on a party that may not exist anymore, or whether you have what you need to fix it yourself, or find someone who can.

Open hardware doesn't mean everything is DIY, and it doesn't mean it's always cheaper or better made. Plenty of closed devices are excellent right up until the moment they're not repairable anymore. But open hardware buys you a specific kind of insurance: the device stays yours, functionally, for as long as you're willing to keep it running, not just for as long as the manufacturer decides to support it.

That's worth more than it gets credit for.

I have a folder of notes from 2009. They're .txt files. I can open them right now, in anything, on anything, and read them instantly. No conversion, no "this file was created in an older version," no little spinner while some app tries to figure out what I meant.

Cleverness has a shelf life. Every "smart" format is a bet. It's a bet that the company behind it survives, that the format stays relevant enough for someone to keep writing parsers for it, and that whatever clever thing it does, the embedded metadata, the proprietary compression, the fancy versioning, stays useful rather than becoming a liability nobody wants to reverse-engineer.

Plain text doesn't make that bet. It just sits there being plain text. A .csv file from 1995 opens exactly the same way a .csv file made this morning does. There's no schema to migrate, no vendor lock-in, no dependency on a runtime that stopped being updated. The format's simplicity is precisely why it doesn't rot.

Compare that to something like a proprietary CAD file, or a database dump from a tool with a weird export format, or one of those design files that only really works if you have the exact right version of the exact right software. These aren't bad tools. But the file itself is fragile in a way plain text isn't. It depends on an entire ecosystem staying alive around it.

Boring formats are honest about what they are. A CSV file doesn't pretend to be more than rows and columns. A .txt file doesn't pretend to be more than characters. There's a kind of honesty in that. You know exactly what you're going to get when you open it, and so does every piece of software written in the last forty years.

None of this means boring formats are always the right call. CSV can't represent nested data cleanly. Plain text has no styling. If you need rich structure, boring formats will frustrate you, and that's a legitimate reason to reach for something else.

But there's a difference between choosing complexity because you need it and inheriting complexity because a tool wanted to lock you in, or because "modern" sounded better than "durable." A lot of software optimizes for looking impressive today. Boring formats optimize for still working in twenty years. Those are different goals, and depending on what you're archiving, only one of them actually matters.

These days, if something needs to last, notes, data, records I'll want in a decade, I default to boring on purpose. Markdown instead of a proprietary note format. CSV or plain JSON instead of an app-specific export. Plain text config files instead of anything that needs a special editor to open correctly.

It's not because boring is exciting. It's because boring is the format equivalent of a tool that still works after you've left it in a drawer for ten years. No batteries to replace, no firmware to update, no company that needs to still exist for it to function.

I wanted a place to write things down that wasn't a platform. Nothing here is optimized for anything. There's no algorithm deciding what you see first, no follower count, no little heart to tap. Just entries, in order, that you can read if you want to.

The page is a single file. It doesn't call out to any server, load any font from somewhere else, or run any script that isn't already sitting right here. If you save it, you have the whole thing, no missing pieces, nothing that stops working when a service shuts down.

Each entry gets its own link, so if something here is worth passing along, you can send exactly that one thing rather than the whole page.

I keep coming back to the idea that a piece of writing should be able to sit untouched for a decade and still work, still open, still readable, still make sense to whoever finds it.

That rules out a lot of conveniences. It means no dependency that might disappear, no account that might get deleted, no format that might stop being supported. It means favoring plain text over anything clever.

It's a small constraint, but it changes how you write. You stop writing for an audience that's scrolling past and start writing for someone who might actually stop and read the whole thing, whenever they happen to arrive.

Most software today is built to be checked. It pings you, it refreshes itself, it counts how long you stayed. Even well-meaning apps end up shaped by that pressure, because attention is what pays the bills.

A page like this one doesn't need any of that. It isn't trying to bring you back tomorrow. It's just here, unchanged, until I decide to add something to it.

There's a kind of relief in building something with no metrics attached. I can't tell you how many people have read this. I don't know if you're reading it now. That's fine, it was never the point.