It's actually not too bad to run, it's just that my community instance has grown a lot, and is close to four years old at this point. Issues crop up, I mostly wrote this guide to share some insights on how I deal with things.

Let me think...

• Flohmarkt is like Craigslist or eBay
• Honk - Ultra-ultra minimalist
• Vocata - a general C2S-enabled server that allows you to throw any kind of Vocabulary you want at it. Could be useful for mocking up client apps.
• Wordforge - federated novel-writing
• SkoHub - Some kind of federated knowledge discovery system?
• GreatApe - an OBS-like federated video thing that you can have live audiences with.

That's just what I could find from scrounging around, I know there's more.

Good to know, I was wondering about that!

It's less expensive than you would think. Object Storage is actually really, really cheap in a lot of cases. I host a PeerTube instance, and while it does cost me money every month, the cost is decently offset by recurring donations, as well as the savings that Object Storage brings.

Jira. In the Software-as-a-Service world, it's often the tool of choice by Product teams to track issues, by breaking everything down into stories.

It's a horrible, slow, janky mess. The interface is confusing and poorly laid out, you can easily have too many options all over the place, and how its even used can vary dramatically from one company to another.

Salesforce is also trash for very similar reasons. How Sales people around the world all vouched for this thing is beyond me.

Hey everyone, I just wanted to thank you for the lively conversation and thought-provoking insights. We don't have to agree on every point (or at all), but I've decided to synthesize a lot of thoughts and ideas from these conversations into a blog post: https://deadsuperhero.com/2024/03/economic-musings-on-federated-networks/

The reason that an open source developer might experience burnout are myriad, but can include:

• Lack of compensation
• Insufficient tooling or project infrastructure
• A high ratio of operators to maintainers
• Lack of a concrete roadmap, quality documentation, tests, essential resources
• Lack of an onboarding process for new contributors
• Inability to reconcile differences with contributors, leading to hard forks or exodus of contributors
• Intractable architectural issues that require substantial engineering effort, possibly more than the maintainer can actually contribute

As someone who has done Community Management for an open source, decentralized communication platform (Diaspora), I am familiar with all of these things. This shit is hard, and I am not denying that Lemmy devs have done a lot of good work.

The problem is actually much simpler than you're making it out to be. For a social platform, which depends on interconnected self-hosted communities to succeed, you absolutely have to build in the tools and utilities necessary to deal with all the crazy shit that comes with the territory. Ignoring this causes a cascade of problems that gradually get worse the longer they remain unaddressed.

The devs are surviving on crowdfunding and grants, and doing the best they can with that. That's commendable! They probably need more of both to have their needs fully covered. But don't get it twisted: receiving proceeds for your work is not the same thing as working for free.

While I think you're correct about it ultimately being their project, and that users are in no place to demand or expect anything, this thing takes on whole other dimensions once a project is all about building a social platform. Particularly one where volunteers host part of the network themselves.

It's one thing to look at some random demand to write everything in a P2P architecture because DNS is too centralized. When I worked on Diaspora, I literally saw people demand stuff like that, and laughed it off. I'm trying to build a platform that exists today, not some pixie dream bullshit compromised of academic circle-jerking.

But when it comes to basic table stakes for participating in a network that already exists, things change a bit. This is especially true when you're connecting to a global network that has:

• Hate Speech
• Targeted Harassment Campaigns
• Child Pornography
• Extreme Gore and Violence

Suddenly, it makes a lot of sense to say "you know what, admins are going to want to filter this shit out, maybe it's reasonable for them to have some tools and fixtures that are part of core."

Unfortunately, these devs are the kind of people who scream angrily when someone says "Hey, this thing doesn't actually respect local image deletes / GDPR stuff / content deletion on account deletion". To me, that's fucking insane.

Yeah, I'm pretty excited about it. Apparently the Pangora (Lemmy fork) dev joined forces, and the new UI is starting to look great.

https://bytes.programming.dev/notes/9qi6rc2avj3gn9dx

It's technically possible, just really, really hard. One example of a successful migration was the transition from calckey.social to firefish.social. It was a massive, extremely difficult undertaking, though.

A big problem involves how user identities are tied to instances. If there were a way to decouple that, I think a lot of the pain goes away.

Yeah, they didn't want their money going to the Taliban, and it's a little shaky as to whether the Taliban's Ministry of IT would take a stricter content enforcement on their ccTLD. For a while, it was only possible to renew domains, not buy new ones.

Still, I stuck with the title because the Taliban is still the reason.

For all intents and purposes, the dev did state their intentions on releasing the code "when it's ready", and was super active in working on it. Not releasing, and relying on one server running a specific upstream branch were definitely mistakes, 100%. But, I think the dev legitimately believed they would hit that target, which was a prerequisite for releasing.