Joel Dueck ·

Friction in publishing

If you’re going to start publishing a blog, a podcast, whatever, there will be friction in three places:

  1. Setting everything up
  2. Every time you actually publish something
  3. Maintenance, upkeep, and preservation

Imagine the end product: every detail of how you want your thing to look and work. If you want to be able to handle super-heavy traffic, or make site-wide changes quickly, or to migrate to a new service provider, include those things in the scope. Now, for you specifically to implement that end product, a certain total amount of friction is involved, and it is conserved across these stages.

If you actually want to lose some of the total friction, you must reduce your project’s scope. If you use tools made by others, they take on a lot of the friction, but they control the scope.

Friction profiles

Starting a blog on Medium, or newsletter on Substack: Almost no friction when setting things up (phase 1) or when publishing things (phase 2). The service decides how things look and work, not you. Upkeep (phase 3) is free as long as the service remains viable and as long as their terms of use remain acceptable to you. If any of that changes, and you still want to keep your thing, suddenly all the friction you avoided is dumped on you at once, as you try to migrate your content somewhere else.

Starting a blog with a web-based CMS on your own server: A high amount of friction setting up the server, the database, the CMS. When it comes to publishing, you’re just typing into boxes in your web browser and clicking buttons: as easy as it gets. Maintenance is somewhat higher in friction than if someone else was responsible for the server, but can go on essentially forever. As long as they have power and a network connection, servers will carry on for years even with extreme neglect. Just make sure your backups are working (the hardest part). In general: a lot more friction in exchange for a lot more control.

Starting a blog with a static site generator on your own server: High friction in phase one, but you can skip the database and CMS setup. Publishing things is more work: you need access to your site’s source code, you need to remember a handful of special commands, and hopefully you enjoy using a plain text editor. Maintenance — same friction as the scenario above.

Starting a simple website with hand-edited HTML files hosted literally anywhere: An underrated option. Sure, a little more manual work if you want a blog with consistent formatting and an RSS feed. But having “just press CTRL+S” as your deployment pipeline is kinda sick. You can schlep your files nomadically to any dumb, cheap/free service as often as you need to. You are invincible, as a stream of water is invincible. Watch out for scope creep the first time you want to change your site design…

Starting a blog with a static site generator on someone else’s server: Sure, you still have high setup friction, and pretty high publishing friction. But in addition you also get the high maintenance friction that comes with adding a dozen extra layers to your software stack, many of which are controlled by others and in constant flux.

Joining the IndieWeb: If you want webmentions on your site, you might just quintuple your phase-one friction. Plumbing is one of the challenges, coherent presentation is another. Hopefully you get it all done in a way that doesn’t leave you completely open to spam. Good luck!

Starting a blog with a static site generator that can also be published to print: as frictiony as web publishing can be, print publishing is vastly more so. Combining the two adds so much more work to setup and to posting. Everything you publish now has to have both mediums in mind. Your software stack just added several layers. But hey, when you’re no longer alive, you can turn everything off and you’ll have all those printed books laying around, just existing, with no friction at all. (You did actually get around to writing and publishing something with this system, right?)

A frictional history of the web

When the web first started, we were creating each individual HTML files by hand every time we published something, and this was very tedious. But it was easy to get started. The scope of what we were trying to do was small, so there wasn’t much friction to spread around, but all of it went into the publishing step. Low setup, low maintenance.

Then we wanted to do more: we wanted to separate content from presentation; we wanted to have tag clouds, we wanted RSS feeds. No way were we going to keep loading all that new friction into the publishing step, because it was also obvious that we should be typing less. So we invested time setting up and maintaining databases, CMSs, etc. These took nearly all the friction out of the publishing step. We spent time setting up and tinkering with the CMS instead.

At some point some people started feeling nostalgic for the old days, and started saying things like “back to plain text” and “words shouldn’t live in a database” (which is a very dubious distinction) but they still wanted to do all the same things we’d been doing, so the static site generators became popular again. And it was just as complicated as the other CMSs had been, but with a lot of friction added back to the publishing step. Maybe — maybe — a bit of the friction got taken out of the maintenance side of things, because we got backups for free. We didn’t have to maintain MySQL anymore but the static site generator itself was happy to take up all that maintenance time.

When normal people who had lives finally got online, they mostly said screw all of that and went with tools built and maintained by others, and I can’t say I blame them.