Open code != working open
Mastodon is one of the most successful software solutions to the decentralized, federated social network called the Fediverse. Sp3r4z’s stats has some interesting numbers about it: there are 3,173 active Mastodon instances summing up 1,510,563 accounts1. Using the motto “Social networking, back in your hands”, Eugen Rochko presents Mastodon as “a platform that is community-owned and ad-free”2, that “aims to be a safer and more humane place”3. However, looking closely, the absence of encouragement to participate in Mastodon’s development in all promotional material produced, even though it’s becoming a famous free and open source software project, reveals an elephant in the room: a history of refusal to work open, and the idea that Mastodon isn’t a community-driven project that welcomes contributions – it is, in fact, considered to be a personal project by its creator.
“Look y’all here because I built Mastodon the way I wanted and you happened to like it. If you no longer like it that’s your own business, don’t give me shit about your failed expectations. There’s the door, there’s the code, there’s the alternatives. The shit I’ve received today just because I was open to something that a part of the community wanted is completely unacceptable.” – A toot written by Eugen Rochko in June 2, 2018 in response to the Trending Topics controversy
It’s time to talk about what happened in the Mastodon community – and, more importantly, how to avoid that such thing to happen in others.
About elephants and uphill battles
I left Twitter and entered the Fediverse one year ago. At first, it felt like paradise – I was welcomed by amazing communities and it was a place I could be queer and weird without any guilt. While Twitter felt like a never-ending competition for attention, engagement and audience retention – what usually led to outrages and more inflammatory content –, Mastodon was like a local gathering you could have heartfelt and sincere conversations without fearing hostility. Soon I felt the need to help it thrive somehow, and that resulted in my first contributions to a free software project.
But as I followed Mastodon’s development more closely, communication problems between the community and Eugen, especially when he expressed problematic opinions, started to catch my attention: for instance, his opinion on accessible design.
User: GIF autoplay? Why isn’t this opt-in, in order to make instances more accessible to people who need to avoid certain animations for health reasons? I really wish accessibility would be made more of a priority.
Eugen: Because you’re logged out. This is a setting when you’re logged in, but when you’re logged out, you obviously can’t customize anything. As to whether GIFs should default to autoplay in general, I think it is the expected behaviour that they do. That’s how it works on Tumblr, for example, and people create beautiful, captivating GIF sets. I think we want to highlight the fact that this is possible on Mastodon as well.
User: “Expected behavior” is why the internet is not very hospitable to people with disabilities. “That’s just the way the internet works” is kind of dismissive and unhelpful and sort of defeats the purpose of trying to be a better social network. I thought Mastodon was different… ?
Eugen: You are entitled to your own opinion on this, but just because I do not agree with you on this niche issue does not erase all the other ways in which Mastodon is different.
– Exchange on GIF autoplay on the pull request concerning the front page redesign4. It took him two days of discussions to accept the community’s position on this.
A similar debate happened when users urged him to implement an image description feature like Twitter’s. And while it eventually made it to the code base – not before a long debate about how it needed to offer more characters than 140 or how it doesn’t matter if people use it as a way to increase toots character count as the main benefit of this feature surpasses all of this –, its design felt like an afterthought and a lot of users still struggle to use it.
Since then, as Mastodon grew, I slowly realized that exhausting debates on important features to marginalized minorities started to become not the exception but the rule. Then it struck me – the community and Eugen weren’t working together to make a better software. We were in a constant uphill battle with a person who constantly promotes Mastodon as the ethical alternative to Twitter, to convince him to incorporate important aspects of software design to make it accessible and inclusive. That isn’t a partnership – it is a covert state of conflict.
“Queer activism has been the catalyst of change for Mastodon from the beginning, and many of it’s most defining features would never have come into existence without it. But Gargron refuses to acknowledge that, or change for transparency to allow for this to be a stronger influence, to allow for positive change. instead he whines about it publicly, pettily, and places the blame on the people who made Mastodon what it is now.” – Mastodon’s Complicated Relationship with Queer Activism, an excellent post by Hoodie, one of the most vocal Mastodon contributors from the early days
It didn’t took long until both sides engaged in an ugly altercation that would become known as the Trending Topics controversy. As Cass, a person who put a lot of effort to welcome newcomers to Mastodon for months, summed up in their post on why they left Mastodon:
Anyone against the idea and who understood how to use Github went to the issue list and objected there. They said that trending topics on Twitter is used to attract and abuse vulnerable people. It was all quite vague, but instead of asking for specific examples of abuse so that he could judge whether the software can prevent (or be made to prevent) abuse of members, Gargron dug his heels in. Then he made fun of the victims of social media abuse, making it clear that he doesn’t take their concerns seriously, while also complaining openly about people objecting vocally to his decisions and boosting toots by people publicly supporting him and condemning the wave of objection. He was petty and passive-aggressive. He complained that people were taking his words out of context and using them to attack him. That may be true, and if it is it’s unfair, but it’s also clear how he feels about the anti-abuse goals in the mission statement: he will only recognise abuse if it happens to him, because he is only building a social network for himself." – I left Mastodon yesterday
Stories about how a lot of people felt uncomfortable interacting with Eugen started to pop up – and I have some myself. A part of the community started working on ForkTogether, which was initiated by Mastodon’s former project manager, Maloki. And as we wait for a better alternative to appear, we ask ourselves: wasn’t Mastodon supposed to be better than this?
Working open
Mark Surman, executive director of the Mozilla Foundation, defines three principles as the foundation of open leadership:
- Sharing decision-making, giving the community the power to shape the project and point it to a better direction.
- Distribute content and code, as a way to encourage the community to maximize the “usefulness” of the project.
- Inviting participation, welcoming people from different perspectives and making sure there are resources to help those interested in participate to join easily.
Unsurprisingly, Mastodon lacks both (1) and (3) – and that represents a severe risk to the longevity of the project.
Free software can’t solve the power imbalance between users and software makers alone by giving to the former the possibility to run, study, and distribute both original and modified copies. Such approach fails to acknowledge that the problems we face with proprietary software go beyond technological aspects, and that is possible to easily reproduce toxic patterns within open projects. Collaborative efforts take a lot more than just making the code available to anyone, being primarily based on human interactions and emotional labor. It takes:
- Recognition. Volunteers pour a lot of hours and energy into their contributions because they feel they are gaining something out of that experience (improved skills or a more diverse network, for instance). And as most of them perform their duties in their spare time, contributing is a privilege that many people can’t afford. Their participation has to be encouraged, appreciated and credited. They should not be treated as an easy way to get quality work without any kind of payment for your own personal benefit.
- Simple communication, as you need to include people from all kinds of backgrounds and technical levels. Never assume someone is in the same technical level as you – ask questions and follow through appropriately but without being condescending. Discourage the use of expressions such as “obviously”, “everybody knows”, “it’s pretty clear that…”.
- Listening. Offering a platform they can discuss important aspects of the project isn’t enough when you don’t listen to their concerns and address them properly, acknowledge their contributions to debates. More importantly, recognize when your perspective is limited, take into account different points of view, and step back and apologize if you make a mistake.
- Caring. Writing a Code of Conduct and actually enforcing it isn’t optional, and it isn’t trivial either. Don’t cut corners on this – the personal safety of community members need to be considered a priority. Have an incident response team, train each other to address the most common violations, write a script to make the response process as automatic as it can be.
- Setting your project free. You should act as tomorrow was your last day at that project and make everything possible to make its existence not dependent on you. Delegate responsibilities, and document your work properly.
Having such a bad experience with Mastodon was painful, but meaningful. It shaped how I see open projects, it made clear to me that a diverse, engaged community can make all the difference in the world for the better – just as a “benevolent dictator” can have the opposite effect. And it made me realize that we can definitely do better than this.
-
Data collected on August 28, 2018 at 7:28 PM (UTC). ↩︎
-
Quotes taken from the project website, joinmastodon.org. ↩︎
-
Quote taken from his blog post “Learning from Twitter’s mistakes” ↩︎
-
Direct quotes taken from the referred pull request. Emphasis with italics are mine. ↩︎