Mastodon project governance


#41

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


#42

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


#43

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 Identi.ca) 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 Identi.ca running StatusNet cost him, and how pump.io 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.


#44

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 Identi.ca’s popularity (right before Evan switched to pump.io 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 Glitch.social), 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.


#45

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, joinmastodon.org 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.


#46

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.


#47

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.


#48

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 Identi.ca (until it switched to pump.io 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.


#49

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.


#50

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.


#51

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.


#52

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


#53

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.