Democracia

O Ansel deve ser conduzido de forma democrática e justa para todos os envolvidos.

Definindo uma organização cooperativa além do código de código aberto

Presume-se que desenvolvedores e usuários que chegam aqui compartilham um interesse comum: eles querem liberdade sobre como editam suas fotos, agora e no futuro. Ou seja:

• ter um controle técnico suficiente sobre o conteúdo e as propriedades de suas imagens,
• estar livres de capitalistas que possam:
  • aumentar o preço de seu aplicativo em benefício exclusivo dos acionistas,
  • minerar as fotos dos clientes para treinar modelos de IA sem consentimento,
  • extinguir aplicativos sem liberar o código-fonte,
• ter o direito de decidir sobre os contornos e a implementação da referida liberdade.

O DNA do Ansel é mais tecnicamente orientado e minucioso do que a maioria dos editores de fotos RAW, embora ainda enfatize a facilidade de uso onde é possível, principalmente em tarefas típicas centradas no desktop (interações com dispositivos de entrada e arquivos, paradigmas de interface gráfica, etc.). O Ansel não é o Darktable  nem o ART  porque sua visão do que um bom software de retoque de imagem deveria ser é bem diferente.

O Ansel é distribuído sob a licença GNU/GPL , o que o torna um software livre/de código aberto. Embora isso dê uma (falsa) sensação de disponibilidade a longo prazo, a realidade é que sua disponibilidade a longo prazo depende exclusivamente da vontade e da capacidade de alguns desenvolvedores de realizar a (tediosa) manutenção cotidiana para mantê-lo funcionando, continuar oferecendo suporte a novas câmeras, etc., o que é uma tarefa subvalorizada porque não produz notas de versão nem apresentações espetaculares.

Pior, a chamada “liberdade” concedida pela licença GNU/GPL afeta apenas o código-fonte: é a liberdade do engenheiro. As licenças de código aberto essencialmente renunciam à propriedade intelectual sobre o código, o que significa que os engenheiros podem estudá-lo e modificá-lo, e depois compartilhar suas modificações. Dado que menos de 6 % da população mundial¹ consegue de fato escrever código, esse é um direito de apenas uma minoria privilegiada. Quanto aos usuários, bem, a licença GPL é bastante clara:

Este programa é distribuído na esperança de que seja útil, mas SEM QUALQUER GARANTIA;

Essa afirmação essencialmente exclui os usuários finais da transação: eles não têm outros direitos além de executar o código como está, especialmente nenhum direito a obter suporte e correções de bugs, muito menos ter o software moldado às suas necessidades. Se algum suporte ainda é oferecido, isso fica a critério dos desenvolvedores, e os usuários deveriam ser eternamente gratos por isso. Isso é explorado nas chamadas “comunidades de código aberto” (ou seja, “fóruns de software”) para calar e invalidar qualquer reclamação de usuário: eles simplesmente não podem reclamar, já que estão usando um trabalho gratuito, mesmo que o marketing dos projetos de código aberto muitas vezes se derrame em elogios quanto à adequação “profissional” desses aplicativos. Mas… promessas foram feitas, a palavra “pro” foi pronunciada mas não cumprida, então há uma inconsistência enganosa em algum lugar.

Mesmo abrindo mão de qualquer responsabilidade para com os usuários, muitos projetos ainda tentam transformá-los, se não em clientes, ao menos em doadores. O que enfrenta um triste estado de coisas: 350 anos de capitalismo apodreceram nossos cérebros a ponto de nos fazer pensar que os aplicativos de código aberto eram o concorrente mais barato do software proprietário. Os usuários simplesmente ficam sentados esperando que os projetos entreguem um produto antes de decidir se vão se dar ao trabalho de doar. Isso é como começar a financiar a NASA depois que o primeiro foguete foi lançado para provar que o projeto de fato consegue entregar: não pode ser assim. Você precisa pagar pelo trabalho mesmo antes de haver um produto para vender. E quando o produto é lançado, projetos como a Wikipédia ainda têm dificuldade em obter menos de 3 $/ano de 2 % de sua base de usuários.

Os aplicativos de código aberto são concorrentes dos aplicativos proprietários assim como os hospitais públicos são concorrentes das clínicas privadas: eles não são. De um lado, temos um projeto socialista iniciado pela crença de que todos têm direito à saúde e, se não puderem pagar por ela, daremos um jeito encontrando dinheiro extra na comunidade. Do outro lado, temos acionistas tentando lucrar, contratando cirurgiões que tentam pagar por sua casa em Malibu e sua coleção de Porsches. Como é que eles são concorrentes? Um serviço público é uma forma de garantir que as pessoas tenham recursos para exercer seus direitos, porque a liberdade é apenas teórica até você ter os meios de realmente fazer uso de seus direitos. Uma empresa privada que vende bens ou serviços é uma forma de ganhar dinheiro a partir de investimentos. A diferença é política. É também econômica, já que não ter os acionistas na folha de pagamento torna o produto final mais acessível de qualquer maneira.

O ponto cego do movimento do “Software Livre” foi evitar refletir sobre o contexto e a estrutura de trabalho em que tal software acontece, é desenvolvido e mantido. Isso pode ser rastreado até a cultura hacker , que é individualista por natureza e compatível com o capitalismo por procuração, por meio da tecnofilia  e do tecnossolucionismo . “Compartilhar como está” (seu trabalho, seu código, seus hacks) foi confundido com “cuidar de” (as necessidades, limitações e desafios das outras pessoas) e alimentado com narrativas quase hagiográficas. Quando você tem um martelo, tudo parece um prego: quando tudo o que você conhece é código, o código é a solução para tudo, e tentar envolvê-lo em filosofia e política (não revolucionária) para definir a “liberdade do código” ainda deixa escapar o quadro geral, que é a exploração do trabalho de todos por uma classe social pequena, mas poderosa e autorreprodutora. Embora 6 % da população mundial pudesse escrever código em 2021, a proporção que sequer podia pagar por um computador pessoal nos anos 1980, quando o movimento do Software Livre começou, era muito menor. Minorias privilegiadas são sempre cegas aos seus privilégios: é assim que você as identifica. Elas não conseguiram enxergar que o Software Livre não passava do fruto desses privilégios. É liberdade apenas para quem pode pagar por ela. E o fato de a etiqueta de preço não ter um cifrão anexado a ela a torna perversa. Ela ainda tem uma etiqueta de preço.

O movimento do Software Livre foi feito para se encaixar nesse capitalismo individualista, de livre-iniciativa e de mercado liberal, e fez todo mundo pensar que bastava deixar cada um iniciar seu próprio projeto ou bifurcá-lo dos outros. Então, o darwinismo social  resolveria as coisas. Sim, mas… quem paga pelo trabalho? Pior, já que o capitalismo dá valor ao trabalho apenas quando seu produto é vendido em um mercado liberal, e esse valor é indexado à escassez do produto, como exatamente devemos convencer os usuários de que algo desmaterializado, infinitamente baixável de graça, tem algum valor? Muitos projetos de código aberto tentaram muitas estratégias diferentes para financiar seu trabalho; todas elas são precárias e prejudicadas porque ainda querem encaixar uma estrutura de trabalho que é comunista por natureza dentro de um arcabouço capitalista (mais sobre isso abaixo).

Embora as organizações sem fins lucrativos possam funcionar para projetos humanitários, onde os doadores nunca serão os destinatários do trabalho, no caso de projetos de software, as doações são interessadas porque os doadores são usuários. Isso alimenta um comportamento de consumidor, no qual consumidores passivos (e de certa forma oprimidos) esperam pelos bens entregues por uma minoria de elite de membros do conselho que dá as cartas. Essas organizações sem fins lucrativos ainda são administradas de forma privada, e o público não tem outro direito senão parar de doar se não se sentir ouvido. O conselho da Linux Foundation  é composto quase exclusivamente por executivos de fabricantes de hardware e das GAFAM , o conselho da Free Software Foundation  é composto por cientistas e técnicos de informática. Não há representação de usuários ali, há estruturas hierárquicas verticais dos “que sabem” sobre os “que precisam”, perpetuando o mesmo tipo de dominação que o capitalismo, menos os lucros.

Isso é justificado pelo fato de que as licenças de código aberto abrem mão de qualquer forma de responsabilidade (garantia) dos desenvolvedores para com os usuários, o que torna essa uma transação de mão única que aparentemente dá todo o poder de decisão aos desenvolvedores. Mas tudo isso é, claro, uma construção, e não uma conclusão inevitável. Do outro lado, porque o dogma capitalista está tão profundamente impregnado no cérebro dos usuários, o código-fonte traz um software para um mercado livre, desmaterializado e não escasso que anula qualquer noção de valor capitalista, o que faz com que seja aceitável que os usuários obtenham o produto do trabalho sem contribuir: outra transação de mão única. Enquanto isso, alguns desenvolvedores estão se esgotando e se exaurindo para oferecer um suporte razoável aos usuários, sem obter uma renda razoável de seu trabalho (explorado), talvez na esperança de que isso acabe compensando a longo prazo, uma vez que eles “consigam vencer”. Ou os desenvolvedores aceitam a regra tácita do código aberto (que ele deveria ser apenas um hobby/atividade de meio período), o que inevitavelmente atrasa o código aberto, como um irmão eternamente pobre do software proprietário. Ou, por fim, algumas empresas de código aberto como a Automattic  ou a RedHat  começam a ficar cada vez mais agressivamente gananciosas com o tempo, enfrentando a reação de suas comunidades. Isso não é sustentável, para nenhuma das partes envolvidas.

Precisamos transformar essas duas transações paralelas de mão única em um círculo. É assim:

1. Nenhuma tecnologia pode existir fora da sociedade que a produz. A tecnologia precisa de ciência. A ciência precisa de pesquisa. A pesquisa precisa de estruturas onde possa ser conduzida livremente. A sociedade é o ambiente onde tudo isso acontece, bem como o sistema de apoio que faz com que aconteça.
2. Nenhuma tecnologia pode existir sem trabalho. Se o produto do trabalho escapa ao sistema capitalista (mercado liberal baseado na escassez e na competição), então o trabalho que o produz também deveria escapar a ele.
3. Nenhuma tecnologia de propriedade privada servirá ao bem comum e ao interesse público. As tecnologias, não apenas os dispositivos, deveriam ser de propriedade de seus usuários, não apenas de seus fabricantes.
4. O trabalho é a única riqueza. Os trabalhadores deveriam se beneficiar de seu trabalho, seja ele vendido em um mercado liberal ou não: ele deveria ser pago de qualquer forma. O trabalho deveria acontecer em um ambiente seguro e justo. É uma responsabilidade coletiva e social fazer com que isso aconteça, porque o produto do trabalho serve ao bem comum e ao interesse público. O trabalho que não serve a esses fins deveria simplesmente ser interrompido.
5. As tecnologias de propriedade de seus usuários abrem caminho para um novo tipo de produção: a colaboração entre fabricantes e usuários, em vez da competição entre fabricantes e guerras corporativas para conquistar mercados convencendo os clientes da superioridade de algum produto (fazendo os usuários pagarem pela publicidade no fim das contas…). Mas o capitalismo não sabe como vender o produto da cooperação, porque não há mais um comprador ou vendedor separado, apenas uma comunidade de pessoas que trabalham juntas em direção a algo: atender às suas necessidades, transformando seus direitos teóricos em liberdade real ao criar o contexto para exercê-los.
6. Há uma responsabilidade mútua dos fabricantes para com os usuários (atender às suas necessidades por meio da/com a tecnologia), e dos usuários para com os fabricantes (dando-lhes um ambiente de trabalho seguro e justo e condições materiais de vida). Isso é o básico de uma comunidade²…
7. O código aberto que leva à verdadeira liberdade só pode acontecer dentro de uma estrutura cooperativa . Que é um comunismo antigo, comprovado e já funcional, no qual a empresa (portanto o projeto de código aberto em geral) é de propriedade de seus clientes e de seus trabalhadores, que compartilham os poderes de voto. Isso vai muito além de uma mera renúncia à propriedade intelectual (licença livre/de código aberto).

Uma cooperativa é uma forma de romper essa dicotomia entre “nós” e “eles”, fabricantes vs. usuários, que alimenta o ressentimento mútuo: os desenvolvedores são os ditadores que tomam o aplicativo como seu playground pessoal, aos quais os usuários deveriam ser sempre gratos não importa quanto o destruam, os usuários são as sanguessugas irritantes que ficam levantando issues e pedidos de recursos enigmáticos, enquanto doam muito pouco.

Em uma cooperativa, fabricantes e usuários são igualmente membros-acionistas. Todos eles são donos do projeto, todos eles têm um voto na assembleia geral. O projeto consiste em tornar a edição de fotos livre para o futuro previsível, sob alguma visão unificada do que é a edição de fotos (quão técnica e minuciosa ela deve ser vs. quão fácil e amigável). Para cumprir esse objetivo, muitos meios estão envolvidos, como educação, defesa da causa, documentação e, obviamente, um aplicativo de software. O projeto é mais do que apenas um produto final, que pode levar algum tempo para aparecer e ficar pronto: o projeto é tudo acima e ao redor disso, é um objetivo e todos os meios para torná-lo realidade.

A responsabilidade dos membros é garantir um orçamento anual para cobrir todos os custos do projeto, muito provavelmente a partir das mensalidades anuais dos membros. A partir desse orçamento, uma certa quantidade de horas de trabalho a uma certa taxa horária é decidida em assembleia geral. Como esse orçamento será gasto (que tipo de tarefas, hardware, ferramentas, etc.) também é decidido em assembleia geral. Para tarefas técnicas, como o desenvolvimento de software, essas serão as orientações de alto nível (como melhorar o mascaramento, o fluxo de trabalho em lote, etc.) e não os detalhes de implementação ou o design em si, que são pouco adequados para processos democráticos. Os desenvolvedores podem impulsionar tarefas voltadas ao backend (como reescrever ou refatorar dívida técnica, para reduzir o custo de manutenção a longo prazo), os usuários podem impulsionar tarefas voltadas a recursos (como oferecer suporte a novos recursos de câmera, formatos de imagem, etc.): o propósito da assembleia geral é deliberar e classificar as prioridades.

As tarefas acordadas serão então tratadas por trabalhadores remunerados na ordem de prioridade até que o orçamento de trabalho seja consumido. Isso não se limita ao trabalho tecnológico e ao desenvolvimento, mas se aplica a qualquer tipo de trabalho previamente acordado. Quando o orçamento é consumido, os trabalhadores relatarão onde pararam na lista de tarefas, o que conseguiram terminar, o que não conseguiram e quais recursos faltaram para terminar. A assembleia geral então decidirá se é possível e desejável investir mais recursos para terminar, ou passar as tarefas restantes para o orçamento anual seguinte. Isso dá aos trabalhadores visibilidade sobre sua renda anual sem promover o excesso de compromisso e o esgotamento.

Os usuários podem formar painéis para trabalhar com os desenvolvedores na compreensão dos problemas reais enfrentados, testar e validar soluções em um processo de design. Qualquer usuário pode ser transformado em trabalhador e começar a receber renda por seu trabalho em tarefas acordadas, mediante aprovação da assembleia geral.

Isso faz com que seja responsabilidade de todos garantir que os recursos para seguir adiante sejam reunidos, e dar aos trabalhadores o que eles precisam para trabalhar de forma decente, segura, sem serem explorados. Nenhuma quantidade de trabalho deveria ser gratuita, não importa a tarefa. O trabalho não deveria se limitar à programação ou a outras tarefas técnicas.

Os limites da democracia

A democracia por voto é essencialmente a expressão da vontade da maioria, que já é conhecida por oprimir minorias. Ela não é, portanto, perfeita. As minorias podem manifestar preocupações razoáveis e legítimas, só que elas não serão compartilhadas pela maioria. Vêm à mente as pessoas com deficiência: alguns detalhes de design podem tornar o aplicativo inteiro completamente inutilizável para elas, mesmo que não tenham os números para impor seus pontos de vista em uma votação. Por outro lado, não é possível acomodar as necessidades peculiares de cada um sem criar monstros. Isso precisa ser cuidadosamente avaliado e arbitrado.

A responsabilidade da maioria é, portanto, identificar quem são as minorias estruturais, ou seja, quais propriedades unem essas minorias (condição de saúde, origem social, educação, nível de renda, etc.). Se uma minoria levanta um problema que é bloqueante para ela por causa de uma das propriedades definidoras da referida minoria, deveria haver uma forma de contornar ou reponderar o voto da maioria. Isso ainda precisa ser definido, mas a maneira mais fácil de abranger isso é durante as deliberações, que dependem da empatia e da compreensão da maioria.

Outro problema de qualquer grupo social é o pensamento de grupo , porque qualquer grupo social tende a degenerar em um clube com o tempo. O pensamento de grupo é quando os indivíduos não se sentem livres para levantar questões que vão contra o (suposto) consenso do grupo, por medo de repercussões quanto ao seu lugar e à sua percepção dentro do grupo. Essas repercussões podem ser muito sutis, porém muito reais. Torna-se prejudicial quando os indivíduos começam a apoiar decisões, dentro do grupo, que não teriam apoiado por conta própria: esse é o ponto de virada em que a racionalidade individual se perde. Para evitar isso, o voto anônimo pode ser usado, mas ele não se aplica às deliberações, onde há necessariamente um orador. Há uma cultura de dissensão saudável a construir, manter e incentivar. Uma forma de resolver esse problema é nomear aleatoriamente um “advogado do diabo” para cada sessão, cuja função será discordar constantemente e expor os argumentos correspondentes.

Espera-se que qualquer comunidade baseada em um interesse comum por fotografia e software livre seja tendenciosa em favor de homens ricos, instruídos, alfabetizados em informática e falantes de inglês. Terá de ser um esforço consciente tentar incluir mulheres, pessoas menos instruídas, cidadãos não ocidentais, etc. Combinado com a democracia por voto e o pensamento de grupo, pode ser realmente prejudicial começar com um grupo socialmente tão homogêneo, se não for gerido com cuidado. Esse será um desafio diário do qual todos precisam estar cientes. Ele também alimentará o viés de sobrevivência , no qual os excluídos não estão presentes para dar feedback sobre por que não aderiram, participaram ou se sentiram acolhidos, e os excluídos precisarão de cuidado extra para serem alcançados e acolhidos.³ Nenhuma dose de racismo ou sexismo pode ser tolerada em um ambiente desses, nem mesmo como piada, porque isso faria a maioria rir às custas das minorias em um contexto do qual elas já são filtradas para fora.

A democracia também é um processo lento. Podem acontecer coisas que precisam de uma decisão imediata, como uma brecha de segurança no servidor do projeto ou nas contas de mídia social, ou qualquer questão jurídica urgente. Alguém deveria ser eleito para mandatos de curto prazo para poder tomar rapidamente essas decisões em nome da comunidade.

Os limites entre especialistas e leigos

Assim como os médicos ou advogados, os desenvolvedores têm competências e experiência de nicho, que lhes darão uma espécie de poder e até carisma sobre os leigos. Esse poder pode ser abusado para oprimir a maioria, usando sua falta de conhecimento em benefício do opressor. Essa relação será sempre assimétrica, e isso precisa ser reconhecido. Além disso, os desenvolvedores terão de ser consultados durante as deliberações na assembleia geral, para avaliar a viabilidade das tarefas e os recursos necessários, antes que as votações aconteçam.

Assim como médicos, advogados, etc., os desenvolvedores deveriam seguir uma espécie de código de ética que acompanha seu poder simbólico, entre os quais:

1. o dever de informar honestamente, no melhor de seu conhecimento, e de explicar de forma simples o que pode ser explicado de forma simples,
2. um dever de devido processo e devida diligência ao pesquisar e desenvolver soluções,
3. um compromisso de trabalhar no melhor interesse da comunidade.

Por outro lado, os desenvolvedores (ou quaisquer outros especialistas) podem ser percebidos como magos oniscientes e onipotentes pelos leigos, que podem então exigir demais deles. Embora o software seja um meio bastante maleável, ainda há restrições técnicas inegociáveis que se aplicam, e nem tudo o que é tecnicamente possível pode ser possível dentro das circunstâncias atuais com os recursos atuais.

Ambas essas posições precisarão ser compreendidas para evitar o crescimento do ressentimento mútuo.

Os limites da colaboração

Todo mundo é designer.

Todo trabalho sobre o qual você nada sabe parece fácil de fazer. Projetar e construir objetos técnicos é um deles. É até empolgante contribuir para isso. Mas um software que será usado como ferramenta por milhares de usuários além de você mesmo não é a mesma coisa que a sua própria mesa de cabeceira.

Os usuários deveriam ser bem-vindos a participar da definição do problema: partir de um ou vários usuários que têm um problema específico em um fluxo de trabalho específico, ver se ele já não pode ser resolvido com as ferramentas atuais e talvez um pouco de educação, e, se não, tentar pesquisar quantos usuários compartilham o mesmo problema. Se o problema não for exatamente o mesmo para todos, tentar encontrar uma expressão comum do problema que permita generalizá-lo.

Uma vez definido o problema, começa o processo de design, que segue etapas formais para evitar correr para a primeira solução (e muito provavelmente não ótima) porque, novamente, a intuição humana é melhor para construir mesas de cabeceira do que ferramentas usadas por milhares. Mas seguir o processo não é suficiente.

A psicologia e as ciências cognitivas convergem para um consenso: o melhor tamanho para equipes de trabalho é entre 4 e 7 membros. A partir de 8 membros, a produtividade começa a cair drasticamente.⁴⁵⁶ Para uma equipe de 4 membros, há 6 canais de comunicação interpessoal, enquanto para 8 membros, há 28 canais de comunicação. Isso torna difícil acompanhar cognitivamente todos os envolvidos, quem é responsável pelo quê, processar sinais não verbais, o que cria uma sobrecarga de comunicação. Acima de 9 membros, começam a se formar clãs, a política se mistura ao processo, e a preguiça social  entra em cena.⁴⁵

Isso significa que o trabalho deveria ser dividido em equipes de trabalho com no máximo 6 a 7 membros cada uma, mesmo que possa ser empolgante para a comunidade em geral se interessar por tudo. A comunicação é o ponto de virada aqui: você precisa da quantidade exata dela, nem mais, nem menos, caso contrário ela satura cognitivamente os membros da equipe e prejudica a própria comunicação. Aí, é o trabalho em si que sofre um golpe.