Não seja esse usuário de código aberto, não seja eu

By | Junho 19, 2022

Antes de ser um mantenedor de software de código aberto, eu era um usuário de software de código aberto e às vezes me comportava mal.

Ao usar um aplicativo ou biblioteca, eu descobriria um erro ou algo interromperia meu fluxo de trabalho com a nova versão e eu iria ao GitHub para denunciá-lo. Às vezes, quando eu chegava lá, eu achava que já estava reportado, então eu comentava o problema para acrescentar mais alguma coisa que eu achasse útil e para dar peso ao relato. Ocasionalmente, também retornei a problemas que não haviam sido resolvidos para ver se poderia adicionar mais informações úteis ou perguntar se havia um ETA para corrigir. Senti que fui útil.

O que não levei em conta é que minhas interações tiram tempo/atenção/recursos/paciência do projeto. O suporte ao cliente é um custo.

Se você tirar alguma coisa deste post, espero que esses custos precisem ser pagos por alguém, o mantenedor.

Pequenos custos se somam

Os projetos de código aberto vêm em várias formas e tamanhos, desde projetos de desenvolvimento autônomos até grandes ecossistemas apoiados por empresas da Fortune 500. Você ficaria surpreso com a frequência com que algo que você considera fundamental ou crítico em seu fluxo de trabalho é mantido por apenas uma pessoa.

xkcd # 2347

À medida que os projetos crescem, aumentam também os custos de suporte aos usuários.

Um exemplo particular de observação foi um grafan / edição de graffiti que abriu pouco depois recurso de alerta foi adicionado. Alertas suportavam apenas gráficos e eu queria receber alertas se alguma das minhas estatísticas individuais também exceder seu limite. Então eu parei e adicionei um +1 à pergunta.

Com o tempo, mais e mais pessoas pararam +1 problema, mas não implementado. Com o passar do tempo a formulação +1Quando ficou mais forte, as pessoas exigiram que fosse implementada e esperavam que fosse implantada em marcos futuros.

Acho doloroso ler este tópico porque se você rolar um pouco para baixo, encontrará meus comentários se comporta como um usuário com super poderes. Sinto muito pela maneira como lidei com este tópico, e a tentação de excluir comentários é forte, mas quero compartilhar isso aqui na esperança de que você aprenda com meus erros e que não se comporte assim em código aberto comunidades.

Grafana é uma ferramenta de painel de código aberto gratuita que é muito popular nas comunidades devops. O que eu não entendia na época era que o Grafanu, como a maioria dos projetos, apenas mantém um um punhado de programadores. Eu não conseguia ver além do branding e do hype do grupo de pessoas que o criava, e não conseguia entender por que esse projeto não implementou um dos recursos mais procurados da comunidade.

A maior coisa que eu não entendi é que cada usuário comenta

esse recurso é necessário para eu continuar usando o Grafan

ou perguntando

por que ainda não foi implementado?

uma barreira estava sendo construída para impedir que alguém trabalhasse nela.

Como os projetos de código aberto são financiados

Enquanto alguns projetos de código aberto são criados por grandes empresas de forma estruturada e planejada, acho justo dizer que a maioria está crescendo organicamente. Muitas vezes, começará como um pequeno projeto paralelo de uma pessoa com necessidades específicas. Essa pessoa ficará animada para criar a coisa e expô-la para ajudar outras pessoas que também têm os mesmos desafios.

Esses projetos têm um custo baixo, tanto em termos de tempo de desenvolvimento quanto de suporte, manutenção e outras atividades da comunidade. Esse custo é coberto pelo indivíduo, eles doam seu tempo para construí-lo e ficam felizes em ajudar os usuários quando eles começam a descobrir o projeto.

Com o tempo, os projetos crescem, reúnem mais usuários e adicionam mais linhas de código. No final, o projeto superará os requisitos originais dos criadores. As pessoas continuarão apresentando novas solicitações de recursos, e o mantenedor as adicionará porque estão empolgadas com o fato de a comunidade querer usar suas ferramentas.

Finalmente, o mantenedor considera as coisas menos como diversão e mais como trabalho. Esta é uma fase normal de muitos projetos OSS e é importante reconhecer que quando você se sente como um trabalho, você deve tratá-lo como um trabalho. O financiamento é necessário aqui, tanto em termos de tempo de desenvolvimento quanto de apoio da comunidade.

Alguns projetos atraem mais desenvolvedores e colaboradores que também se voluntariam para assumir esse fardo. Pode atrasar essa sensação de trabalho para uma data posterior e expandir o fardo, mas acho que é inevitável que eventualmente alguém tenha que pagar para que esse software continue existindo.

Existem diferentes abordagens que os projetos usam para encontrar uma fonte de renda sustentável. Às vezes, os projetos usam software de código aberto para administrar um negócio com fins lucrativos que adiciona uma camada extra de valor e cobra por isso, como um serviço gerenciado. Pela segunda vez, os projetos tentarão atrair doações para pagar a manutenção. Ocasionalmente, grandes empresas que se tornaram viciadas nessas ferramentas contratam reparadores diretamente (estou feliz por estar neste grupo hoje). Em todos esses casos, a maior parte da comunidade de software de código aberto não contribuirá financeiramente e continuará esperando que o serviço gratuito continue.

Se você estiver interessado em como os projetos de código aberto crescem e se tornam sustentáveis, você deve conferir Trabalho público.

Voltando ao Grafan, por exemplo, eu era um daqueles usuários de código aberto que tinham expectativas do serviço apesar de nunca pagar nada. Esta é uma maneira terrível de pensar.

Se você desenvolver um aplicativo iOS de código fechado e cobrar por ele na Apple App Store, sua base de usuários terá certas expectativas. Eles esperam que o aplicativo continue em execução por um período de tempo razoável. Se o aplicativo depende de um serviço da Web para funcionar, eles esperam que ele continue funcionando. Se eles tiverem problemas com o aplicativo, eles poderão pedir ajuda.

Há uma troca de valores aqui, dinheiro em troca de um aplicativo, e isso é razoavelmente bem entendido. No entanto, ainda existem problemas práticos para as empresas entenderem, como quanto tempo um desenvolvedor pode dedicar a cada usuário e quanto tempo um aplicativo deve ser executado após a compra. eu gostei recentemente episódio Sob o Radar sobre gerenciamento de suporte ao cliente quando você é um programador solitário que fala em detalhes sobre esse tópico.

Mas o que acontecerá se jogarmos dinheiro fora da equação. O software de código aberto é gratuito. No entanto, muitos usuários ainda esperam que o mantenedor forneça um certo nível de suporte.

Se um usuário comprar um aplicativo para iOS e a próxima atualização alterar ou remover alguns dos recursos importantes para ele, é um direito razoável reclamar. Se um usuário fizer download de uma ferramenta gratuita de código aberto e a atualização alterar a funcionalidade, ele deve ser elegível para apelar?

É minha opinião que eles podem relatar essa alteração indesejada ao desenvolvedor de qualquer maneira, mas sem esperar que eles fiquem satisfeitos. Aqui a relação é completamente diferente. O usuário se comunica com a pessoa que lhe deu algo de graça, não com a empresa que cobrou algo.

O financiamento borra a água

Esperamos concordar que, quando algo é pago, você tem direito a uma certa quantia de suporte e, quando não o recebe, gratuitamente. Então, o que acontece quando a pessoa que cria um projeto de código aberto encontra uma maneira de financiar esse projeto? O que acontece se esse projeto se tornar algo mais parecido com uma empresa?

Aqui eu quero afirmar que nada mudou. Mesmo que um mantenedor seja pago para manter o software, ele não é pago para fazer exatamente o que você diz a ele.

Os usuários que ainda estão recebendo software livre também não devem esperar suporte gratuito e, se um projeto mudar de direção ou fizer algo que não goste, eles devem interagir com o projeto sem direitos.

Voltemos ao nosso exemplo Grafana. A Grafana Labs é uma empresa com fins lucrativos que ganha dinheiro com a Grafana. Tem um bom logotipo, site e tudo mais que você esperaria de uma empresa. Não tentando justificar meu comportamento no passado, acho que parte do motivo pelo qual fiquei tão surpreso e barulhento que o problema não foi resolvido foi que eu esperava que uma empresa com fins lucrativos consertasse as coisas que a comunidade estava procurando.

No entanto, agora vejo que meu uso da ferramenta não trouxe nenhum valor para as empresas e não fui usuário de nenhum de seus serviços, então por que eles deveriam me fornecer suporte gratuito então.

Com base na minha própria experiência, acho que o pessoal do Grafana Labs tem parte de seu tempo dedicado ao desenvolvimento de um projeto de código aberto. Eles provavelmente estão trabalhando em coisas com as quais seus clientes pagantes se preocupam e coisas nas quais eles pessoalmente querem trabalhar.

Evitando tarefas complicadas

A maneira como eu e inúmeros outros membros da comunidade Grafan nos comportamos sobre essa questão tornou a leitura desconfortável. Portanto, não é à toa que nenhum dos mantenedores decidiu trabalhar nessa tarefa por cinco anos. No verão passado, o problema foi finalmente resolvido com a implementação do suporte para alertas estatísticos individuais. Talvez o usuário finalmente tenha pedido que fosse implementado, ou o técnico de serviço finalmente decidiu que era suficiente e superou o inconveniente para que ele pudesse fechar o problema.

De qualquer forma, sou eternamente grato aos mantenedores do Grafana por construir um projeto fantástico de código aberto que eu poderia usar gratuitamente, e peço desculpas por adicionar a fogueira que foi um problema #6983.

Seguindo em frente

Gostaria de encerrar meus pensamentos sobre como, como mantenedor, gostaria que os usuários se comportassem quando algo inevitavelmente quebrasse.

Em primeiro lugar, seja gentil. Se você fizer uma atualização e algo estragar seu fluxo de trabalho, é normal se sentir frustrado, mas a pessoa que fez essa alteração não pretendia incomodá-lo. Mude para o repositório e, se já não houver problemas, abra-o. Seja grato ao mantenedor por todo o valor que você já tinha e faça uma relatório de erro mínimo para que eles saibam o que está errado.

Se houver um problema existente, adicione um emoji com o polegar para cima no comentário original e adicione um comentário adicional somente se você tiver novas informações relacionadas ao problema. Se o que você quer dizer já foi dito, então não diga. Ao interagir com os mantenedores, lembre-se de pedir a ajuda deles, não de dizer a eles o que fazer.

Se o problema for um bug claro e o único próximo passo possível for corrigi-lo, considere levantar uma solicitação de retirada se você tiver a capacidade de fazê-lo. Mas se houver opiniões diferentes sobre como proceder, não basta configurar cegamente o PR com sua solução preferida.

Se o projeto aceitar doações e você tiver fundos para contribuir, envie alguns fundos para os desenvolvedores e informe-os de que se preocupa com o problema na nota. Apenas lembre-se de doar para o projeto como um todo, e não comprar seu tempo para consertar essa coisa em particular.

Se o projeto for apoiado por uma grande organização, você pode ter um relacionamento comercial existente e um gerente de contas. Em caso afirmativo, entre em contato dessa maneira, pois isso pode ajudar a desviar fundos dessa empresa para consertar as coisas.

Finalmente, você sempre tem a opção de bifurcar um projeto. Isso é muitas vezes dito apesar de não ser um empreendimento pequeno, mas para muitos pode ser um caminho sustentável a seguir. Ao assumir a propriedade e a responsabilidade pelo fork, você tem controle total sobre seu desenvolvimento e pode fazer exatamente o que precisa.

Mas de todas as coisas
Sejam ótimos um com o outro, divirtam-se com os caras
.

Adoro ouvir comentários sobre minhas postagens. Você deve ir para Twitter e me diga o que achou!

Deixe uma resposta

O seu endereço de email não será publicado.