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, etc.

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 can use tools made by others to do some, or all, of the work, if they exist. The tools you make and/or use determine how much of the total friction is fungible across the three areas.

A frictional history of the web

When the web first started, we were creating each individual HTML file 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.