Mastodon project governance


From the POV of an outside observer from GNU Social land (only recently moved to a Mastodon instance), a lot of the current conflict in the Mastodon community seems to derive from three things;

  1. As @saper pointed out, some confusion about which decisions only affect (the flagship instance), vs which affect Mastodon (the software/ network of instances), vs. which affect the fediverse (the meta-network of all instances of all the social apps that can inter-operate)
  2. Two overlapping but different sets of design goals for the UI
  3. Two very different and conflicting sets of expectations about how to govern and manage the software development process

Issue #1 could be mitigated by user education, based on clear, user-friendly documentation explaining the boundaries between each layer. Issue #2 could be solved for instances that don’t like @Gargron’s UI design choices, by swapping out the vanilla Mastodon web client for something like Pinafore or Halcyon.

But I think the deepest and most difficult problem here is #3, and this one has no technical solution, because it’s a social problem, not a technical problem. There was an attempt to solve this problem by having @maloki employed as a Community Manager, but this doesn’t seem to have solved it. I agree with Maloki that the only solution that will allow everyone to get their needs met is a fork; a new project with its own name, identity, code repo(s), documentation, and community processes.

Some questions for the folks who want to #ForkOffTogether. Coming up with consensus answers to these questions will both require and result in education about issue #1 (see above):

  • What kind of governance/ management schema do you want to use? See my previous comment, minus the bit about presenting it to Gargron.
  • What kind of fork will best serve your needs
    • a “hard” fork: take a copy of the Mastodon code and go off in your own direction with it. LibreOffice is a hard fork of OpenOffice.
    • a “soft” fork: release your own tweaked version of each Mastodon release, so it better meets your needs. Abrowser and IceCat are soft forks of Firefox.
    • a “spin” fork: mix-and-match some components of Mastodon with components from other sources, and release that under your own branding. Eg a Mastodon back-end with a different web client, or vice-versa (see next questions).
  • Which software do you actually want to fork?
    • Do you even like the Mastodon web client, or do you actually prefer another one (see issue #2 above), or want your instances to give you a selection?
    • Is Mastodon’s Ruby back-end the most efficient ActivityPub server for your needs, or would you be better to use/ fork Pleroma, or something else?
    • Do you have needs that can’t be met by any of the existing back-ends / web clients, and require changes that are unlikely to be made by the existing projects?
  • is a federated micro-blogging platform actually what you need? Is micro-blogging what you want to do? Do you really need multiple federated instances? Could the needs Mastodon isn’t serving be better met by a shared instance of Loomio, or Crabgrass, or Discourse?

Final thing, anyone who thinks this is the nuclear option is probably new here. Mastodon came about as a fork of GNU Social. Gargron created Mastoon by using the same federation protocol (OStatus), but totally rebuilding the software using the language/ framework he prefers (Ruby on Rails), and the style of UI he likes (modelled on TweetDeck). Forking is one of the ways free code software evolves, and avoidable conflicts are avoided by giving everyone who needs it their own sandbox to play in.


For what it’s worth, I offered a couple times months ago to do some gardening on the issues a while back, and received no response. There are people out there willing to do this, and do it from a non-deletionist standpoint (erring on the side of leaving issues open). But you are right, there is plenty of work to do weeding out duplicates, or requests for help in the guise of bug reports, or occasionally doing a “bug scrub” on ancient issues and closing them if they’re no longer a problem or can no longer be verified.

Perhaps entrusting some folks to do this type of work would make the issue tracker less aversive for everyone using it - you (@Gargron), contributing developers, and users alike. In the meantime I try to point out duplicates or ask helpful questions (“is this still a problem?”) and hope somebody else will eventually take the best action with the issue. ¯\_(ツ)_/¯


Your post started with a good analysis of the three distinct issues, which I agree with. But then, it started deriving into ideological perspectives that I disagree with.

Allow me to bring up this “final thing” since it can enlighten my later comment. No, Mastodon was never a fork of GNU social (no capital ‘s’ here, by express demand of the former project leader, Matt Lee.) A fork is about taking existing code from repository A, sharing it to repository B, and moving the origin (in Git terms) or upstream to repository B, short-circuiting the need to have A’s project leader be accepting your perspective. Now, of course, this does not apply to GNU social, a PHP code that evolved from merging StatusNet (former project of Evan Prodromou that used to run on the once popular and OpenSocial. GNU social, in my opinion, was doomed to fail since in Evan’s own words, he decided to abandon the StatusNet code base to create a much lighter and energy-efficient Pump.IO – if some cybrarian wants to make some links, I remember at the time he blogged about how much money hosting running StatusNet cost him, and how would save him – and by extension, any federated operator of this code – thousands of (Canadian) dollars a month. In these conditions, accepting the donation of StatusNet code into GNU social was kind of a dumb thing to do from a strategic perspective.

And no, coding something similar in another language has never constituted a fork.

There are two main approaches to this : one is to hang on, figure out difference and find a middle ground that satisfies everyone – this is what is called politics: you try to get along ; another option is to effectively fork a project, build governance around it, and part ways. The second option that is pushed by @maloki and friends should think the fork over in terms of project goals, ethics, and technical approach. Because forking away from a prolific project leader like @gargron requires quite a number of technical skills. If you do have the skills to do it, then you need to think about the evolution of your fork : will it at some point merge back, like Merb did with Rails, or keep diverging? Given the apparent hostility of this #ForkTogether, I’d say you’d rather think about it early and be honest about it. Good luck – keep us updated.