The Fediverse As A Wedge to Free-Software

#tech #FOSS

Table of Contents

In the interest of getting straight to the point, I won’t be wasting too much ink on turning this into Yet Another Explainer of the Fediverse and how it works. If you need a primer, The Verge already wrote a decent rundown of everything a beginner would need to know.

The following was adapted from part of a talk given at the FSF’s LibrePlanet 2023.


As an advocate for free-and-open-source (FOSS) software, I’ve long believed in the value of picking our battles strategically. The landscape of tech is always shifting and it’s not just the big companies that need to keep their pulse on changing trends, trajectories, and demands. If we want to gain influence and spread our ideas to the rest of the movement, it helps to think opportunistically.

This means identifying areas where we’re likely to make the biggest dents for the least cost, and invest our efforts where they’ll bear the most fruit. It often won’t be obvious or readily spelled out for us where it’s best to strike, but that’s why it helps to think outside the box.

Laid out below is one of these areas of opportunity: the Fediverse. Between 2018 and 2023, a lot of my involvement in the FOSS space has been concentrated on building up the infrastructure to make open, decentralized social networks possible. This essay exists to answer the question of “why”: what the Fediverse can provide to the larger free-software movement as a whole and why it’s worth putting in the work to build up.

Think of this almost as a case study in what the process of assessing the environment, finding windows of opportunity, and building up effective solutions entails. Even though this essay is focused on the Fediverse, the broader principles and mentalities apply everywhere.

The Breakdown of Proprietary Social Media

In 1985, the GNU Manifesto was released. It would be written within the context of a world that was still being introduced to the personal computer, and one in which now-old development practices (waterfall methodology, one-time software license fees, closed-source development) were still fashionable.

This was the environment in which the GNU Project started. The tools provided by the project (and its long-term goal of creating an entirely free OS) met a market that was emerging and provided free solutions that directly challenged the holes present in proprietary design. A lot has changed since then. In the age of the cloud, software freedom is no longer just about the code you run locally on your machine. DRM, networks, and JavaScript have all become new vectors for bad actors to infringe on your freedoms.

Computers are no longer just a tool for a certain set of professionals to use – they’ve become deeply embedded into our daily routines, and have come to reflect the world around us. Kids talk with their friends over Instagram, graduates apply for jobs on LinkedIn, political and cultural elites network on Twitter, and relatives keep touch via Facebook. Back in the day, computers provided an escape from the real world, and now they are the real world. People who otherwise have no technical proficiency or interest are now online. We have an economy that now rides or dies on the back of online commerce and tech. And with each step into this new world, we’re given less and less choice to fully opt out. Social media powers a lot of this new world, but that’s not to paint it as some sort of emerging sector. The platforms of the 2010s and the patterns of their design are well established by this point, but even then, it’s now that the cracks are really beginning to show.

This is most notably the case for the major social media platforms of the 2010s. Twitter has famously been subject to a political tug-of-war that spiralled into a laundry list of high-profile screwups. Reddit has begun gating its API access, bricking support for third-party apps in the process. Under the pressure of App Store policy, Tumblr controversially issued a sweeping ban on “adult content” which led to an exodus of the site’s userbase. Ironically, in the years since, the site now deals with a plague of “porn bots” which spam NSFW ads across users’ timelines. Facebook has been dealing with its own flood of AI-generated slop, enabled thanks to the platform’s own monetization programs. And it’s only fair also to mention the long-standing issues YouTube creators have had with the platform’s arbitrary policing of copyright and demonetization. The big new winner of the 2020s – TikTok – completely strips away nearly all social functions from its interface. Instead, it provides a neverending stream of pure Content™ for its users to digest.

Whether its due to the emergence of new technologies (such as generative AI) reshaping the economy of information, the spambot arms race reaching its natural conclusion, or years of complacency finally rearing its ugly head, it’s clear that the web of today is in a shakier spot than even the web of ten years ago.

But if there’s any silver lining to shaky ground, it’s that it’s always the most ripe for a shake-up. The old FOSS critiques weren’t just some old-fashioned lecturing, they’re entirely vindicated. People may have dismissed our warnings, but given enough time even abstract concerns end up manifesting into concrete ones. This current breakdown of Web 2.0 and its infrastructure needs to be studied if we want to best take advantage of it. We need to understand how user demographics have changed, how the economics have changed, how development has changed, and how the ways in which we use tech have changed over the past forty years.

But even more importantly, we have to be able to understand the principles which underly proprietary design and why they create the conditions for the failures we’re currently seeing. Centralized ownership leads to site-moderation becoming a political football. Opaque, closed-source algorithms serve recommendations that aren’t in line with our needs. Walled gardens make the web harder to search and information harder to preserve. Ad-centric monetization encourages the proliferation of spam. A complete disregard for privacy has fomented a hotbed of government surveillance and repression.

What keeps these platforms afloat is that they are “too big to fail”: it’s difficult to talk about social networks and their dynamics without also talking about the phenomenon that fuels them: network effects.

The network effect is a phenomenon in which a platform or service gains more value the more users it has on it. Irrespective of what you think of the interface or code, you may still have a Facebook or a Twitter account because everyone you know is already on there. If you’re looking for your friends, you have to go where your friends are. If you’re looking for an audience for your content, you have to post where people can see it. And if you’re looking for content, you have to go where its posted. This, of course, creates an incredibly vicious cycle in which new users are continually encouraged to join large platforms and discouraged from joining smaller ones.

This ends up killing smaller platforms and creating an environment in which a single company is able to assert complete dominion over their given niche. These platforms may start by showing care for user interest, but the billions in VC dollars these companies burn in order to sweeten the pot is invested with the expectation of eventual payoff. Once they’ve safely made it as number one, they can begin to start screwing people over. As Cory Doctorow explains, this is a widely-documented phenomenon:

Here is how platforms die: First, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die. I call this enshittification, and it is a seemingly inevitable consequence arising from the combination of the ease of changing how a platform allocates value, combined with the nature of a “two-sided market,” where a platform sits between buyers and sellers, hold each hostage to the other, raking off an ever-larger share of the value that passes between them.

Federation as a Solution

In the face of these abuses, many have tried to start their own alternative platforms, but also many have failed. Gab, Steemit, HIVE, Parler, BitChute, the list goes on. For all of them, the network effect was the big hurdle to figure out to overcome. Sure, initial press might bring a short wave of sign-ups, but in order to turn that hype into a sustainable community, extra steps have to be taken. How do you convince people to take a chance on a brand new site when nothing has yet been established on it?

Some platforms directly will pay specific creators to switch over in exclusivity deals, other platforms may make use of cryptocurrency features to promote a new method of monetization. In each of these cases, brute force seems to be the strategy at play. The hope that with enough money, you might be able to replicate the same growth trajectory as the original platforms, and end up using their strategies to take their crown. But, as the launch of Threads has shown, even all the money in the world can only get you so far.

What separates the Fediverse is its willingness to forego that direct competition in favor of leveraging a backend architecture (ActivityPub) that’s entirely unlike what most platforms use. Federation provides both the redundancy and freedom of decentralization while also being able to still reap the benefits of a unified feed. Instead of having to trust the goodwill of platform owners to moderate in the ways you want, you can either find a host that either aligns with what you’re looking for or spin up your own. Instead of relying on one central provider to bear all the server costs, various smaller hosts spread out the load amongst themselves.

This creates an environment in which moderation is no longer just a question of ownership or trust, but now can become one of user control. Communities have the tools to exercise freedom of association, by setting the rules for their own instances, and deciding the terms on which they either split from or block another instance.

This sort of design can end up promoting a culture where individuals are in an environment surrounded by the values of free software and see the ways in which it is directly relevant to them and their communities. It creates a social graph in which a large pool of technically minded users develop interfaces and tools, administer instances, and bring over their less technically-minded peers into onto platforms, supplying them with their onboarding needs.

This is all made possible because ActivityPub is designed with a protocols-not-platforms approach in mind1. It doesn’t force you onto one app, one interface, or even one platform. On a conventional social network, splitting off because you have issues with the host or using a different piece of software because you prefer its design would come with the cost of dividing the original platform’s network and having to start from scratch with the new one. Federated services don’t run into this problem because they still share the same protocol: if anything, the added redundancy makes them stronger.

The ActivityPub protocol is generic enough that all sorts of applications – from video sharing to book sharing – are able to communicate with each other even as they harbor wildly different designs.

Federation As a Bridge to New Possibilities

It’s not hard to imagine how someone might look at all this and ask whether or not the Fediverse – despite how willing it is to reimagine the backend – is too willing to simply clone the front-facing aspects of how other platforms are designed. A lot of people already do.

However, in the case of creating an alternative to an established, centralized, commercial social media platform, one should consider whether the only problems that exist in the established platform have to do with centralization, advertising, and algorithms. If the answer is yes, creating a Twitter alternative is as simple as making a microblogging platform that replicates most of Twitter’s functionality with a few tweaks and a new coat of paint. However, if there are issues that stem from the design and user interface of Twitter itself, it is far less clear that creating a decentralized version of Twitter will cure it of all of its ills.

But I’d like to push back on this a bit. There is real short-term value to using these designs in order to hook people onto the protocol.

As we laid out in the last section, there is a widespread state of crisis going on within the industry as a whole. Each case of upheaval brings with it all the backlash from their respective userbases. And it’s during these moments (Twitter buyout, TikTok ban, Reddit API blackout, YouTube ad-pocalypse) that you can take the outrage and channel it into full-on conversion.

People instinctually respond to anger at a platform by looking up alternatives, and being able to have a ready drop-in replacement is a lot easier of a sell than something radically new.

But here’s the kicker: ActivityPub is a protocol. It’s software-agnostic. Once you have people on the network, it becomes a lot easier to begin experimenting with different designs, because experimentation doesn’t cut you off from the network. You can still try out weird servers without losing your friends, if anything it encourages you to.

ActivityPub does have platforms like Honk, whose design (no likes, no faves, no polls, etc.) are a bolder challenge how social media works, but even those platforms benefit from the flow of users and resources those “Fediverse clone” platforms bring in.

And even on a more basic level, the clone platforms are a lot of people’s introduction to concepts such as federation, instances, protocols, and self-hosting. Whatever we can do to bridge that mental transition for the wider public is a key step towards undoing the proprietary grip on public mindshare.

And of course, we shouldn’t neglect the benefits that do exist in these designs. Twitter’s design has long been incredibly suited for professional networking. Just ask any academic, journalist, politician, or artist. The design of its profiles, feeds, messaging, and discovery system fits incredibly well for these specific purposes.

Similarly, Mastodon – thanks to its recent popularity boost – is starting to turn into a sort of central hub for all sorts of organizations and individuals involved in or adjacent to the FOSS community. It’s very easy to DM people, collaborate with them, and keep track of what they’re working on. Ensuring that FOSS activists can actually network on platforms they own, trust, and can shape the culture of is absolutely huge for building up institutional power.

One can also look at Reddit and how design works great for promoting calls to action, or promoting work. Lemmy provides a similar function, but one that’s less gamed and optimized by companies due to its ecosystem being comprised of much smaller communities with tighter moderation.

The Challenges Facing the Fediverse

That’s not to say the Fediverse isn’t facing an incredibly uphill fight in terms of its future adoption or that it’s not without its issues.

Well, what kind of issues are we talking about here? I think the best way to explain is to take a look at a case study.

In 2022, Elon Musk purchased Twitter. The site has had its problems before, but this change of leadership (and the changing policies that ensued) began to drive people off the platform in waves. They started shopping around for an alternative, and a lot of people chose to settle on Mastodon. This didn’t last too long though, as the site struggled to retain its users after a few months in.

Taking a birds-eye view, there’s some key takeaways to note about the incident:

  1. Windows of opportunity come suddenly and unexpectedly. The circumstances that even created the situation in the first place were impossible to predict. It entirely came down to the arbitrary, personality-driven decisions of one man.

  2. Making long-term bets ahead of time can help you be ready even if you weren’t prepared. Mastodon still managed to seize on this moment despite not having any warning, because they spent the years to build up both the infrastructure and pre-existing userbase ahead of time. Mastodon was started in 2017, years before Elon buying Twitter was even in question. This was by far the site’s biggest advantage. Other competitors of the time (like HIVE) fared even worse because they weren’t able to scale up overnight2.

  3. People wanted a Twitter replacement. The majority were focused on the experience first, and not the underlying principles. Out of that pool, some would come to dig into and appreciate the principles, but, at large, the bar people were judging Mastodon at was relative to Twitter. Not relative to team size or “good for a FOSS project”, but a question of if this experience comes as intuitively and reliably as Twitter.

Judging by those metrics, Mastodon was definitely left with a few glaring issues.

  1. Confusion surrounding sign-up. The instance model Mastodon relies on for its sign-ups can be incredibly overwhelming if users are left to their own devices to find, vet, and select a good instance. Keep in mind a lot of these people haven’t even yet wrapped their head around what an instance even is. During the exodus, a lot of the large Mastodon instances shut down their registration which often made it unclear as to where one would have to go in order to even join the network. This meant a lot of people were already turned away at the door before they even got a chance to try.
  2. Lack of robust spam filtering tools absolutely exacerbates the above problem. Admins have to manually vet spam often in order to keep it at remotely manageable levels, and instances which are both open and not constantly moderated will often get flooded with spambots. This often discourages instance owners from making registration easy and can funnel people to join instances which are flooded with bots.
  3. Half-baked instance migration also often means that while you can switch instances, it can often come at a cost. Mastodon specifically does allow for migrating followers and redirects, but post migration still has not been handled for years. There’s also no system to rescue your profile should the instance just go down one day.

Each of these problems make it a pain to understand Mastodon, a pain to get started on Mastodon, and sometimes can punish you for using Mastodon on the wrong instance. It’s understandable why a lot of people left the site with a sour taste in their mouths.

And to be fair, some of these issues do point to serious protocol-level problems that make finding solutions more difficult.

Unlike ATProto/Bluesky, ActivityPub lacks nomadic identity and does not have nearly the same level of protocol-level support for decentralized identifiers or account portability3.

Other common charges leveled against the architecture include its pub-sub model adding a lot of complexity to implementation and not fitting a lot of the use-cases without a good deal of hand-hacking on application developers’ part. This can lead to situations like one where Mastodon’s sheer size pushes other devs to adopt its spec modifications at the expense of the original spec.

But that’s not to say there aren’t things that can be done to either mitigate or handle these issues in the short term4. Improved search tools and expanded options for registration (such as invite-link based ones) could go a long way towards smoothing over the signup experience. Expanding moderation tools and laying the groundwork for more robust spam-detection systems can go a long way towards dealing with the spam problem.

In some cases, like that of instance migration, it gets trickier. This issue is arguably the top priority for the platform and work has been done (and eventually implemented in other Fediverse platforms like Misskey) but the Mastodon team has generally has either ignored or declined requests to implement the changes.

In some places, you do see the community actually show a capacity to pick up the slack where an official solution doesn’t exist. Tools utilizing Mastodon’s API helped allow for post-scheduling, cross-platform bridging, and expanded mobile app support all while the official devs were still working on adding support.

But despite those occasional steps forward, it all points to a larger problem, one which goes deeper than the protocol level. The Fediverse is lacking an institutional apparatus to identify and prioritize problems, determine the timetables at which they would need to be fixed, and then gather together and allocate the necessary resources to fix them.

A lot of these issues have band-aids or quick-fixes that could be turned around in a matter of a couple months: enough time to be able to respond to massive sign-up waves without missing the train.

Problem is people who want to help don’t know where to help, people who are working don’t have many common forums to ensure that they can effectively coordinate their efforts, and there isn’t really a broader discussion about priorities and vision being had.

This is something the free software movement absolutely can work towards providing5. Organizations like the FSF are best positioned to begin reaching out to, networking, and supporting the people who have the ability and are willing to fix these issues.

Creating a pipeline that’s able to either introduce people to work on these projects or support those who are already doing the heavy lifting would do a great deal both to demonstrate the free-software movement’s relevancy to the modern world and to help cultivate a new generation of talent as they act out their ideals in real-time.

By providing a nascent community with the tools for coordination and recruiting that they just do not have but need to solve their problems, you help bring them into the fold of the larger movement.


  1. The existence of this bottom-up culture is the main advantage the Fediverse still has over competing networks such as ATProto (powering Bluesky). The current ATProto ecosystem is overwhelmingly (even moreso than Mastodon) reliant on a single instance, single service, and a narrow set of developers to provide for its userbase. Having a slower, more organic growth with a founding base of technically-minded users probably helped in this regard. ↩︎

  2. Both Threads and BlueSky would only be ready for widespread use years after the incident, as they had to get their wheels spinning as the incident was occurring. Unfortunately Mastodon wasted a lot of that lead with slowness to resolve issues, but for a good while there, it had a serious shot at leveraging the situation to become the main Twitter competitor. ↩︎

  3. Your username is also your identifier, meaning that also unlike ATProto, you’re unable to rename your handle after you’ve made the account. ↩︎

  4. Bluesky also has its own protocol-level issues, but it effectively utilized its duct tape in order to deliver a Twitter-matching product quickly enough to meet the moment. ↩︎

  5. 4/17/2024: I have other work exploring specific ways in which this can be done, but they still need to be adapted to blogpost format. Footnote will be updated shortly when the blog has been updated. ↩︎