Autor e mantenedor de vários projetos de código aberto , Andrew Gallant está tentando aliviar a tensão que se acumulou recentemente na comunidade de código aberto. Os gritos da alma “Como é ser um mantenedor de software livre” , “Código ingrato de código aberto” e outras queixas dos mantenedores deram origem a uma discussão sobre agressividade, grosseria, ingratidão, desgaste emocional e a gravidade do apoio altruísta a projetos. A publicação foi publicada em 19 de janeiro de 2020, - aprox. trans.

Quero me afastar da tradição de falar quase estritamente sobre tópicos técnicos - e compartilharei algumas de minhas relações pessoais com software livre e de código aberto (FOSS). Embora todas as pessoas sejam diferentes, espero que a troca de pontos de vista ajude a construir compreensão, empatia e confiança mútuas em nossa comunidade.

Por favor, não considere este post como uma reação direta às ações de qualquer outro mantenedor. Esta não é uma receita para o comportamento ideal, mas uma reflexão pessoal na esperança de que eles se tornem uma ocasião para que outros reflitam sobre seus próprios relacionamentos com o código aberto. Não existe um caminho certo para se tornar um bom mantenedor. Cada um tem suas próprias maneiras de lidar com isso.

Isto não é de forma alguma um pedido de ajuda. É sobre entender. Não estou pedindo uma mudança na economia do software livre nem discutindo minha saúde mental. Não estou falando em atrair mantenedores adicionais. Eu só quero compartilhar minha história e tentar aumentar a empatia na comunidade FOSS.

Público-alvo : todos os envolvidos no código aberto.

Conteúdo

• A história
  
• Emoções condenadas
  
• Negativo Purulento
  
• Trabalhe através do poder
  
• Rudeza
  
• Autoridade
  
• Mais sobre competência
  
• Confiança
  
• Melhor do que parece
  
• Conclusão

A história

Meu primeiro projeto de código aberto foi lançado há quase 16 anos - um quadro de avisos em PHP. Naquele momento, quase todo mundo criou essas coisas, e foi assim que aprendi a programar. O projeto começou inicialmente como um sistema escolar para discussões (na época, as escolas não trabalhavam com a Internet, exceto para hospedar sites ruins). Então eu encontrei a dificuldade de estimativa. O projeto se prolongou por muito mais de um semestre e gradualmente se transformou em um hobby que foi além do escopo do projeto da escola.

Pessoalmente, eu sempre gostei de programar apenas por diversão. Gosto de todas as etapas: primeiro investigando um tópico, determinando a viabilidade, desenvolvendo um plano inicial, codificando obsessivamente e até pensando nisso, gosto de cada minuto de tudo.

Para gostar da programação, não preciso compartilhar os resultados do meu trabalho. No entanto, o código aberto rapidamente se tornou uma parte natural do meu processo de desenvolvimento, que persistiu de uma forma ou de outra por 16 anos. De fato, o que eu mais gosto é se o código permitir que alguém resolva seu problema com mais eficiência. Quanto mais bom meu código traz, mais agradável. Como regra, não me importo com quem, por outro lado, é apenas outro hacker que satisfaz sua curiosidade, ou uma empresa gigante fazendo algo interessante em uma escala incrível.

Minha história do FOSS continuou com várias versões do meu quadro de avisos e do wtcSQLite , um simples clone do phpMyAdmin , mas para o SQLite.

Quando mudei do Windows para o Linux por volta de 2009, lancei ainda mais projetos, mas no Python e no X11. Entre eles estão o PyTyle, para a fixação de quadros no gerenciador de várias janelas e no openbox-multihead , minha implementação do suporte a vários monitores no Openbox . Esses projetos, juntamente com algumas pesquisas da Go, me levaram a criar o gerenciador de janelas no Go que eu ainda uso.

Com o passar do tempo, e cerca de seis anos atrás, comecei a escrever em Rust. O Quickcheck se tornou a primeira biblioteca, mas foi seguido por várias outras: regex , docopt.rs , rust-csv , fst , termcolor , walkdir e muitas outras nos seis anos seguintes.

Embora a grande maioria dos meus projetos Rust sejam bibliotecas, existem ferramentas de linha de comando como xsv e ripgrep .

Muitos dos meus projetos antigos agora estão realmente mortos ou apoiados por outros, mas continuo apoiando a maioria dos projetos Rust. Ou foram substituídos pelos racks de melhor qualidade de outra pessoa (por exemplo, como o canal de viga cruzada substituiu o chan ).

Hoje, ainda gosto muito de programar, mas também passo muito tempo revisando códigos, depurando problemas com usuários finais, respondendo a solicitações de recursos e outras coisas. Invariavelmente, isso significa interação, trabalho e comunicação com outras pessoas.

Emoções condenadas

Na minha juventude, eu tinha orgulho de minha "lógica" e "tomada de decisão imparcial". Como em todo bom auto-engano, há um grão de verdade aqui. Mas, em essência, eu pessoalmente sou um ser profundamente emocional.

As emoções fluem profundamente e podem ser uma fonte realmente útil para a motivação interna. Por exemplo, por algum tempo após o lançamento do ripgrep, eu realmente odiei tocar no código responsável pela exibição dos resultados da pesquisa . Ele estava confuso, com erros e difícil de mudar. Reescrever completamente o código é uma decisão completamente lógica que pode ser tomada por motivos puramente técnicos, mas fiquei motivado a fazer isso com um sentimento de nojo. Eu simplesmente não gostei dos meus sentimentos . As emoções me ajudaram a consertar a situação, me ajudar. Por exemplo, agora a saída é isolada em uma biblioteca separada com testes completos, e me sinto muito melhor sempre que preciso entrar nesse código e fazer alguma coisa. Este ainda não é o meu melhor trabalho, mas já é uma grande melhoria - pelo menos do ponto de vista emocional - em comparação com o estado anterior.

As emoções são divertidas, porque podem levá-lo a estados verdadeiramente surpreendentes. Digamos, no exemplo anterior, há algumas razões técnicas suficientes para reescrever o código de saída? Aqui você precisa tomar uma decisão. Mas se não houver motivação, talvez nunca ouse refatorar. E sem refatoração, provavelmente a base de código estagnará e o programa começará a falhar, ou alguma combinação de ambos. Se as emoções motivarem, a refatoração abrirá um futuro muito melhor, onde você poderá implementar mais funções no software sem comprometer a confiabilidade.

As emoções têm uma desvantagem. Qualquer pessoa que lançou e suportou algum software bastante popular certamente contatou outras pessoas. Acontece que outra pessoa pode ter um efeito impressionante no seu estado emocional. Um gesto ou comentário positivo pode alegrar o seu dia. O mesmo sentimento: sim, o upload do meu código foi tão importante que ajudou essa pessoa . Mas, como qualquer mantenedor confirma, os comentários positivos são quase sempre ofuscados pelos negativos.

Comentários negativos não são tão ruins. Essa é uma consequência natural do compartilhamento de código quando você convida outros usuários a usá-lo e relatar problemas . Quando uma mensagem de erro aparece, você sente que falhou com esse usuário. Quando você escreveu o código, tinha certeza de que o testou bem o suficiente, mas ele ainda está incorreto . Os relatórios de erros nunca param? Quanto tempo esse usuário perdeu devido a um bug? Quanto tempo levarei para consertar tudo? Nem isso: quanto tempo levarei para simplesmente mudar para um modo em que haja pelo menos uma esperança de corrigi-lo?

Esses pensamentos podem levar a emoções que começam a corroer você. E este é o cenário mais provável quando se trata de comentários negativos.

Negativo Purulento

Eu aprendi rapidamente a superar emoções negativas a partir de relatórios de erros. De fato, boas mensagens de erro de fácil leitura logo se tornam agradáveis porque geralmente são muito raras. A maioria dos erros não é reproduzida, mesmo se você fornecer um modelo para o problema com solicitações explícitas para todos os parâmetros (modelo de problema). O remetente provavelmente quer o melhor, mas as informações simplesmente não são suficientes para reproduzir o erro. E barulho começa e para trás em uma tentativa de isolar o bug.

Para mim, pessoalmente, esta é a área mais dolorosa. As emoções ganham vantagem porque só consigo pensar em uma coisa: por que essa pessoa não teve tempo para ler e preencher o modelo do problema ? Ou se ocorrer um erro devido a um erro de um usuário que não leu a documentação, só posso pensar: dediquei algum tempo a fornecer algum software para esse usuário e ele nem consegue ler o README antes de enviar um relatório de erro?

Isso é loucura. Obviamente, as emoções nem sempre são racionais. A documentação provavelmente poderia ser mais clara. Ou o usuário pode não ter notado esse item. Talvez ele não tenha experiência na execução de projetos de software livre ou no envio de relatórios de erros e, talvez, não saiba como ajudar na reprodução simples de um bug. Todas essas são suposições bastante razoáveis, e é por isso que faço o meu melhor para que as emoções não prevaleçam. Embora a empatia com a pessoa do outro lado do fio também seja importante.

Suponha que eu não diga "Convido você a usar meu código" em qualquer lugar, mas faço muitas coisas apenas porque minha intenção é que outras pessoas usem meu código. Estou escrevendo documentação mais detalhada, exemplos de uso. Configurei testes de integração contínua. Feito README para iniciantes. O link para o projeto é indicado em muitas das minhas páginas. Se as pessoas aceitarem esse convite para usar meu código ou considerarem um rastreador de erros aberto um convite para relatar erros, não devo puni-los quando realmente enviarem essas mensagens. O autor de um relatório de erro incorreto provavelmente pensa que fez todo o possível. E enquanto eles agem com boas ações, eu realmente tento responder o mesmo.

Isso sublinha a assimetria entre usuários e mantenedor. Os autores de muitos relatórios de erros podem trocar uma ou duas mensagens comigo. Para eles, um relatório de erro mal escrito realmente não importa. Mas estou do lado errado, porque tenho essa cena repetidamente em todos os meus projetos. O tempo todo. Quase todo dia. Manter a empatia em tal situação é extremamente difícil, especialmente se você tiver um dia ruim. O que às vezes acontece.

Às vezes, minha impaciência se manifesta em respostas muito curtas. Eu tento o meu melhor para melhorar a esse respeito. O processo de auto-aperfeiçoamento ainda não está concluído.

Trabalhe através do poder

Se você é o mantenedor de um projeto popular ou de vários repositórios regulares, obtém um fluxo quase contínuo de relatórios de erros e solicitações de pool. Eles vêm diariamente. Acompanhá-lo é quase impossível. O tamanho do cache do meu cérebro é incomumente pequeno, então não sou muito bom em alternar o contexto entre os projetos. Como resultado desse fenômeno, rapidamente coleciono relatórios de bugs e solicitações de pool para os projetos com os quais trabalhei recentemente. Esses projetos são provavelmente mais acessíveis ou melhor abordados nas últimas páginas do cache do cérebro.

Mas em outros projetos, a lista de problemas começa a se acumular. Todos os dias, você vê uma nova edição e diz a si mesmo: "Sim, realmente analisarei isso assim que voltar do trabalho". Mas algo novo está por vir. Como resultado, a motivação para mudar de contexto surge apenas quando o usuário faz um ping mensalmente por quatro meses - provavelmente sua solicitação de pool é realmente importante.

Desculpe, houve um pouco de sarcasmo na última frase, mas ao mesmo tempo é verdade. A assimetria de usuários e mantenedores está de volta em ação, mas estou realmente tentando limpar o pool de filas de solicitações e desenvolver o projeto. Quero contribuir com esse usuário, não apenas para continuar usando meu código, mas também para fazê-lo feliz . Em muitos casos, apenas uma hora é suficiente para resolver as solicitações de pool e todos os problemas que requerem ação.

Mas passei quatro meses apenas observando com tristeza como os problemas persistem naqueles que entram sem solução.

Para esse fenômeno, apliquei um método que utilizo de maneira muito eficaz em minha vida pessoal: estabelecer limites. Educadamente, mas estabelecer limites com firmeza é um daqueles truques mágicos que ganham dividendos assim que você o aprende. Se você não sabe como fazer isso, dificilmente posso explicar. No entanto, estabelecer limites permite que você se concentre no que é importante para você , não para os outros .

Obviamente, é preciso buscar o equilíbrio. O estabelecimento de limites não significa que você pode se concentrar apenas nos seus próprios assuntos. Mas a capacidade de erguer esse muro e dizer: "Não, eu não faço X, mas terei prazer em fazer Y" - realmente fez maravilhas para mim. Meu segredo é apresentar argumentos com os quais os outros não podem discutir com base em minha própria experiência e desejos.

O que isso tem a ver com código aberto? Para mim, pessoalmente, a chave era estabelecer um limite entre mim - e todos esses problemas órfãos com solicitações de pool. Você precisa de alguma forma se impressionar: “Eu voluntariamente passo meu tempo, e é normal que eu não responda a tempo. Tenho certeza que a maioria das pessoas entenderá isso e será razoável. "

Isso também aparece ao discutir solicitações de novos recursos. Às vezes, a solicitação pode fazer algum sentido para o seu projeto, mas essa função implica um grande fardo de suporte. Aprendi a estabelecer limites: você pode dizer "Não" a uma função apenas com o argumento de que não deseja gastar mais tempo com suporte. Como aconteceu mais de uma vez, você pode mudar de idéia! Por exemplo, se o código foi aprimorado, torne-se mais acessível para manutenção - você pode perceber em si mesmo mais desejo de introduzir novas funcionalidades. Mas, se não, faço o possível para tatear meus limites e me recuso a me sobrecarregar com um trabalho extra que não agrada.

Gostaria de escrever instruções passo a passo sobre como definir limites firmes e parar de se sentir mal devido a uma pilha de problemas. Isso não elimina completamente o negativo, mas ajuda muito.

Rudeza

Trolls óbvios geralmente são fáceis de lidar. Este é um grupo de pessoas com intenções óbvias de irritar você. Os trolls geralmente não enviam nenhum código, portanto, seus comentários não precisam receber muita atenção. Pelo menos, é o que digo a mim mesmo no âmbito do mecanismo de defesa. Se eu vejo um troll, geralmente o relato em suporte ao GitHub com o bloqueio subsequente. Em geral, raramente encontro esses personagens, então aqui pareço ter sorte.

Mas a grosseria assume muitas formas. Minha emocionalidade estabelece uma estrutura bastante decente de decência, então você não pode considerar toda essa grosseria. Mas, do meu ponto de vista, isso é pelo menos grosseiro.

• "Sua ferramenta não funciona [no meu caso de nicho], portanto está quebrada."
  
• "Vou apenas intervir para dizer que também gostaria desse recurso" (Nota. Parece que alguns leitores não conseguem tolerar o que eu chamo de "grosseria". Talvez essa seja uma palavra muito forte, mas quando na discussão eles acumulam tais " "Add-ons", apenas adiciona ruído ao e-mail e pode ser irritante. Em vez disso, emoticons são bem-vindos ou você pode adicionar alguns detalhes ao seu caso de uso específico. No entanto, parece bem pequeno no contexto, e eu realmente vejo isso aqui estatisticamente meu problema).
  
• Para insistir que para implementar a função, você precisa " apenas criar X".
  
• Agressão passiva quando você transmite uma solicitação de função.
  
• Irritante construtivo sobre software em [insira aqui qualquer mídia social].
  
• Variações sobre o tema “Por que você está reinventando a roda?” Ou “Por que não contribuir com um projeto existente?”

Em muitos casos, a grosseria é o resultado de uma decepção genuína por parte do usuário. Quantas vezes você murmurou baixinho quando algum instrumento não se comportou como você deseja? Não importa que essa ferramenta seja provavelmente apresentada a você gratuitamente. Você está apenas tentando resolver um problema, e a ferramenta está entrando no seu caminho. Eu definitivamente senti isso. Na minha opinião, um sentimento humano completamente normal.

Às vezes prevalece a grosseria, expressa de várias maneiras improdutivas. Eu sei que eu mesmo fiz isso e, é claro, também aconteceu do outro lado. Isso é incrivelmente perturbador para todos os envolvidos.

Em outros casos, algumas pessoas não entendem sua grosseria. Talvez por causa da barreira do idioma ou simplesmente porque eles não sabiam como suas palavras afetariam os outros. Muito inocente, mas não muda os sentimentos da minha parte.

Lidar com esse tipo de grosseria pode ser muito difícil. Talvez esses problemas não incomodem ninguém, mas eu não sou um deles. Eu poderia fingir que isso não me incomoda, mas tenho certeza de que isso levará a um insulto ao código aberto e a uma decepção ainda maior.

Aqui, novamente, estabelecer limites me ajudou. Se descartamos os trolls, a grande maioria dos snappers geralmente responde muito bem, se você os educar. Eu costumava fazer isso nos meus rastreadores de bugs, e isso geralmente melhorava a situação. Não sinto insulto porque me protejo e , ao mesmo tempo, me sinto melhor quando a outra pessoa pede desculpas, o que acontece na grande maioria dos casos.

Para fazer isso, basta dizer: "Não gosto de como você disse X. Acho que será muito mais produtivo se recusarmos esses recursos no futuro".

Mas, em alguns casos, as pessoas não respondem muito bem a essas palavras. Na minha experiência, eles geralmente os ignoram. Se eles continuarem sendo rudes, posso repetir isso algumas vezes, porque alguns precisam ouvir algo mais de uma vez para alcançá-los. Pelo menos eu sei disso sozinho (para desgosto da minha esposa). Se isso ainda não funcionar, e o tom deles ainda me incomoda, então paro de interagir. Simplesmente feche ou bloqueie o problema ou a solicitação de pool ou vá além até que o usuário seja bloqueado em [inserir mídia social aqui].

Autoridade

Era uma vez, conversei com alguns amigos íntimos que estavam viajando para o exterior. Ao voltar para os Estados Unidos, eles compartilharam um pequeno exemplo de choque cultural. A principal coisa?

Eu nunca pensei sobre o quanto os americanos gostam de forçar .

Se isso é uma característica de toda a cultura americana ou apenas do meio ambiente - não discutiremos. O ponto é que algumas pessoas gostam de falar sobre o que outras pessoas devem fazer. Eu cresci com esses feeds de pessoas dos mais diferentes níveis da hierarquia de poder - e realmente sinto um desgosto inato por isso.

Estou absolutamente convencido de que a maioria das pessoas nem percebe esse comportamento. Alguns não querem entrar na sua vida, mas simplesmente tentam dar conselhos. Pelo menos é assim que eles respondem quando eu aponto casos particularmente graves de coerção.

Recuar um pouco, usar a palavra "deveria" não é necessariamente ruim por si só. Mas o que realmente muda seu significado, na minha opinião, é a presença de um convite . Se você pediu conselhos a alguém sobre um tópico, e ele disse algo como "Sim, você precisa fazer o X", isso não parece tão ruim. , .

:

• .
  
• [ ].
  
• .
  
• [ ].
  
• .

, - . . , , - , . , - , - , .

, , . :

• , « ?», , . FAQ .
  
• . , - , .

, . , Rust, UNLICENSE . - «» , () , . . . - , .

, . - , . . , .

, . , , , - .

, - ( ), . . . -, . - , — , , — . , -: - , .

. . , , .

. open source. , , , .

FOSS — . , . FOSS , , . , .

, . - , , , .

. , . :

• , , ?
  
• ?
  
• ?
  
• ?

, . , . , . . — , . , , .

, JSON, , . , / . .

, , . . , . , , . , .

, , . , , FOSS.

,

. : « ?» , . . , , . , ( ) .

, :

• , . , . , : «, , . ».
  
• -, .
  
• -, , , . — , .
  
• changelog, , . , , .
  
• , , . , .
  
• . , , .
  
• . , , .

, — — . . , , , . .

Conclusão

FOSS, . , . , . , . , , . , . - , FOSS.

, , , , . , .

No artigo, listei muitos tipos de comportamento que considero negativos. Nem todos os perceberão tão negativamente quanto eu. Isso é normal e esperado . Além disso, eu próprio fiz algumas dessas coisas negativas. As pessoas não são perfeitas e nunca podemos responder totalmente 100% do tempo. Essas são perguntas sutis, e espero que possamos melhorar a situação, pelo menos um pouco.