In light of the announcement of Mastodon’s US-based 501c3 Non-Profit, and the reveal of that organization’s board members, there has been backlash from members of the Mastodon community. Some people are even saying that this is the last straw, it’s time for a hard fork of the project!

Before I dig in, I would like to preface: there is nothing inherently wrong with forking an open source project. It happens all the time, and some truly great projects have come out of forks that people benefit from today.

The thing is, maintaining a hard fork is not a cakewalk. If your fork intends to compete with the original, it’s likely going to be an uphill battle.

What kind of problems would this fork face? Let’s talk about it.

Developer Momentum

When it comes to popular forks of open source projects that are thriving, we can look at a few examples: LibreOffice and Nextcloud both come to mind.

Both of these projects are fairly successful because they managed to bring the vast majority of their contributors to the forked project en masse. The projects they forked from were also fairly established to begin with, featuring multiple software engineers, designers, and community contributors.

Mastodon is Tiny

Despite all of its success, Mastodon remains a tiny project with only a handful of full-time devs working on it, and a few long-time volunteers. Mastodon GmbH currently employs 2.5 people to work on the code full-time.

Very few people know the ins and outs of the platform as well as the original team does, and trying to pull in different people’s contributions on a piecemeal basis isn’t sustainable. Diaspora’s own community-run approach is a good example: over more than a decade, the project has barely made any major improvements or changes.

Code Divergence

Another uphill battle involves pulling in improvements from upstream. The further a fork diverges from an upstream project, the harder it becomes to reconcile differences.

Back in the day, Diaspora had a few forks: one implemented groups, another had cool usability improvements. At one point, the main UI went through a comprehensive rewrite, adopting BackboneJS and tests everywhere.

None of the fork authors knew how to work with BackboneJS, or write tests. Suddenly, there were differences that couldn’t be reconciled. Cherry-picking improvements with upstream suddenly was really difficult, and so was contributing features back. Over time, the forks died off completely.

We’ve Been Here Before

This isn’t even the first time the community has called for a hard fork. Florence was an attempt to do exactly this, at a time where a chunk of Mastodon’s community was deeply unhappy with the project’s creator. Evidently, trending hashtags were the straw to break the camel’s back

Eugen told people that if they were unhappy, they could always fork the code and make their own decisions. It was his way of saying that people were welcome to do their own thing if they weren’t happy.

It went about as well as you would expect. The phrase #ForkOff was born, and people ran with it. Eventually, this turned into an actual effort to fork, generating a significant amount of interest. The #ForkOff project gave itself a name, set up a project, and then proceeded to have lots and lots of meetings about governance and policy.

Over time, an uncomfortable reality became readily apparent: the Florence project was great at holding meetings, but struggled to attract dedicated developers. There was no shortage of ideas, but a quick glance of the issue tracker demonstrates a lack of general direction:

• #55: Detect and flag possibly seizure-inducing videos
• #60: Make web application more lightweight
• #71: “Forget” Feature
• #73: Allow admins to set “trap” names
• #111: Support XMPP URI in Mastodon interface

To be clear: none of these are necessarily bad on their own. and some of the suggestions eventually ended up in mainline Mastodon. It’s just that this tracker is mostly a suggestion box, and the project direction feels as though it was crowdsourced.

Florence shut down after a few months, due to a variety of contributing factors: COVID, health problems, lack of volunteers, and breakdowns in communication were some of the reasons. Across the project’s lifespan, it only made three minor Pre-Releases prior to shutting down.

The Lesson

Here’s the thing: you can fork an existing project, and add your own features. A few forks like Hometown are out there doing it, and they’re great. Creating a fork to challenge the dominant project you forked off of is another matter entirely.

Without momentum, commitments, and community, you’ve got squat. To challenge Mastodon with a fork, you need: a coherent vision and direction, serious developer and design muscle, and the ability to commit years of your life to turn Mastodon into something else. That last one in particular is key: this fork can’t be a side project. To succeed, it will require all of your time and energy to sustain.

What can we do?

On the surface, forking an existing project seems like a no-brainer. Rather than starting from scratch, you get an existing codebase for free! But, you also inherit all the technical debt, all the cruft, and none of the expertise. Therein lies the rub.

The way I see it, there are two paths forward that may be better for the long term: start a new project with people who want to work with you, or join an existing project that needs your help. You could even help an existing fork!

Either path requires a tremendous amount of hard work, but they’re both opportunities to learn and shape a system from the ground up, incorporating a vision of what you want to see. These are great ways to learn, grow, and build community together.

 Share