Código aberto != trabalhar abertamente — July 15, 2019

This is a 9 min read filed under pt-br > essays > free software

Mastodon é uma das mais bem sucedidas soluções de software para a rede social federada e descentralizada chamada Fediverso. As estatísticas disponibilizadas por Sp3r4z nos mostram alguns números interessantes sobre ela: há 3.173 instâncias ativas do Mastodon somando 1.510.563 contas 1. Usando o lema “Você no controle de sua rede social”, Eugen Rochko apresenta o Mastodon como “uma plataforma que pertence à comunidade e livre de anúncios” 2, que “visa ser um lugar mais seguro e humano”3. Entretanto, ao olhar de perto, a ausência de encorajamento para participar do desenvolvimento do Mastodon em todos os materiais promocionais produzidos, ainda que ele esteja se tornando um projeto de software livre famoso, revela um elefante na sala: uma história de recusa em trabalhar abertamente, e a ideia de que o Mastodon não é um projeto guiado pela comunidade, que acolhe contribuições – na verdade, ele é considerado por seu criador apenas como um projeto pessoal.

“Olha, vocês todos estão aqui porque eu construí o Mastodon da maneira como eu quis e vocês por acaso curtiram. Se vocês não curtem mais é problema de vocês, não me encham o saco com as suas expectativas não correspondidas. A porta está ali, o código está ali, há alternativas. A merda que eu recebi hoje só porque eu estava aberto a algo que parte da comunidade queria é completamente inaceitável.” – Um toot escrito por Eugen Rochko em 2 de junho de 2018 em resposta à controvérsia dos Trending Topics

É hora de falar sobre o que aconteceu na comunidade do Mastodon – e, mais importante, como evitar que a mesma coisa aconteça em outras.

Sobre elefantes e batalhas sem fim

Deixei o Twitter e entrei no Fediverso um ano atrás. No início, parecia um paraíso – fui acolhida por comunidades maravilhosas e lá era um lugar em que eu poderia ser queer e estranha sem culpa. Enquanto o Twitter me passava a impressão de ser um lugar com competições por atenção, engajamento e retenção de audiência sem fim – o que geralmente levava a revoltas e mais conteúdo inflamatório –, Mastodon era mais como um encontro local em que você poderia ter conversas sensíveis e sinceras sem ter medo de hostilidade. Não demorou muito para que eu quisesse ajudá-lo a ter sucesso de alguma forma, e isso resultou em minhas primeiras contribuições a um projeto de software livre.

Mas assim que comecei a seguir o desenvolvimento do Mastodon atentamente, problemas de comunicação entre a comunidade e Eugen, especialmente quando ele expressava opiniões problemáticas, começaram a chamar a minha atenção: por exemplo, a sua opinião sobre design acessível.

Usuário: Reprodução automática de GIFs? Por que isso não é desligado por padrão para tornar instâncias mais acessíveis a pessoas que precisam evitar certas animações por motivos de saúde? Realmente gostaria que acessibilidade fosse uma prioridade maior.

Eugen: Porque você não tem uma sessão ativa. Isso é uma configuração para quando você tiver uma sessão ativa, mas quando não, você obviamente não pode personalizar coisa alguma. Já quanto a se GIFs devem ser reproduzidos automaticamente, em geral, eu acho que é o comportamento esperado deles. É como funciona no Tumblr, por exemplo, e as pessoas criam conjuntos de GIFs bonitos e encantadores. Acho que queremos enfatizar que isso é possível no Mastodon também.

Usuário: “Comportamento esperado” é o motivo pelo qual a internet não é um lugar acolhedor para pessoas com deficiência. “É como a internet funciona” é um tanto desdenhoso e pouco prestativo, e meio que frustra o propósito de tentar ser uma rede social melhor. Pensei que o Mastodon fosse diferente… ?

Eugen: Você tem direito a sua opinião sobre isso, mas só porque eu não concordo com você nesse problema de nicho não apaga todas as outras maneiras em que o Mastodon é diferente.

– Conversa sobre reprodução automática de GIFs na pull request sobre o redesign da página inicial4. Tivemos dois dias de discussão até que ele aceitasse a opinião da comunidade sobre isso.

Um debate similar aconteceu quando usuários imploraram para que ele implementasse uma funcionalidade de descrição de imagens como a do Twitter. Apesar de ter sido implementado – não sem uma discussão longa sobre como eram necessários mais que 140 caracteres ou que não importa se pessoas a usam como uma maneira de aumentar o número de caracteres de toots já que o maior benefício dessa ferramenta supera tudo isso –, o seu design dá a impressão de ter sido feito às pressas, e muitos usuários ainda sofrem para usá-la.

Desde então, à medida que o Mastodon crescia, eu lentamente percebi que debates exaustivos sobre funcionalidades importantes para grupos marginalizados começaram a se tornar não a exceção, mas a regra. Eis que tive uma epifania – a comunidade e Eugen não estavam trabalhando juntos para fazer um software melhor. Estávamos em uma batalha permanente com uma pessoa que constantemente promove o Mastodon como uma alternativa ética ao Twitter para convencê-lo a incorporar aspectos de design importantes para torná-lo acessível e inclusivo. Isso não é uma parceria – é um estado de conflito velado.

“O ativismo queer foi o catalisador de mudanças para o Mastodon desde o começo, e muitas de suas funcionalidades mais definidoras jamais teriam existido sem ele. Mas Gargron se recusa a reconhecer isso, ou mudar para ser transparente para permitir que isso se torne uma influência mais forte, para permitir mudanças positivas. Ao invés disso, ele chora sobre isso publicamente, de forma mesquinha, e culpa as pessoas que fizeram do Mastodon o que ele é agora.” – Mastodon’s Complicated Relationship with Queer Activism, um texto excelente por Hoodie, uma das pessoas contribuidoras mais vocais dos primeiros dias do Mastodon

Não levou muito tempo até que os dois lados do conflito entrassem em uma briga feia que ficou conhecida como a controvérsia dos Trending Topics. Como Cass – uma pessoa que se esforçou bastante para receber bem novos usuários do Mastodon por meses – resumiu em sua postagem sobre o porquê de ter deixado o Mastodon:

Qualquer pessoa contra a ideia e que sabia como usar o GitHub foi até a lista de issues e se opôs ali. Elas disseram que os Trending Topics no Twitter são usados para atrair [assédio] e abusar de pessoas vulneráveis. Era tudo muito vago, mas ao invés de pedir por exemplos específicos para que ele pudesse julgar se o software poderia prevenir (ou mudar para prevenir) o abuso de usuários, Gargron insistiu em permanecer com a sua posição. Então ele fez piadas sobre vítimas de abuso em redes sociais, tornando claro que ele não leva as suas preocupações a sério, enquanto reclamava abertamente das pessoas que enfaticamente faziam parte da oposição e compartilhava postagens de pessoas publicamente o apoiando e condenando a onda de objeções. Ele foi mesquinho e passivo-agressivo. Ele dizia que as pessoas estavam tirando as suas palavras do contexto e as usando para atacá-lo. É possível que isso seja verdade, e se é, isso é injusto; mas é também claro como ele se sente a respeito de objetivos antiabuso na declaração de missão: ele só reconhecerá abuso se acontecer com ele, porque ele só está construindo uma rede social para si.” – I left Mastodon yesterday

Histórias sobre como muitas pessoas se sentiam desconfortáveis ao interagir com Eugen começaram a aparecer – até eu tenho algumas. Uma parte da comunidade começou a trabalhar no ForkTogether, iniciado pela ex-gerente de projetos do Mastodon, Maloki. E enquanto esperamos pelo surgimento de uma melhor alternativa, nos perguntamos: o Mastodon não deveria ser melhor que isso?

Trabalhando abertamente

Mark Surman, diretor-executivo da Mozilla Foundation, define três princípios como a fundação da liderança aberta:

  1. Tomada de decisão compartilhada, dando à comunidade o poder de estruturar o projeto e apontá-lo para uma direção melhor.
  2. Distribuir conteúdo e código, como uma maneira de encorajar a comunidade a maximizar a “utilidade” do projeto.
  3. Incentivar participação, acolhendo pessoas de diferentes perspectivas e se certificando que há recursos para ajudar aqueles que estejam interessados em participar a se juntar ao projeto facilmente.

O que foi exposto neste texto revela que o Mastodon não segue os princípios (1) e (3) – e isso representa um severo risco à longevidade do projeto.

Software livre não consegue resolver o desequilíbrio de poder entre usuários e criadores de software sozinho ao oferecer a possibilidade de executar, estudar e distribuir cópias originais e modificadas. Tal abordagem falha em reconhecer que os problemas que enfrentamos com softwares proprietários vão além dos aspectos tecnológicos, e que é possível reproduzir facilmente padrões tóxicos em projetos abertos. Esforços colaborativos precisam de muito mais do que tornar o código disponível para todos, sendo primariamente baseados em interações humanas e trabalho emocional. Trabalho colaborativo precisa de:

  1. Reconhecimento. Voluntários depositam muitas horas e energia em suas contribuições porque sentem que estão ganhando algo daquela experiência (melhoramento de habilidades ou uma rede de contatos mais diversa, por exemplo). E como a maioria deles realiza as suas atividades em seu tempo livre, contribuir é um privilégio que muitas pessoas não podem ter. Sua participação deve ser encorajada, apreciada e creditada. Voluntários não devem ser tratados como uma maneira fácil de conseguir trabalho de qualidade sem qualquer pagamento apenas para beneficiar o criador do projeto.
  2. Comunicação simples. Você precisa incluir pessoas de várias origens e níveis técnicos. Nunca assuma coisa alguma – faça perguntas e continue a conversa de forma apropriada, mas sem ser condescendente. Desencoraje o uso de expressões como “obviamente”, “todo mundo sabe”, “é claro que…".
  3. Escuta ativa. Oferecer uma plataforma onde as pessoas possam discutir aspectos importantes do projeto não é suficiente quando você não escuta as suas preocupações e as aborda propriamente, reconhecendo a contribuição de outras pessoas nos debates. Mais importante, reconheça quando a sua perspectiva é limitada, considere diferentes perspectivas, e assuma responsabilidade e se desculpe se você cometer um erro.
  4. Cuidado. Escrever um código de conduta e aplicá-lo não é opcional, mas também não é trivial. Não há um jeito fácil – a segurança pessoal dos membros da sua comunidade deve ser considerada uma prioridade. Tenha uma equipe de resposta a incidentes, treine-os para responder às violações mais comuns, escreva um roteiro para tornar o processo de resposta o mais automático possível – mas sem perder a empatia e a humanidade.
  5. Liberdade ao seu projeto. Você deve agir como se amanhã fosse o seu último dia no projeto e fazer tudo para que a existência dele não dependa de você. Delegue responsabilidades, e documente o seu trabalho.

Ter uma experiência tão ruim com o Mastodon foi doloroso, mas significativo. Ela modificou a maneira como vejo projetos abertos, tornou claro para mim que uma comunidade diversa e engajada pode fazer toda a diferença do mundo para o melhor – assim como um “ditador benevolente” pode ter o efeito oposto. E me fez perceber que nós definitivamente podemos fazer melhor do que isso.


  1. Dados coletados no dia 28 de agosto de 2018 às 7:28 PM (UTC).

  2. Trecho retirado do website do projeto, joinmastodon.org.

  3. Trecho retirado da postagem “Learning from Twitter's mistakes”.

  4. Trechos integrais retirados da pull request. Ênfases minhas.


Anna e só is a documentarian who loves working with open projects and takes pride in offering them a unique point of view. ⌨

👋 Related posts in the Trabalhando abertamente series...

No follow up posts yet. Check back soon!