On self-hosting being a patch

Recently the blog post Self-Hosting Isn’t a Solution; It’s A Patch landed in my reading list via Lobsters.

It was an interesting read and I recommend anyone interested in tech decentralization and regulation to check it out, but two thoughts came to mind:

First, perhaps most of the blame is in the concept of “self-hosting” itself. It is too narrow for what it really represents. Something described as self-hosted can most of the times not only be individually-hosted but community-hosted. You can host it yourself and bear all the associated burdens alone, yes, but the way the article portrays this as the only possibility is a bit of a straw man. “Self-hosting” also implies open-source software that you could run for a whole community, a town, a country, a continent, or the planet if you can.

It implies that not only the software’s source is available and its license is a free software license, but that it is designed in a way that you should be able to run it to its full capacity yourself. How large that scale will be, how many people are running it, and how it gets funded and managed can take multiple forms and, if regulation is to be the answer, that is one possible structure (government) that can fund such projects, though it doesn’t have to be.

The second thought is that regulation and self-hosting are not opposed to each other. In fact, they are not at odds at all. So to point to regulation as the better solution and self-hosting as a limited one may pose the illusion that we have to choose – we miss that they actually are far more effective together. That is, unless your goal is just to reform the big-technology-corporation-owns-everything model. For that, regulation alone is much better, with all the long-winded bureaucracy, ceremony and always-open possibility of a reversal.

The regulations in Europe during the past years have surprised in how strong they are in favoring interoperability and some decentralization. Also, more then a few stories about European tech funds putting money into open source projects have crossed the same channels that landed this article among my browser tabs.

Neither of them is, alone, the solution, as you could also see regulation as a lubricant, a way of legitimizing the predatory practices of everyday capitalism by putting it into a nice, confined setting and stamping it with the seal of compliance, however you are able to ascertain it, while still allowing most of the damage to happen, be it a loophole, a cover-up or simply something that didn’t happen to bother the regulators to begin with.

In this sense, the act of building completely independent platforms, able to operate using their own software and infrastructure, comes from a whole different angle and a much more incisive one at that. It works not simply on the level of “how can we make these companies play nice” but of “how can we not depend on these companies to begin with”. This is not solely a concern about reliability, as seen when the article notices how small and underfunded decentralized projects can simply vanish due to lack of funds or inability to stand up to legal threats, it is a concern about privacy and autonomy too.

While it is always sad to see an open-source project or community close down, this is also a community that was built on foundations of interoperability and that values the capacity of taking your data out and moving it elsewhere when needed. I do think platforms like the Fediverse could improve in this regard, as, for instance you can’t always move your content with you as easily as more portable data such as follows and followers, but that is one of many issues we can work on and move past.

Conversely, when a company goes out of business or sells out, a completely different situation is presented to you. Your data may simply be “transitioned” to the infrastructure of another company and the way you interface with it may completely change. Or it may have been built on fully proprietary software and data formats that will essentially become useless a few years after the company shuts down. Or it may simply vanish and you never had a way to get your data to begin with.

Our systems do not need to be high-maintenance, intensive on resources and energy needs. They don’t have to answer every request with availability and latency that measures up to however many nines or zeroes are the current industry standard. They have to attend to the needs of those who are using them, which can be much less demanding. We can run both infrastructure and software at more human scales and learn other ways of growing or shrinking, and we can also scale to high performance and availability too. This is what the concept of a network enables after all, but it is often used to centralize and create dependency instead.