Why a hard-fork of Mastodon isn’t the way

Recently Jon from The Nexus of Privacy published a draft article “It’s time for a hard-fork of Mastodon”, in it he raises many points about the BDFL governance of Eugen Rochko, the rejection of “small improvements” by Eugen over the years, trust and safety needing improvements, and the speed of development.

Now, this response isn’t a negation of some of the very valid points that Jon raises, however, I do want to respond nonetheless: a hard-fork of Mastodon isn’t the way forwards.

If we survey the ActivityPub server landscape, and look at most projects, most only have a single developer actively working on the project with any level of dedication, Mastodon appears to be an exception, but really isn’t. Pixelfed has Dansup, Peertube has a single developer, Kbin has Ernest, etc. Each of the existing forks of Mastodon are maintained by either one or two developers, if that.

For any project to succeed, it needs people dedicated to working on it full-time, and those people need to have a deep understanding of the various complex systems and how they interact. Developers are useful on any project, and can help land new features quicker, however, there’s a whole mountain of other work that isn’t well respected in open-source projects, and often ignored by people external to those projects.

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).

Mastodon has usually only had one developer, maybe two, working on it full-time at any given point over the past 8 years. Eugen’s usually having to wear a dozen hats, which split his time and attention. Right now, it has Claire leading development, with support from Renaud (part-time CTO), and volunteers such as Matt Jankowski, Michael Stanclift, and A. There are of course a whole host of other frequent contributors, myself included, but the list is small and the amount of work is massive.

On top of this, we have the way that people think it’s okay to treat people who work on and lead open-source Fediverse projects: swearing at them, harassing them, hurling insults and vitriol because the thing that they think is super important hasn’t been done in the time-frame that they deem acceptable. Or because they encountered a social issue which they think could have been avoided (hint, it’d take resources away from other activities to do things).

Whilst there’s features and development which I’ve personally considered forking Mastodon for, I wouldn’t actually want to maintain a fork long-term. For instance, I’d love to do a fork with a new federation management setup, based on firewalls & filters. I’ve 13 pull requests open, many still drafts, some waiting almost a year for review, but I know there’s a tonne of other on-going work, and my current changes likely don’t take priority. That’s something I have to be okay with as a volunteer contributor to any open-source project.

People in the Fediverse love to act as if Eugen (Gargron) is the huge blocker to everything in Mastodon, but as the contributor graphs show, Eugen’s contributions have significantly dropped off in recent history, and he likely spends more of his time trying to secure funding and doing administrative work, rather than active development. Back in June 2023, Renaud joined Mastodon as their (unpaid) CTO, as a part-time role. But there’s always more work than hands available to do it, especially for a project that has so many users and so little funding.

Yes, all Fediverse software can do better on all the things listed in Jon’s articles. Mastodon already has some of the best trust & safety features on the Fediverse, the only competitor here is Pixelfed. Most other Fediverse software often has a long way to go, especially when we look at things like DSA Compliance (e.g., Article 17's notify & appeals processes).

If we look at other fediverse software, we see dime a dozen forks of Misskey —so much so that there’s even a name for forks of Misskey: Forkeys — but its development is still largely lead by one company, as far as I know. We’ve also seen calls for forks of Pixelfed and kbin, for various reasons. Open-source governance is a hard problem, most projects struggle with it, particularly when they undergo significant growth which doesn’t correlate with an increase in funding. A classic example of this is the Node.js / iojs drama, where eventually iojs merged back in with Node.js and that gained new governance.

There are things that people are calling for, such as “automatic blocklist setup” and the question then becomes: what blocklist, how’s that blocklist maintained, how is it structured, etc. As of right now, I don’t think any of the available blocklists are well enough organised or maintained to have them recommended as a default, besides maybe a “Do Not Interact” or “DNI” list or two. There’s been documented flaws and issues in all the lists available, and that’s only to be expected, but if we’re recommending something at install time, the data backing it better be damn good.

For IFTAS, we took the direction of maintain our own lists, and building a tool to manage synchronisation of that with servers in a simple and straight forwards way, it’s called Fedicheck. (disclaimer: I’m an advisor and freelancer for them).

I was actually also the author of a pull-request that aimed to add install-time blocklist import, the big issue there was that it left behind those on hosted platforms (arguably the hosts should be doing more to improve the provisioning of instances to help admins have a better experience).

The data in blocklists can often either be problematically sourced, or have errors with little process in place for appeals. Once an instance gets on a list, it’s typically very hard for that to be undone (not least because there’s no easy way to import retractions via CSV files). Most of the data isn’t categorised, or if it is, it’s not available in a format where you can pick and choose what to trust from that list.

(I’m aiming to improve this with my FIRES project which was recently funded by NLNet).

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 (hint: you probably don’t want to be accepting any contribution to a major open-source project, because that’s how you get things like the recent xz vulnerability happening).

Contributing to open-source takes active effort, and that effort must be compensated. It takes leadership and resources to be able to correctly steer a project. Many fault Mastodon for not supporting single-user instances enough (but it was arguably never designed for this use-case). Many fault it for not having features that they want, but they’re unwilling to fund those features. Mastodon is getting quote posts: NLNet just funded this.

At the end of the day, building software that’s used by millions of people is fundamentally difficult, and calls for forks just distract from efforts to move things forwards.