It's Hard to Go Alone
04.06.2022

Cutting the proverbial cable with big tech services is possible, but it’s still not plausible for most people. The goals of open source remain as distant as they were 25 years ago, and it’s only developers to blame.

A few months ago, Spotify came under fire for their nine-figure contract with Joe Rogan, the podcast embodiment of clueless mediocrity, a man whose only claim to fame is making the guy at the airport bar with loud, provably-wrong opinions feel smart. Rogan’s show has often trafficked in the sort of casual bigotry commonplace in American society, racist and transphobic opinions grounded in unresolved insecurity rather than any sort of measurably objective fact, and Spotify pays him handsomely for it. I took a look at my 2021 Spotify Wrapped, the streaming service’s year-in-review feature that tells you exactly how many times you hurt your own feelings with a song. My list had largely the same songs as last year. I wasn’t using the full features of the service. And $10 monthly for unlimited access to music doesn’t feel like an ethical way to support artists, either. So I canceled my subscription, deleted my account, and banished the apps from my devices. This left me with a problem: my passion for music discovery may not be what it was in my teenage years, but I still want to listen to what I like. Moreover, I have a fairly decent collection of legally-owned music that I’ve digitized over the years. Why not rebuild my music library? I could host my own solution, set up my own infrastructure, and have exactly the music I want. I could even be inspired to actually buy the albums of those artists I had on repeat, who make fractions of a penny per stream. I would control my own data; no algorithm would be siphoning off my listening habits and constructing some profile of who some AI believes me to be. Sounds great, right? So I went looking around and clicked through some of the offerings on the awesome-selfhosted repo that tracks these things. There are plenty of free, open source solutions for hosting a streaming media player. My theory goes something like this: 1. Find a maintained FOSS media streaming app and host it on my Azure subscription; 2. Mirror my music library to an Azure Storage Account and map this as a volume in my streaming app; 3. Re-engage with music mindfully, rather than as a cheap commodity. After clicking through some demos, I settled on Funkwhale. It had the features I wanted and is fully self-hostable. I got it running locally with minimal effort using Docker compose, but this is where my success ended and where my litany of complains about cloud and FOSS begin. FOSS documentation remains elusive and out of date Documentation is rarely a developer’s favorite task, and the open source movement has always promised that with open contributions, documentation will improve over time. This has never really been the case. The Funkwhale documentation is broken and sometimes wrong. The instructions for setting up with Docker Compose work well enough, but then it ends with, in essence, “ok now go configure nginx, it’s easy.” Unfortunately, when clicking through the link for how to do that, it seems to have conflicting information on what configuration files to use, where to run them (do I run them in my nginx running container, or download these alternative files prior to standing up the containers?), or what the recommended configurations are doing. Moreover, there are some strings in the docs evidently meant to be replaced, but which were not. This means you have to understand how the documentation is built in order to understand what it is telling you to do. Not great. Cloud documentation is weak If this reads as a criticism of FOSS, don’t worry, as corporate documentation is no better at all. Reading through the documentation on how to get multi-container container instances running on Azure points you to documentation that doesn’t make any sense and doesn’t work. In this case, the docs tell you to set up an Azure container registry and use that to host your images. This is easy enough. However, they tell you to point your docker-compose.yml file to the registry you just created before pulling or building any images. This doesn’t work. Because it doesn’t work, it’s not clear what the intended set of actions is, rendering the documentation useless in the end. Containers just abstract the same failure modes we’ve always fallen prey to Containers were supposed to solve a longstanding problem by allowing us to build software as a deployable unit, rather than as a compiled application with deep and potentially conflicting system dependencies. The ideal container should only require a set of environment variables to execute, and these variables should be obvious what their purpose and relation to the application is. We’ve failed in this mission. Instead, we have simply turned the container into a soft abstraction of the application. It’s no longer enough to stand a container up; no, instead we are once again relying on bash scripts and obscure and badly documented logics to get containers running right and working together. Not only does this add complexity where complexity shouldn’t be needed, but we’ve managed somehow to turn this into another source of resource consumption. Funkwhale’s documentation says it should run with about 350MB memory, suitable for running on a Raspberry Pi. I’m sure this is true, given enough tuning. However, a Standard B1ls Virtual Machine on Azure (1 vCPU, 0.5 GiB memory) was not enough to get the dockerized application up and running. Stepping up to a B1s ($9.13/mo) was also not enough, at least not with a lot of added effort. This means that for the most basic, out-of-the-box setup, I would have to pay more to host my own instance on the cloud than I would pay for Spotify in the end.

This might not be such a problem, because…

Everything demands its own database

Funkwhale has a database dependency, which makes sense when you look at its features. It uses PostgreSQL under the hood, and, interestingly enough, Redis. This seems like overkill for a personal streaming server, but Funkwhale is designed for more scalable uses. Fine.

That would be one thing, but I also run a Monica instance (Monica is a personal CRM). Monica uses MySQL. So now to run two applications I have three completely different pieces of database tech. I could, with some work, migrate my Monica data to Postgres and then configure Monica to use Postgres. This might be enough to justify setting up a Postgres server on Azure. Which means I have to reverse engineer the docker deployment of Funkwhale to configure it to use this service. And that means I need to do more work to configure the virtual network attached to the VM in the cloud.

I have done this all before. I have done this all so many times before. My question is thus: why do I have to keep doing this over and over? Why isn’t this part of application development made to be as turnkey as possible?

Developers are developing for developers (and nobody else)

One of the things big tech did was make it easy for normal people, people who aren’t developers, to use the internet. All of the alternatives to big tech keep trying to succeed on their moral merits. Look at Mastodon. Mastodon has a lot of great features, and might be a step towards solving the many problems with social media that Twitter has refused to address. But the greater ActivityPub community, of which Mastodon is certainly a part, can’t seem to stop with proselytizing. Even if you look at the “Guide for ActivityPub users,” it tells people to “spread the word,” saying, “the most effective way to promote a decentralized internet is by using it and encouraging others to do likewise.” This may be the case, but what this ends up as is people trying to sell me on a service because it is decentralized and not people trying to make decentralized services the obvious and easy choice for users.

In other words, you are telling me to struggle because struggling is morally better. I may not disagree with this principle in general, but my most finite resource, time, does.

Mastodon was developed for developers who really enjoy designing and implementing standards, and adds only a few novel minor features to the actual social networking functionality that Twitter offers. It doesn’t really understand how people use Twitter. Static site generators are like candy for nerds. Every serious writer I know uses Substack or Medium or Wordpress. Nobody buys milk with the blockchain. Let’s get realistic about who actually uses the tech we’re building.

Open source as a movement is laden with contempt

The Code of Conduct wars of the mid-2010s revealed an uncomfortable truth about the tech industry and open source culture: developers think that we are smarter than everyone and therefore we hold immense contempt for everyone. Years ago, my friend Aurynn Shaw wrote about what she calls Contempt Culture, the tendency for communities in technology to lift themselves up by putting others down. This mindset has weaved its way into all aspects of technology, but particularly open source. Read the comments on any almost any open source issue tracker. While they don’t (usually) say it outright, the tone is clear: if you cannot figure this out, it is your fault. This issue isn’t just maintainers, but in the community as well. This behavior is found all over the comment portions of Stack Overflow answers.

Of course, this is rarely actually the case. Often, it’s because the user has a unique issue or is trying to do something that the developers hadn’t thought of yet or because the software is actually unreasonably difficult to get working. I freely admit that I am not the best developer in the world. There’s a lot I don’t understand. But I am intelligent enough to know two things: first, I can figure it out if I spend enough time on it; second, that my time is way too valuable to waste sinking it into reverse engineering source code or making sense of outdated or incorrect documentation. Hundreds of millions of people are on Twitter, tens of millions are on Spotify. A partial explanation for their success is that it is extremely easy to onboard onto these platforms.

If you want me to use your software, make it worth my time. One easy way to do that is to not ask for very much of it.

Wrapping up

This is a long-winded way of saying that I really, really want to find alternatives to big tech. I want to control my own data. I have the skills to be able to do it. I still think it should be easier than it is.

Funkwhale is a lovely piece of software. Monica is a lovely piece of software. I could pay for managed/hosted versions of both, if it was only a matter of using the software for the features. But I want a world where true decentralization of data is possible, which means I want to hold the keys to my online presence at all times. This is still too hard, even for experienced technologists.

Choosing to leave Spotify and Twitter were decisions I made from my own set of personal principles, which involve criticism of the specific decisions that the executives of those companies have made. Choosing to go full IndieWeb means taking on an open source philosophy that de facto embraces independence over usability and accessibility. Could I personally fix the issues I have with these approaches? Sure. It’s open source, after all. But do I find it worth my time? Not at all. At the end of the day, I’m the user. I want to be convinced that the approach is better. Sell me on it. Prove it to me. Don’t do it by telling me about the moral worth of open source or federation or any of those things. Care about my use case. Value how I value my time.

Posted: 04.06.2022

Built: 05.07.2022

Updated: 05.06.2022

Hash: 11200a1

Words: 2030