Accidental complexities of the IndieWeb

2025-01-08 14:30 • 843 words • ~4 min read ⏲

V.H. Belvadi called the IndieWeb community to reflect on the importance of friction. As with all metaphors, there's a risk of talking past each other, so I first want to take a cursory look at af few examples of what friction looks like in the context of publishing on the web.

Bill Beaty, in over 30 years of running Science Hobbyist, has created lot of content. Answering the question how could create so much he writes: I live on the internet, in an ancient unix shell account [..]. If I should ever type up a little textfile during other activities on the computer, it only takes me ten seconds to put it on my webpage. Unlike most people, for me the barriers against publishing on internet have entirely evaporated. Such a way of working is of course a trade-off. As websites grow over time, usually at one point one may want to change some part common to all pages, like a header, a footer, the side navigation, which is an easy task if you use a content management system, not too hard with a static site generator, and, if everything is rolled by hand, probably comes with so much friction that in the end you would not even bother to try.

But tooling itself is also not a "free lunch": you have to keep up with it, and tools can change in undesirable ways. It might lock you in, so that swapping it out also can present a major cause of friction. My friend Lars-Christian recently decided he had enough of Wordpress, so first he wrote his own static site generator, and then, as he understandably did not want to pay a premium for Wordpress hosting anymore, had to move his blog to a new host. Once more, a such decisions exemplify trading one kind of friction for another one. Linus Lee argues that tools that parallel our minds can multiply our creativity and productivity, by removing the invisible friction of translating between our mental models and the models around which the tools are built.

Next, take Rakhim, who wanted to revive his website. In his own words, he just wanted to write again. But his tools then again were a cause of friction: after installing a new version of Hugo things broke. After 25 minutes of attempts to fix it I though "yeah, that's it". Now, in what I can with the utmost admiration only call a proper yak-shave, instead of abandoning the thought of writing he decided to building out a blogging platform to his own ideals. But, it would go without saying, one is not done dealing with friction once a platform is built, as shows the example of Herman Martinus, the creator of bearblog. When the free tier he offers started to attract too many spammers and SEO farmers (no good deed goes unpunished...), he had an ingenious idea to put friction to good use to deal with them and introduced The Frustration Loop.

Friction in the non-metaphorical sense is a natural phenomenon, and - as any force of nature - indifferent about societal or moral categories. It applies to all, for good or for bad. In the context of publishing on the web it is no different. The orders of magnitude difference between the billions of people on silos compared to the maybe some ten thousands on the independent web is a reminder that of one of the core principles of the indieweb, that UX and design is more important than protocols, formats, data models, schema is both valid and collectively neglected by the community. The silo platforms, even if their driving motives are of a mere pecuniary nature, demonstrate that simpler ways are feasible. I consider this type of friction to be similar to what software engineers, after a notion introduced in Fred Brooks' seminal essay No Silver Bullet, call the accidental complexity of a system:

[T]o see what rate of progress we can expect in software technology, let us examine its difficulties. Following Aristotle, I divide them into essence — the difficulties inherent in the nature of the software — and accidents — those difficulties that today attend its production but that are not inherent.

Just as Brooks notes that advances can do no more than to remove all the accidental difficulties from the expression of the design. The complexity of the design itself is essential, so is the essence of publishing on the web not the tools that are needed to build and serve a stream of bytes to be rendered in the browser. The essence are the ideas itself. The authors of the classics of literature, the influential thinkers, philosophers and scientists did not concern themself with printing, typesetting or bookbinding. They may or may not have held these crafts in high regard, ultimately they were inessential to their work.

If the accidental complexity of publishing on the web were resolved for good, we would be, in the words of William Zinsser, still stuck with the same old job of saying something that other people will want to read.