Mastodon project governance

Okay so I’m just a user passing by, I haven’t really been involved in Mastodon development one way or an other so I might not know everything.

However, I find quite worrying the fact that Mastodon still depends mostly on the will of one person, whoever that person might be.
Mostly because from what I’ve seen in other projects (which sure were different from this one), you have a problem each time that very person want to quit. And there are plenty of reasons for that, and I highly doubt none will ever come real here. That person might want to move on with another project, and maintaining both could be completely impossible, or they might be unable to maintain it anymore (let’s give a few ones : burn-out, financial problems, mental health issues, etc.). I have seen many people think they could do that forever and one day found themselves unable to do that anymore.

To me, no matter how you put it : this is a bad governance, even if the person if real good at doing it.

Some other issues I find troubling have already been pointed out : the job doesn’t seem to be doable by a single person. Gargon you said yourself that you couldn’t review all the issues on GitHub, and even if there are some that are here twice or more, if some aren’t really issues you can solve, or are baddly put, I don’t see how you can decide which is which. Therefore, you might miss serious issues that should be reviewed (and from the little I’ve seen, there are a big number of issues tagged with a high severity and some have been opened for several month).

Now, and I think this will be my last point : I personally really hate when there’s a way for a “dictatorship” (now I know, you’re not president of a country, this is “just” a project). But still, everything depends on your good will, even this talk on Mastodon’s governance depends on you. Now I’m not saying you aren’t listening anyone (from what I’ve see, this doesn’t look true), however you could still do that if you wanted to, and apart from people stopping to contribute to the project, there would be no way to change that. Now, my personal idea of how things should be managed probably influences what I’m saying here, but I don’t find it ridiculous.

Here’s the little I had to say about this topic.


I totally get this. I think what @Sylvhem is noticing is the result of the way free code communities have tended to grow; organically, not by design. For a small project, or one run by people who really like keeping everything in one place, it’s fine for the Issue tracker to also double as a community forum.

Since Mastodon has this Discourse forum, it would be good to nudge folks towards holding more blue-sky brainstorming type discussions here, to reduce the amount of noice in the dev area. But even if that would be helpful to the Mastodon community, it’s a culture change, it will take time, and trying to enforce it in a bureaucratic way will just alienate people. I think it’s very generous of @Gargron to allow the community to treat his office like an ongoing BarCamp :wink:

The governance issues follow a similar dynamic. When Mastodon began, nobody new if it would get big enough or last long enough to require a formal governance body. Arguably, we still don’t know that.

What I suggest is forming a working group of people who are willing to put some serious hours into organizational admin, and who between them represent a broad cross-section of people involve in Mastodon as devs, instance admins, and end users. Those people could work with the new Community Manager (if there is going to be one) to do two things;

  1. clearly document how things work now in Mastodon. Who does what, and who has what responsibilities and privileges. It’s amazing how many misunderstandings can be cleared up, and dropped balls avoided, just by doing this.

  2. come up with a plan for a community-led governance structure to present to Gargron. One that engages with the reality of who and what the Mastodon network is now, and is likely to be over the next 2-3 years. One that respects the rights of the workers who maintain free code software to be self-managing, and respond creatively to user needs, in the spirit of the Agile Manifesto (not the Agile™ Scrum™ cargo cult).

  3. Seek consensus on which existing foundation (or other free code stewardship body) could potentially be asked to be a legal and financial umbrella for Mastodon until the community is organized enough to create its own (if it even needs one). Examples of orgs that do this for projects include the GNU Project/ FSF, Debian/ Software in the Public Interest, Software Freedom Law Centre, Software Freedom Conservancy, and Apache Foundation.

I really wouldn’t worry about writing a formal constitution, or registering a legal entity, just yet. Having served on the governance group of organizations that have these (and written a constitution for one), I can tell you it’s essential to make sure you’re ready for the administrivia work that maintaining a legal entity requires. There’s a lot of administrational plates to get spinning before you get to that point.


Yes there is, it’s called a fork. Large free code project depend on many contributors; engineers and designers but also documentation writers, bug reporters, community managers, morale upkeepers and all sorts of other undefined roles. When the people controlling a project lose the goodwill of that community, and refuse to compromise, the community can take a copy of the code and create a new project to do things their way.

This happened when the OpenOffice developers walked away after they were acquHired by Oracle, and formed the Document Foundation and LibreOffice. This is a last resort, it creates a bunch of disruption, and extra admin and community regrouping work. But it’s there as a final failsafe that protects free code projects in the (rare) event that benevolent maintainers become unreasonable despots. Because it’s there, most maintainers make the effort to stay in touch with the needs and concerns of their communities, and do their best to be good leaders, not bad bosses.

1 Like

Since there has not really been any movement or even proper conversation on this topic, I decided to take the advice of Gargron and #ForkOff

For anyone who wants to know what #ForkOff is about, it’s basically focusing om Mastodon Project Governance, but in a fork.

For the most important bit of that thread:

No one can #ForkOff alone, but together we may be able to.

I present to you: The Great Fork-Off Survey of 2018

For anyone who’s concerned that forking is a hostile action I got you covered with this thread:

But it can easily be summed up with: Forking is Self-Care


I think there is an important factor to incorporate into this discussion:

We have to identify wishes or demands regarding the network as a whole, the server and the client software. I am afraid that many of suggestions are concerning fediverse as a whole, not just purely Mastodon software (“tootsuite/mastodon” on GitHub). I think that’s a source of many misconceptions regarding alternative software like Pleroma.

So the question is:

  1. What are requirements directed at the federated protocols (OStatus/ActivityPub, the protocol)
  2. What are requirements regarding some specific non-standard extensions (conventions)
  3. What are requirements regarding the client and the user interface

As I have stated on the toot I would like to start documenting the current state of 2, the unofficial extensions which make it really “the Mastodon network”, which is not GNU Social and not even Pleroma.

Finding consensus on protocol and conventions will be difficult. Disagreements here have lead already to instance blocking and the network split may happen which will destroy the biggest value we have: federation

I understand that non-technical users may have trouble identifying if they wish or requirement are part of 1, 2 or 3 and it would be good if more savvy users could help
to categorize that.

There are already labels on the tootsuite’s GitHub like activitypub, ostatus webfinger for protocols. User interface ui has its own big category.

1 Like

Okay forkers aside, what we basically need now is the thumbs tentatively raised from Gargron to put our heads together on this and come up with some proposals

I imagine there’s a broad range of ideas out there and I’d be happy to volunteer to collate what we here have (and indeed beyond) if people are happy for me to do so

1 Like

This is drifting off the topic of Mastodon governance, and into the larger top of fediverse governance. There has been some speculative discussion on this here:

Briefly though:

As I have stated on the toot I would like to start documenting the current state of 2, the unofficial extensions which make it really “the Mastodon network”, which is not GNU Social and not even Pleroma.

I would like to see Mastodon (and any forks) fully implementing the ActivityPub spec both the server>server and server>client protocol sets, and documenting anything it wants to do that really can’t be done within the spec as formalized AP extensions. I would like to be able to create a new app, implement the AP spec, and be able to federate with Mastodon instances out-of-the-box without having to reverse engineer any inessential weirdnesses.

There are heaps of people creating new AP-compatible apps, and if AP is successful, there will eventually be hundreds (or thousands!). If every app has to maintain a ticket for debugging federation with every other app, it cannot possibly scale, which defeats the whole purpose of having a common standard. Imagine if every email server or client had to have an open ticket for debugging federation with every other one!


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. ¯\_(ツ)_/¯

1 Like

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.

1 Like

Firstly, I just want to point out that like the comment I’m replying to here, this comment isn’t related to the topic (Mastodon project governance), and unless you too like to geek out on arcane free code history, I suggest you ignore both comments. But there are a few mistakes here I think ought to be corrected, and since I’ve been accused of “deriving into ideological perspective” (whatever that means), I’m going to claim a right of reply.

OK, so clearly you’re here to split hairs, because you’re picking on the admittedly loose way I used the word “fork”, while completely ignoring the main point made in that paragraph. Which was that Gargron had a problem with the way GNU social was being developed, but instead of harrassing and dogpiling the GS devs about it, he started his own project where he could do things his own way. This would be just a true if he had forked the GS code, instead of forking the GS functionality (birdsite-like microblogging) and recoding from scratch in a language/ framework he was more familiar with. Takeaway: forking is not some nuclear option to be avoided at all costs, it’s a normal part of how volunteer-driven free code evolves.

Since we’re splitting hairs, this is almost right. Matt’s GNU social and Mikael’s Free Social were both soft forks of StatusNet that came about because Evan had stopped actively developing StatusNet, orphaning a load of instances that had been running it since the peak of’s popularity (right before Evan switched to and rendered it mostly unusable). In 2013, Evan made his abandonment of StatusNet official, and the various soft forks were re-united under the GNU social banner. Not long after, OpenSocial Foundation merged its standards work with that of the Social Web WG, but I’m not aware of any OpenSocial code being merged into GNU social (think I missed something there? Citation please).

Re-coding from scratch, instead of taking the best bits from a number of soft forks, would have been better strategy? Would Mastodon ever have existed (or postActiv, or Pleroma etc), if Matt and Mikael hadn’t pulled the existing OStatus fediverse together on one actively maintained codebase, and given them a critical mass of existing instances to bootstrap off? Counterfactuals are hard, but I doubt it.

Sure. But this is an argument against hard forks. Soft forks (like, as a sandbox for testing different approaches, are part of that politics, and arguably a more useful contribution to it than labouring the point on mailing lists or GH issues. Besides, as I said in the original post, Gargron and a bunch of other people have

… and …

… which I why I now see a fork as both unavoidable and, given some of the behaviour on both sides, desirable.

As others have pointed out, Gargron’s appearance of heroic productivity is, at least in part, a consequence of implicitly taking credit for work other people have done.

Is either the back-end or UI of Mastodon even the best tool for the job the #ForkTogether folks want done? I’d say no, on both counts. IMHO Pleroma is a better AP server than Mastodon, especially on older / under-powered devices, and Pinafore is a better #UX than Gagron’s sensory-overload-inducing TweetDeck mashup, especially on smaller screens. This is why I proposed that a big part of the problem is issue #1, people not even realizing they have a choice of software, not just a choice of instances, and thinking Gagron is God-Emperor of the whole fediverse, rather than just the corner of it that (for whatever reason) gets the most attention from tech bloggers.

1 Like

I don’t personally have much of an opinion on this conversation, but I couldn’t let this statement go without comment.

Have you critically looked at the on-boarding process of Pleroma or Gnu Social? Here is the link for Pleroma: What Is Pleroma? | Lainblog and for GNU Social GNU social · GNU Network Services. Like it or not, does a fantastic job of presenting at least some of the ideas of what makes all of this software special. Not sure if @Gargron did that work or not, but the design and copy for the on-boarding experience is far superior to the other options out there.

Can we stick to the traditional use of the word “fork” where one takes existing codebase and something new or different is built using that? What you describe as “soft-fork” is just another implementation of a protocol.

It sounds like a hair splitting but the difference is crucial as I have tried to explain above. No one can be the “God-Emperor” of the fediverse if they do not fully control the protocol.

1 Like

For the sake of a civil conversation here:

The linked article contains little details about “taking credit for work other people have done”. What the linked story says is

he effectively takes the credit for others’ work. If he doesn’t mention that it was someone else’s, I will assume an idea was his.

(emphasis mine)

This is just an assumption on the author’s side and a rhetoric device.

I kindly ask you to substantiate claims such as “implicitly taking credit for work other people” with actual examples, quotes and links and not just possibly defamatory opinions.

1 Like

Sure, I was on a GNU Social site before it tanked, and I was forced to choose a new host. Before GS was a thing, I used (until it switched to and basically died), and Diaspora. I’ve checked out and tested Pleroma, as well a number of other fediverse apps.

He didn’t, and in some cases folks had to go to some length to convince him it was worthwhile. The fact that you don’t know this is a good illustration of one of the main gripes former Mastodon supporters have with the way the project is currently governed.

I agree, I’m just not sure what it has to do with the topic or anything I said.

Sure. Can we use our replies to address the substance of what people have said, rather than splitting hairs about their spelling, grammar, or choice of terms? Thanks :slight_smile:

What you’re describing is a re-implementation, but as I’ve now explained twice, the consequences of creating Mastodon would likely have been exactly the same if he had forked GNU social instead of re-implementing it.

As I laid out in an earlier post:

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.

These are widely used terms. Your preferred web search tool will supply plenty of examples.

Of course, that’s precisely my point. Gargro is only the God-emperor of Mastodon, but I suspect some people are confused into thinking that Mastodon = fediverse, and that to have anything work differently in the fediverse Gargron has to approve it and merge it into Mastodon. Which of course is not the case.

Seems to me it’s pretty widely understood to be the case, and the post I linked and its follow-up gave a number of specific examples. You are f course entitled to the opinion that these are just “opinion”. I think it’s a fairly minor issue myself, but if it’s happening at all, it is bad form for a peer production project that benefits from unpaid contributions, and I’m very aware that since I’m not one of the people affected by it, it’s easy for me to dismiss it as minor.

This confusion comes precisely due to inconsistent terminology, which turns any discussion into a meaningless babble. See below.

I have checked some and it seems that this is more often than not used to describe compatibility issues in blockchain-based consensus protocol. Here is an interesting quote:

What we are talking about is software fork - something that predates git and blockchain.

And the issue of protocol compatibility between different implementation of the same protocol is a question of interoperability. For example, whether GNU social interprets message’s summary field in the same way as Mastodon - it is a question of good or bad interoperability.

(arguably manipulative emphasis mine)

So you are repeating stories and hearsays and now you say this is all hypothetical. I’d prefer to talk about particular events, comments and code. Especially before accusing someone of acting against the community’s interest.

I have given definitions in this thread for what I intend to be understood by “hard fork” and “soft fork”. If you have preferred terms for these definitions, let me know what they are. Otherwise, you’re just splitting hairs.

I agree, this is manipulative emphasis, because the most important parts of the quoted text, the ones that honest emphasis would highlight, are:

  • “the post I linked and its follow-up gave a number of specific examples”
  • “I think it’s a fairly minor issue myself”

The parts you emphasize simply make it clear that I’m open to the possibility I’ve been misinformed, and either way I’m not interested in arguing about it. This is my final comment on the subject. I’m not sure what you think will be accomplished by trying to dress up these comments as some kind of sinister plot. If you think you can somehow prevent a fork that is unavoidable and desirable (for both the Gargron fan club and the #ForkTogether folks) by arguing with a casual user who is isn’t part of either camp … well … good luck with that.

Fair enough. Sorry for bothering you with questions that probably should go somewhere else!

Sure, we can agree on this. Still, as @saper mentioned, forking is a technical term that refers to ‘taking away’ the existing code base to build new governance around it. So in the case of #ForkTogether, you’re indeed talking about a fork – and no, this is not splitting hair, this is correcting wrong usage, as you did with my wrong mention of OpenSocial in place of Free Social in the history of GNU social, and I thank you for that.

You might want to call soft fork what happened between StatusNet, Free Social and GNU Social, given that all three use the same language and eventually were merged together. But I don’t think there’s the slightest chance of merging Mastodon with GNU social, or for that matter, Mastodon with Pleroma. Even if the key aspect of a concurrent implementation is how the project is handled by its community, it would only be considered a fork if it would start off the same code base.

Having different opinions doesn’t make a fork, although of course it can trigger one. What is important here I guess is whether the #ForkTogether fork intends to be friendly to Mastodon so as to eventually merge back in the future, or whether the governance split also means a technical divergence.

1 Like