Fork it! It's time for a Mastodon hard fork (UPDATED)

Last updated May 8. See the update log at the bottom for more details.

Join the discussion on Mastodon!

"A hard fork is when a group of developers disagrees with the direction of the project and decides to create a divergent version more in line with their own vision."

– producsingoss.com

A Mastodon hard fork that focuses on safety, community, accessibility, and working well with others has a great opportunity to improve safety in the fediverse, the dynamics of the Mastodon ecosystem, and fediverse software development in general.

• The official Mastodon software has a long history of not prioritizing safety or the needs of small-to-medium size community-focused instances, so a a hard fork has a chance to make rapid progress on all these fronts.
• A hard fork is also a chance to establish a new culture, with more inclusive environment that encourages broad and diverse participation and a commitment to a more consensus-oriented decision-making process.
• A hard fork can attract volunteers who aren't interested in working on the official fork, and tap into additional funding.
• If the new hard fork starts with a goal of working well with others (volunteers, existing and new forks, apps, instance admins, and other fediverse software platforms) it can help the broader ecosystem as well – including the official Mastodon fork as well as newer platforms that are focusing more on safety from the beginning.

Of course, a hard fork is challenging. As clar fon says

"sorry but the answer to "why is there not a fork yet" is last time we tried literally no one wanted to help (roaring applause for the cause, crickets when it came to doing shit), there was a fucking pandemic, and the only people on the team were too disabled and burnt out to help out, especially with zero support in their endeavours"

This time, though, there are some big differences. Most importantly:

• The wave of interest in the fediverse – with software like Ghost, Wordpress, Flipboard adding integrations as well as innovation from fediverse platforms and apps – means that there's more funding available.
• Mastodon's embrace of Threads (the new social network from Facebook's and Instagram's parent company Meta) increases the urgency for a hard fork for the wide swathes of the Mastodon ecosystem that want nothing to do with Mark F***king Zuckerberg and his social networks – and, since Meta allows anti-LGBTQ+ hate groups and bigotry, increases the urgency of focusing on safety for everybody using Mastodon

It's worth highlighting that a new hard fork complements the official Mastodon fork, which is likely to remain a better alternative for large, Threads-friendly instances like mastodon.social. But Mastodon has a very complex support matrix, a lot of technical debt in the code, and a lot on its plate including quite possibly having to devote resources to the Threads integration.⁰ A hard fork has a chance to make rapid progress. And if the hard fork can establish a more inclusive culture, that can also help the official Mastodon fork evolve its culture more quickly if it wants to.

There's a lot to discuss here, so this is a looong post. If you're already convinved that a hard fork makes sense, feel free to skip ahead to A lot of open questions - and a lot of potential upside. And more generally, if there are some sections that interest you more than others feel free to skip around.

Contents

Part 1

• A missing fork in the landscape
• Okay, but why a hard fork?
• There's a big elephant in the federated room (and I don't mean Mastodon)
• An opportunity for broad participation and a cultural reset

Part 2

• Safety is an especially good area to focus on
• There are also a lot of other areas for improvement

Part 3

• It's not as easy as it sounds ...
• But it's not like it defies the laws of physics!
• What about funding?
• Make sure most of the funding goes to Black, Indigenous, Muslim, trans, queer, and disabled people

Part 4

• It's not an either-or situation
• A lot of open questions - and a lot of potential upside
• Stay tuned!

A missing fork in the landscape

"[T][he fringe development scene on Mastodon ... has been the dominant force by which external development has taken place on the network since mid‐to‐late 2017."

– Margaret KIBI's Progressing Fringe Mastodev, 2019

Ever since the early days of Mastodon, forks like glitch-soc (aka Mastodon Glitch Edition), Hometown, Fedibird, treehouse, and toot.cafe have functionality that people using the official Mastodon software can only fantasize about. And even though (as KIBI notes) "there is not necessarily a strong impetus to push for their adoption across the broader network," much of today's Mastodon functionality originated in forks.

That said, these forks are all based on the official open-source software project from Mastodon gGmbH, the German non-profit¹ that holds the copyright to the Mastodon code, runs mastodon.social and the joinmastodon.org landing page, and provides the official mobile apps. Most of the 10,000+ Mastodon instances (aka servers or service providers) run the official release, including mastodon.social and almost all of the biggest – and some of the best-known hosting services only support the official release but not forks.²

One of the reasons this matters so much is that historically, Mastodon founder and Mastodon gGmbH CEO Eugen Rochko has run the official release with a BDFL (Benevolent Dictator for Life) style. In Can Mastodon seize the moment from Twitter? (November 2022), Rochko discussed why he thinks the BDFL model leads to better results for open-source projects:

"A good product needs long-term vision and it needs cohesive vision. That’s something that a committee cannot give. When you have a lot of people who have pet issues and one thing that they care about, it kind of ends up being a patchwork.... Sometimes, you need to make executive decisions about changing stuff in a serious way, which might not be popular with what most people in a committee would want."

So if Rochko thinks that functionality that lets people protect themselves against harassment (and is ideal for instances with local communities) shouldn't be available in the official software – even though it was implemented in Glitch-soc since 2017 and is available in other forks as well – too bad for people whose pet issues are privacy and community. For people whose pet issue is accessibility, if Rochko says a design decision that make the software harder for use with low vision get as a "feature not a bug.", it's not available in the official software – even though, guess what, it's been implemented in a fork. And these are just a few examples. Safety is an especially good area to focus on and There are also a lot of other areas for improvement have lots more.

This isn't meant to undercut what Rochko has accomplished. As Ro says in A Case for Community:

"To make a positive start, I want to give some props to Eugen Rochko, the original creator of Mastodon. The explosion of independent social media onto the global landscape is mainly due to the adoption of the idea he put together in 2016. It should be remembered that many people's introduction to self-hosted communities was Mastodon. In that context, Rochko deserves respect for being the door that introduced people to a new concept."

But as Ro also points out, Rochko's leadership style "has resisted the diversification of the platform experience, choosing to cling to a hard-line stance on what he feels the project should be."

A fork that focuses on safety, community, and accessibility can help change those dynamics.

• Most importantly, making the new fork's improvements available to other forks can provide more safety to people on instances running those forks.
• Ideally, the official Mastodon release will also adopt these improvements, making them available via the offical installation and hosting companies.
• If not, then instances that want to provide more safety and better accessibility to their users – and hosting companies that want to provide offerings for people who want to prioritize safety, community, and accessibility – will have an option.

Okay, but why a hard fork?

Depending on how receptive the official software project is, many of these benefits could potentially be achieved at least to some extent without a hard fork. As It's not as easy as it sounds ... discusses, a hard fork is challenging; some argue that it's not the right path. On the other hand, as I'll discuss in the next few sections, there are also some strong arguments in favor of a hard fork.

To start with, as the example of local-only posts illustrates, safety improvements that are seen as conflicting with Mastodon's vision and priorities are likely to be rejected from the official software. For that matter, even safety functionality that does appear to align with Mastodon's vision doesn't necessarily get prioritized. The recent confirmation that release 4.3 still won't make it easy for new instances to start with a blocklist that protects people from the nazis and TERFs that are active on the fediverse is a good example. Of course, it's possible to add these safety improvements in a soft fork. But doesn't it make more sense to have the base software that everybody uses be as safety-focused as possible?

Another point in favor of a hard fork is the need for the Mastodon gGmbH to balance a lot of priorities – including mastodon.social, by far the biggest instance on the fediverse with almost 300,000 active users. Over the years, I've heard from many Mastodon instance admins and users on smaller, more community-focused servers that their priorities take a back seat. Rochko's decision last year to change the signup process to default new users to mastodon.social highlights one aspect of the conflict of interest here: changes that primarily benefit mastodon.social aren't useful to other instances. And conversely, community-focused changes aren't useful to mastodon.social, so don't get prioritized – or even (as in the case of local-only posts) accepted once they're implemented.

There's a big elephant in the federated room (and I don't mean Mastodon)

"DO NOT TRUST THIS BIPED."

– Catherynne M. Valente, Mark F***king Zuckerberg Is Not Your Friend, July 2023

Mastodon's integration with Threads, the new Twitter-like social network from Facebook's and Instagram's parent company Meta, increases the urgency for a fork focusing on safety – and, for many, provides even more reasons for a hard fork.

As Erin Kissane's outstanding Untangling Threads and my own Should the Fediverse welcome its new surveillance-capitalism overlords? Opinions differ! discuss, there are arguments for and against working with Threads. For people on all sides of the issue, though, the extreme anti-trans hate groups Meta fails to moderate across Facebook, Instagram, and Threads and Meta's history of making money from white supremacists provide very concrete arguments for increasing the focus on safety.

Will Mastodon's upcoming release 4.3 provide more tools for admins on instances federating with Threads – and for people on those instances – to protect themselves against these anti-trans hate groups and white supremacists? We shall see, but early returns aren't encouraging. For example, when Threads announced the very sensible policy of allowing individual users opt in to federating, Rochko expressed his disappointment ... so I'm not holding my breath for an equivalent option in Mastodon.

But even if Mastodon does start providing better safety tools, Rochko's warm welcome to Threads and mastodon.social's decision to federate with Threads will also add momentum to calls for a hard fork. From mastodon.social's perspective, making federation with Threads works smoothly is valuable. As Rochko says in How Mastodon made friends with Meta:

"So they reached out to us and we had conversations about what they want to do, how they can do it, and we had more detailed conversations about how to do X, how to do Y protocol-wise. We helped them resolve some issues when they launched their first test of the federation because we want to see them succeed with this plan, so we help them debug and troubleshoot some of the stuff that they're doing. Basically, we're talking with each other about whatever issues come up."

But from the perspective of hundreds of instances have signed the anti-Meta FediPact, and hundreds more are blocking Threads without signing the pact, any resources devoted to to improving the Threads/Mastodon integration are wasted. What happens when Threads turns on two-way federation and the hate groups, white supremacists, and spam bots on Threads start hassling people in the fediverse? As more Threads users turn on federation, will that lead to scalability problems? What if an unexpected privacy issue surfaces? What if the election disinfo and coup that's likely to surge on Threads starts to trickle over into the fediverse? Any of these things could require a big chunk of work from the Mastodon team.

Not only that, for people who are suspicious of Meta, a hard fork that's more insulated from Meta's influence has some obvious benefits. And I'm not just talking about FediPact signers here! One of the few things about Threads pretty much everybody in the fediverse agrees on is that Meta can't be trusted So even many instances and software developers who are working with Threads today can see the value of an independent alternative. But Rochko has downplayed the potential safety, privacy, and cultural issues of the Threads integration³ as well as the possible embrace-and-extend threat. Does he really understand the risks here?

Meta's plans to offer automated moderation tools to fediverse admins (discussed by Rachel Lambert and Peter Cottle on the Dot Social podcast Threads Has Entered the Fediverse) further heighten these concerns. On the one hand, it aligns well with the direcction Mastodon CTO Renaud Chaput sketches in Evolving Mastodon’s Trust & Safety Features (also July 2023) for "configuring trusted providers" for moderation activities. On the other hand, Meta's moderation tools are racist and anti-LGBTQ+, and produce a lot of false positives (as Black activists and supporters of Palestine on Facebook, Instagram, and Threads know only too well). And what else will Meta do with the data these services collect?

Of course, Lambert and Cottle emphasized that Meta doesn't plan to force anybody to use these tools – and the trusted provider architecture is useful in other scenarios as well. Still, at best the effort Mastodon devotes to supporting Meta's moderation tools is wasted for instances that don't want racist, anti-LGBTQ+ automated moderation.

An opportunity for broad participation and a cultural reset

Update: the original version of this post included an edited excerpt of this poll, and didn't link to the original poll or make it clear that I had edited it. My apologies, that was a mistake.

A hard fork is also a good chance to attract new volunteers. The poll I did with the draft version of this post only got 118 responses, and it's obviously a self-selecting sample, but the results are still interesting: people with a wide variety of skills are at least potentially interested. I've heard from many people that the official Mastodon fork's culture is very developer-centric, so a fork that values other particpation equally could be very attractive to a lot of people.⁴

And a new fork is an opportunity for a new culture. As long-time fork developer Lady notes,

"a fork absolutely needs to have good practices in place for volunteers. this is something mastodon has historically struggled with."

Cassian's I left Mastodon 27 days ago (2018), hoodieaidakitten's Mastodon’s Complicated Relationship with Queer Activism (2018) and Ana Valens' Mastodon is crumbling—and many blame its creator (2019) highight some of the Mastodon's struggles on this front; I saw a similar example of somebody not being acknowledged in the 4.2 release last summer. A new fork doesn't have to inherit those problems. Getting good practices in place for volunteers – and for working with other forks and apps – up front is a good way to make progress.

A new fork's also an opportunity for more diverse participation. You don't have to be a diversity-in-tech expert to see that establishing accessibility as a priority up front, funding accessibility work, and valuing and appreciating accessibility feedback and testing are all likely to get more disabled people involved. And more generally, racial and intersectional diversity isn't something Mastodon has ever really focused on. How well does the project currently adhere to best practices for inclusive culture? How racially diverse is the Mastodon team? What percentage of the budget goes to Black and Indigenous developers, to women of color, to trans and queer people of color?

Of course, the culture of the official Mastodon fork isn't set in stone – and they also have a great opportunity to make progress on its culture and change its priorities. Rochko is wearing a lot of hats these days, and long-time Mastodon contributor (and trust and safety expert) Emelia Smith reports that Claire is now leading Mastodon development, with support from part-time CTO Renaud. It could be a natural time for the fork to evolve away from its current BDFL style and developer-centricity; get better at acknowledging contributions and working with other fedivese development teams; diversify paricipation; seek out and listen to marginalized instance admins and community members, and fund more accessibility, and safety community workwork.

Still, old habits and power structures die hard. The longer a culture has been in place – in an open-source project, or on a social network – the harder it is to change it. And as Smith points out, the Mastodon fork's development resources are currently limited, and there's a lot on their plates, which makes it all the more challenging. So even if the official Mastodon fork decides to go this route, it's likely to be harder and take longer for them to change their culture significantly. A new fork starting with a new culture is complementary – and could in turn help the official fork make progress more quickly.

And progress could have a big effect on the Mastodon ecosystem and the broader fediverse. As Dr. Johnathan Flowers says in The Whiteness of Mastodon (December 2022)

"We need to acknowledge that there is a history on Mastodon of instances of color being marginalized, being discriminated against. There is a history users of color being subject to racist, to anti-Semitic, to homophobic kinds of abuse. There is a history of the kinds of similar kinds of violence against users of color, against disabled users, against marginalized users on Mastodon that there is on Twitter ..."

Of course, Flowers is talking about Mastodon as a whole, not the software development in particular. Still, Mastodon's lack of safety have certainly contributed to the bad experiences that so many marginalized people have on Mastodon,⁵ so a fork that makes progress on that front could have a big impact. And a community-oriented fork with diverse participation is more likely to listens to, work with, and prioritizes the needs of marginalized people – an approach that creates that works better for everybody, as Afsenah Rigot explains in Design From the Margins.

Safety is an especially good area to focus on

"And speaking of vital techniques for developing software that's safer and more secure, the principles and practices of privacy by design highlight the opportunities for short-term low-hanging fruit – as well as longer-term directions."

– Steps towards a safer fediverse, Febuary 2024

I've talked a lot about the value of a more safety-focused fork, so it's worth going into some detail on the opportunities for progress.

In the short term, there are a lot of straightforward safety-related improvements over today's official Mastodon release. For example:

• Supporting local-only posts, which forks like Glitch and Hometown have had them since 2017.
• Turning on "authorized fetch" (the magic admin setting that makes blocking more effective) by default.
• Changing the default for safety-related preferences like approving followers – and for whether or not to show followers on public profiles.
• Prohibit followers-only replies to public or unlisted posts, closing the abuse vector Mekka Okereke describes here
• Making it easy to load a basic blocklist when a new instance starts up so people aren't as vulnerable to harassment from the nazis and TERFs that hang out in the vile sections of today's fediverse.
• Make RSS feeds opt-in, as in Hometown.⁶

The code for many of these already exists. Others are minor changes, like changing the initial value of a default setting, and in some cases also adding in mechanisms to change it via the admin UI, API, and the tootctl management tool. But they either clash with Rochko's vision for the software, or (like making it easy for new instances to start with a blocklist) haven't had resources devoted to them.

Other safety improvements require more effort, so won't happen until there's additional funding and people to work on them. Still, the Mastodon team under Rochko consistently hasn't prioritized safety; a quick look through the Mastodon GitHub has many safety-related issues that have been open for years. As I wrote in November 2022's Does Mastodon really prioritize stopping harassment?

"For a platform that supposedly prioritizes anti-abuse Mastodon's lack of progress on this over the last several years is really striking."

So progress is much more likely to happen in a fork that focuses on safety than in the mainline Mastodon code. A few key areas especially worth considering:

• adding the ability to take public posts private, a valuable defense against dogpiling that's likely to become even more important once Mastodon follows through on its plans to introduce quote boosts in a future release
• allowing control over who can reply to posts
• improve blocking – both for individuals and of entire domains – which today has a lot of limitations
• introduce a new "non-public" visibility to complement "public" and "quiet public" (previously known as "unlisted", but getting renamed in the upcoming Mastodon 4.3 release)
• improving consent-based federation, which Mastodon documentation currently describes as "contrary to Mastodon's mission"
• implementing user experience improvements like Federation Safety Enhancement Project (FSEP)'s "following UI integration"
• providing hooks to support fediverse equivalents of tools from other platforms like Block Party and Filter Buddy that allow for collaborative defense against harassment and toxic content can apply in a federated context

There are also a lot of other areas for improvement

"If it's not wildly different, but noticeably better, you'll get faster adoption.... After you gain some momentum then you do the big stuff."

– fancysandwiches

I'm not going to go into as much detail on community and accessibility as I did with safety, but the same patterns are there: straightforward short-term improvements, and opportunities for more significant changes long-term.

With accessibility, open Github issues related to link underlining, color contrast, and CamelCasing hashtags offer straightforward opportunies for improvements.⁷ More ambitiously, how hard would it be for the software to offer some support for accepting an #AltText4You suggestion for images that don't have any alt text?

There's also important overlap between safety and accessibility. Changing the defaults for safety-related preferences to be more protective is also valuable from an accessibility perspective; with current defaults, disabled people are left at risk if the preference pane isn't accessible (screenreader or mouse navigation issues, text that't been translated to a person's native languag, etc). An option to get use the web interface without javascript, is good for security and privacy as well as accessibility.

And there's overlap between safety and community as well, including (aat the risk of repeating myself), LOCAL ONLY POSTS HAVE BEEN IMPLEMENTED IN FORKS SINCE 2017!!!!! Forks are starting to implement "bubbles" (currently only available in Akkoma), a useful towards multi-instance communities (or communities-of-communities) that could be extended to help with safety as well. Local-only profiles (or a local-only profile tabs) are an obvious complement to local-only posts. Longer-term safety directions like improving consent-based federation and supporting collaborative self-defense tools like Block Party and Filter Buddy also have value in terms of community.

And looking even more Broadly, it's worth highlighting that a new hard fork that starts with Glitch or Hometown and merges in additional features from other forks would also have many other advantages over today's Mastodon.² Formatted posts, and the Glitch UI improvements, are straightforward examples. And once you start looking at the Mastodon github issues, there are lots of small-but-valuable improvements. One of my favorite examples of this is making the maximm post length easily configurable:

• cassolotl suggested this in 2017 and it was quickly implemented by lambadalamda and integrated into glitch-soc
• Rochko rejected it.
• Since then, it's been proposed – and rejected – repeatedly: in 2018, 2019, 2022, 2023, and quite possibly others I missed in my quick search of Mastodon issues

This by the way is a great example of the impact of Mastodon's historical development style. Rochko's the BDFL, so if he thinks it should be hard for admins to set up their instance the way they want, then he gets to make it hard for admins to set up their instance they way they want. But you can certainly see why admins don't like that and see it as example of Mastodon not working well with others!

Of course, any fork is going to have to make choices about what functionality does or doesn't go in – and you can't please everybody. Still, there are plenty of opportunities for improvements over the official Mastodon fork that can provide a lot of value to small-to-medium size community-focused instances.

It's not as easy as it sounds ...

"Reminder to people who say "Let's fork Mastodon"... the code is the easy part (and that's also very hard)"

– aus.social admin Shlee

"The thing is, maintaining a hard fork is not a cakewalk."

– Sean Tilley in The Trouble with Forking Mastodon on We Sistribute

The opportunities for improvement and issues with Mastodon's culture have been there for years, but previous hard forks haven't been able to capitalize. The code is indeed very hard; Mastodon's a huge code base, there are some unfortunate design and architectural decisions, and it's accumulated a lot of technical debt. So it'll take people who aren't familiar with the code base a while to come up to speed.

Shlee's post highlights some of the other challenges, including

"You need to build a community - you need to build consensus - you need to build influence. You need to have funding."

In Why a hard-fork of Mastodon isn’t the way, fediverse trust and safety expert (and longtime Mastodon contributor) Emelia Smith goes into more detail on the challenges that the current team needs to address – most of which potentially apply to a new fork as well.

"There’s general maintenance work, such as updating dependencies or moving off dependencies that are no longer supported; there’s security fixes and the back-porting of those fixes to older released versions; there’s product roadmap and project planning; there’s triaging and responding to hundreds or thousands of issues and pull requests; there’s providing help and assistance to users of the software who are encountering issues and bugs; there’s responding to press enquiries, applying for grants, working on legal & accounting to gain non-profit status, etc. There’s also documenting the project, which is a huge effort, with far too few people contributing (instead many are preferring to write their own blog posts about their experiences, rather than improving the documentation for everyone)."

But it's not like it defies the laws of physics!

That said, other open source projects have had successful hard forks, so it doesn't defy the laws of physics for a Mastodon hard fork to succeed. And indeed, when you look at they specific challenges, they don't seem insurmountable. As Tilley says,

"Committed developers, deep knowledge of the code, community outreach, a coherent product vision, and having a designer all go a long way towards making this successful. Making it easy for communities to switch over is important, too."

Easier said than done, but certainly not impossible.

A new fork also has some advantages over an existing fork, at least in the short termno back versions to maintain, no support requirements from existing users, a chance to put new issue triage and prioritization processes in place. A new fork also has a chance to reduce its scope, for example by focusing on small-to-medium size instances – and leaving support of large instances to the official fork.

And if the new fork can take advantage of the opportunity for broad participation and a cultural reset, many other possiblities open up. Take Smith's point about documentation, for example. Why aren't more people contributing to Mastodon? Here's the "Contributing to Mastodon" section on docs.joinmastodon.org

Even if you go to the Mastodon documentation Github repo, there aren't any suggestions on how to contribute. And how are Mastodon documentation contributors acknowledged?⁸ It's a good example of Mastodon's developer-centricity. A fork that more actively encourages and recognizes people who help with documentation has a good chance to get broader participation.

Similarly, Smith notes that Mastodon arguably wasn't ever designed for single-user instances. As smallpatatas notes in The Slow Fedi Movement: Toward a Green, Independent, and Equitable Fediverse

"The cost of managed hosting even for a single-user instance is way too expensive for most of the world. Here's Marco Rogers' experience. $19 is a lot of money if you live in a low-income country."

If a new fork enthusiastically adopts lower-cost as a design goal, could it attract more single-user and small instance admins – and hosting companies interested in getting more single-user and small instances as customers?⁹

What about funding?

Even though volunteers are the lifeblood of community-focused open source projects, paid positions and project-based funding are vital as well. Unless people are paid for their work, participation is restricted to those who can afford to volunteer. Fortunately, there's a lot of buzz around the fediverse today – and increasing awareness that Mastodon's innovation has been lagging – so funding is likely to be easier than it's been in the past.

As well as crowdfunding and grants from foundations and civil society organizations, hosting companies, app vendors and infrastructure businesses like Fastly are other potential sources. There are a lot of smaller businesses who are looking for an alternatives to today's rich-get-richer Big Tech world.

And Mastodon's alignment with Threads is a big red flag even for businesses who benefit from access to Threads' audience. As I said in Wait a second. Why should anybody trust Facebook, Instagram, or Meta?, everybody seems to agree that Facebook, Instagram, and Meta are untrustworthy.

"After all, it's objectively true!"

The official Mastodon project is likely to be more attractive to large commercial social networks looking to expand into the fediverse (especially with Twitter and Medium co-founder Biz Stone on the board of the new US-based Mastodon non-profit). Then again, several potential funders have told me that Mastodon's lack of attention to safety and/or reputation for racism mean they don't see it as fundable at this point – but are interested in projects that would be a good match for a more safety-focused version of the software created by a more diverse and inclusive team.

If a crowdfunding route makes sense, many people who aren't currently supporting the Mastodon Patreon have told me they'd donate to a new fork. And while it's far from the only reason, the bigger elephant is a key here; many people on instances that want nothing to do with Threads don't want their money going to a Threads-friendly project like the Mastodon official release. Of course that doesn't necessarily mean they'll all follow through but it reinforces the possibility of complementing (rather than cannibalizing) existing resources.

One approach is to channel this funding through cooperatives, non-profits and public benefit corporations – partnering with existing ones at first while setting up new ones. In feedback on an early versio of this post, Lady suggested another approach:

"fund INSTANCES, and then have instances pledge hours, not money, to fork development. i like this model because it is very community‐oriented, and it ensures that the people who are using the software are the ones deciding its development direction. but it’s also a lot harder to implement—it requires gathering a large enough community of instances together and actually having them pledge that work. it would be great if we could rely on hosting services to pledge some of the hours here too."

Make sure most of the funding goes to Black, Indigenous, Muslim, trans, queer, and disabled people

"The decentered include subpopulations who are the most impacted and least supported; they are often those that face highest marginalization in society... when your most at-risk and disenfranchised are covered by your product, we are all covered."

– Afsenah Rigot, Design From the Margins, 2022

Whatever funding structures are used, it's vital to ensure that most of the funding goes to marginalized people and projects they lead. This is an important principle in general, and it's especially important for a Mastodon fork. The Whiteness of Mastodon, Mastodon’s Complicated Relationship with Queer Activism, Dogpiling, weaponized content warning discourse, and a fig leaf for mundane white supremacy, A breaking point for the queer community, and The patterns continue ..., have background.

It's not an either-or situation

"Overall, I think a hard-fork of Mastodon would do more harm than good: it’d split already limited funding, split development resources, and arguably have just the same if not worse governance issues."

– Emelia Smith, Why a hard-fork of Mastodon isn’t the way

When I posted the first draft of this article, and again when I posted the revised version, several people brought up arguments against a hard fork of Mastodon that are certainly worth discussing. Smith does a great job of describing the constraints of the current team, with very limited resources and a massive amount on their plate. Given that, she suggests that "calls for forks just distract from efforts to move things forwards."

A different way to look at it, though, is that a hard fork potentially offers a path around these constraints. I talked above about the potential for attracting funding and volunteers that complement the official project. And while governance is a challenge for any open source problem, a more diverse project with a community-oriented focus and more consensus-oriented decision making (as opposed to the BDFL style) also offers significant opportunities for improvement.

And splitting funding and development resources is potentially a good thing – especially (but not only) from the perspective of community-oriented instances and businesses who have concerns about the Mastodon's alignment with Threads. Mastodon gGmbH and their new US non-profit are attracting a lot more funding – in fact during the time since my draft post, they've announced six-figure donations from Jeff Atwood and Mozilla, a grant from NLNet to implement quote boosts, and the new US 501(c)(3) non-profit with some very well-connected board members and the explicit goal of helping with funding. There's a limit to how quickly any project can grow, especially if they're trying to evolve their culture (which they hopefully are).

So it's not an either-or situation.

Others suggest that it's better to focus energy and resources on other fediverse microblogging software instead of Mastodon. There certainly are a lot of worthwhile projects out there – Jenniferplusplus' More than Mastodon is a good list – and There's no question that platforms like GoToSocial, Bonfire, Akkoma, streams, and Letterbook have been designed with more of a focus on safety. And for developers who know (or want to learn) the programming language other platforms are implemented in, these code bases are a lot more approachable. As fork veteran clar fon says about GoToSocial:

"GTS checks all the boxes for me. they have a good team, a good pace, a good vision, and a good plan. it'll take time to reach parity with mastodon but I don't doubt they will

any serious work on a fork for mastodon, in my opinion, will spend most of its time rewriting shit from scratch anyway. unless you're looking to just keep it on life support until GTS is done"

On the other hand, there are hundreds of thriving communities running on Mastodon and its forks today, some of which have been around for years, and there isn't any way yet to move a community to a new platform. A new fork can make a lot of valuable incremental improvements before (or in parallel with) rewriting. And GoToSocial's niche is small or single-user instances; kudos to them for taking that focus, but that also means it's not clear how well-suited it'll be for medium-sized community-oriented instances with several hundred or more users. As Ro says,

"I understand there are other AP-enabled platforms out there that are better than Mastodon. That's cool.

But we can't abandon people who use Masto right now who want something better."

So once again, it's not either-or. In fact, given Mastodon's bad reputation for not playing well with others, a hard fork with a more cooperative attitude could well help other platforms.

For example, Mastodon's size often lets it do its own thing and pay less attention to standards. A fork that moves in a more standards-compliant version will be more compatible with other platforms, and increase pressure on Mastodon to also be standards compliant. As Nora points out, "the more instances are out there that aren't moving with mainline, the more they will have to lean into standards in order to keep the network whole."

A lot of open questions - and a lot of potential upside

There are a lot of open questions here, starting with three that Margaret KIBI brought up years ago at the end of Progressing Fringe Mastodev, after talking about Mastodonʼs "long patterns of assimilation and exploitation":

• Who will build it? 
• Who will control it ? 
• What of the power differential which results from these imbalances, and which has resulted from years of passive cis/white profit off of marginalized labour?

As KIBI says, there are no easy solutions; "it is the work cut out for us."

Some of the other key questions I've touched on over the course of this post also don't have easy solutions.

• How will consensus decision-making work in practice? How to start the new fork with a more inclusive culture that encourages participation? What other open-source software projects (or collaborative projects that aren't open-source software) should it look to as models?
• How can a new fork help "fringe Mastodev" forks, without repeating the pattern of assimilation and exploitation?
• How can a new fork work with the official Mastodon fork in synergistic ways?
• How can a new fork work with apps, platforms, and hosting providers more effectively?
• Where to start on the laundry list of potential improvements?
• Where does initial funding come from? How to make it sustainable? How to ensure the funding is distributed equitably, and reinforce a decentralized consensus-based culture?

Still, these are questions that need answers over time – not show-stoppers. There's also a lot of potential upside if the new fork is even somewhat successful: improving safety, experimenting with new cultural approaches, and helping the broader ecosystem.

Stay tuned!

When I published a draft of this post in mid-April, this section was called "Clever conclusion - tbd." A lot's happened since then – including Mastodon's Saturday April 27 announcement of a new US-based non-profit 501(c)(3) to help with fundraising.

The new 501(c)(3)'s board includes Esra’a Al Shafei (founder of Majal.org, co-founder of the Numun Fund, and board member at Tor Foundation) and Karien Bezuidenhout (who has a wealth of non-profit experience), two incredibly valuable additions that really highlight the possibilities. And a US-based 501(c)(3) can unlock a lot of additional funding, including corporate matching. That's good!

But the new board also includes a lawyer whose day job is defending AI companies against copyright lawsuits, and an investor who's also on the board of the AI Foundation, a "dual commercial and non-profit organization" – and is also a founder of Twitter. Even though Mastodon gGmbH is independent from the new board, the annoncement heightened concerns about surveillance capitalism and co-opting already sparked by Mastodon's Threads-firendliness.

So unsurprisingly, discussions of a hard fork intensified.

When I first published this post, Sunday evening, this section started with a link to a thread from Ro (developer of The Bad Space and former admin of PlayVicious.social) with some of his thinking about how to start hard-forking Mastodon. Monday morning, Soon after that, Ro published A Case for Community, proposing Awujo:

"Awujo is the Yoruba word for community, and it was chosen to illustrate a fundamental shift from a singular and narrow vision to a broader, more inclusive perspective. A perspective that values a collaborative approach to implement a wider range of features that speak to the needs of people who want to have a curated experience with an improved version of Mastodon."

Ro's overview high-level overview of Awujo's goals includes better safety tools, expanding the moderation experience, accessibility, reducing bloat to increase performance and stability, simplfying setup and maintance, defining a transparent code contribution process, and creating a stable pathway for current Mastodon instances to migrate to Awujo. The approach Ro suggests – starting with the Glitch fork, working contributors and/or funders to form the core governance – makes sense to me. And there are a lot of other great perspectives in A Case for Community – it's really worth reading. Let's hope that funding emerges and Awujo gets to critical mass!

As hacker.town mayor The Gibson pointed out, Awujo is only one of multiple efforts firing up. In the discussions of Ro's post I saw at least two people working on other fediverse platforms highlight synergies. And there's enough energy for hard forks that it wouldn't surprise me if we see other attempts attempts to explore as well. An advantage of a new fork starting with an existing forks like Glitch or Hometown is that it can deliver short-term progress, and the polls I've done certainly imply there's a lot of interest in helping with hard forks.

Once again, it's not necessarily either-or. Multiple explorations can happen in parallel – and hopefully work together, at least to some extent, to make the efforts more synergistic.

So stay tuned for what's next! As Margaret KIBI said in Progressing Fringe Mastodev

"It is my hope that if we continue this work with an eye to the above questions, new horizons will open up which will give us additional insight into the necessary steps for a just future."

Notes

⁰ The original version of this post didn't include the words "quite possibly" in this sentece. How Mastodon made friends with Meta discusses how Mastodon helps Threads "debug and troubleshoot some of the stuff that they're doing," and I assumed that work would continue and increase as two-way federation gets enabled and more people on Threads turn on federation. But perhaps not. So I added the words "quite possibly" here, and discussed it a bit in the section on There's a big elephant in the federated room (and I don't mean Mastodon)

¹ The recent blog post Mastodon forms new U.S. non-profit mentions that "Mastodon gGmbH has received a notice from the same tax office that our non-profit status has been withdrawn," although they're appealing.

² For obvious reasons, hosting services are more likely to support software with a team and organization behind it.

³ As far as I can tell, Rochko never talked about the hate groups on Threads and what Mastodon is doing to help instances federating with Threads better protect their users. His answer to "Will Meta get my data or be able to track me?" in What to know about Threads (from July 2023) is ... less than compelling.

⁴ To be clear, it's not just Mastodon that's developer-centric. Snot Flickerman's Lemmy comment on a draft version of this post is a very typical atitude in the fediverse, although it's rarely phrased quite so eloquently:

"This “Jon” guy has been writing these fucking long ass screeds about all this for at least a year now.

Maybe if this motherfucker stopped writing and took some time to learn to code and then contribute to the codebase themselves, they might have more luck....

Contribute to the code base or shut the fuck up about your demands."

⁵ For example:

• New Mastodon instances leave everybody open to harassment from well-known nazi and so-called "freeze peach" instances. Providing a default blocklist would significantly reduce this problem ... but as discussed in the main text, this still hasn't made the cut for the upcoming release 4.3
• As Muslim and Indigenous people have pointed out to me, mastodon.social's moderation often doesn't take action on Islamophobic and anti-Indigenous hate speech and harassment. So setting the default signup to mastodon.social without addressing these moderation issues increases the chances that new Muslim and Indigenous Mastodonians will have a bad experience.
• You're probably as tired of hearing about Mastodon's refusal to support local-only posts as I am about writing about them, but guess what? Local-only posts would give people of color an option to reduce their exposure to harassment but they're not available in Mastodon. So would allow-list federation, but that's contrary to Mastodon's vision – and in a discussion a few months ago, Chaput confirmed to me that this attitude isn't likely to change going forward.

⁶ Today, disabling RSS feeds on vanilla Mastodon requires modifying the nginx configuration file -- which isn't even possible for instances using hosting services.

⁷ Hashtags in #CamelCase (where #TheFirstLetterOfEachWordIsCapitalized) are more usable for screenreaders, but Mastodon today converts its hashtag suggestion to all-lower-case – annoying, and relative easy to change.

⁸ I don't remember any acknowledgements for doumentation mentioned in blog posts, these contributions don't seem to appear in the changelog, and from a quick search documentation isn't even mentioned in Mastodon's 2022 Annual Report.

⁹ Then again, at this point other platforms like GoToSocial (which runs on a Raspberry Pi) or snac (which is written in C) may be better choices for single-user instances. So a new fork could also take advantage of an opportunity for short-term scope reduction if a new hard fork chooses not to focus on single-user instances initially.

Still, as It's not an either-or situation discusses, there are also barriers to people and instances switching platforms. And as of April 29 the most popular response to the poll about what people want to see in the fork is "Reducing cost and complexity for small instances", so there probably is energy to make progress on this. I decided to move the bit about scope reduction to a footnote.

Update log

Ongoing: fix typos, add links, other cleanups

May 8: include quotes from The Trouble with Forking Mastodon, link to More than Mastodon list of alternate projects

April 29: rework last section to incorporate to A Case for Community.

April 28: published for reals, with many changes from draft

April 18: first published draft