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;
- As @saper pointed out, some confusion about which decisions only affect Mastodon.social (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)
- Two overlapping but different sets of design goals for the UI
- 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.