7
MrJ
5 min de leitura ·

🌎Meu pull request não pedido para alguns parasitas🪱 da comunidade. Em resposta ao post: "Usuário de open source precisa parar de tratar mantenedor como funcionário" - Guia de postura - Como "cobrar" melhoria

Recentemente, o @gabrielbaiano levantou um ponto necessário aqui no TabNews sobre a postura bizarra de usuários que tratam desenvolvedores de projetos open source como funcionários não remunerados.

Estou sumido, apareço e me irrito.

Eu escrevi uma resposta lá, mas lendo as interações da thread, percebi que o buraco é muito mais embaixo. Existe uma falha estrutural na compreensão do que significa "código aberto" na cabeça de muita gente que consome tecnologia hoje. A distorção chegou a um ponto onde o usuário de software gratuito bate no peito para exigir prazos e suporte de quem doa o próprio tempo livre.

Decidi expandir meu comentário e transformá-lo nesta publicação para colocar os pingos nos "is". Não é só um desabafo, é um alinhamento sobre como as coisas funcionam de verdade.

Eu realmente estou incrédulo, li alguns comentários aqui que me fazem desacretidar que sabem minimamente a história da computação. É um vergonha, e nem fazem parte da nossa "profission"

O open source é hoje um movimento tecnológico e uma forma de trabalho que vai além da produção de software. O movimento open source usa os valores e o modelo descentralizado de produção do software open source para descobrir maneiras inovadoras de resolver problemas em suas comunidades e setores. O código-fonte do software open source é projetado para ser acessado abertamente pelo público: todas as pessoas podem vê-lo, modificá-lo e distribuí-lo conforme suas necessidades.

O software open source (OSS - Open Source Software) é desenvolvido de forma descentralizada e colaborativa e conta com a revisão e a produção pela comunidade. Ele costuma ser mais barato, mais flexível e mais duradouro do que as opções proprietárias, já que é desenvolvido por comunidades independentes, e não por um único autor ou empresa.

Fonte: https://www.redhat.com/pt-br/topics/open-source/what-is-open-source

Tendo minimamente esse ponto esclarecido, opensource é uma forma de distribuição. Assim como GNU, GPL, etc, podendo ser visto como estratégia. A google é Rainha nisso.

agora para você que possui paciência e gostaria de aprender

Como "cobrar" por algo que é Open Source (ou de graça)

Onde ninguém têm a necessidade de atender seu problema individual.

Antes de tudo, esclarecer alguns pontos conceituais que muitos na nossa área ainda confundem:

1. "Open Source" fala sobre Liberdade, não sobre Gratuidade

A famosa máxima da Free Software Foundation resume bem: Free as in free speech, not as in free beer("Livre como em liberdade de expressão, e não como em cerveja grátis"). O Open Source é uma forma de distribuição e licenciamento que garante acesso ao código, transparência, auditabilidade e colaboração. Ele não proíbe a comercialização, nem obriga o mantenedor a trabalhar de graça como suporte técnico. E fundamentalmente esquecivel por algumas pessoas: Um projeto open source é uma das ferramentas mais fundamentais e acessíveis para quem está começando a estudar programação e tecnologia. Como o código-fonte desses programas é público, qualquer pessoa pode visualizar, modificar.

Estudar! Coisa que parecem que não fazem na era da IA.

2. O código pode ser livre, mas o Tempo e o Suporte não são

Existe uma diferença enorme entre o código-fonte (que está lá, estático no repositório) e o trabalho contínuo (compilar, empacotar, manter servidores, corrigir bugs urgentes, tirar dúvidas, criar instaladores one-click). O código pode ser grátis, mas a conveniência e a garantia têm custo.

Ao meu ver, se você usa, lucra e não colabora nem financeiramente, nem intelectualmente. Você é um Parasita!

https://www.youtube.com/watch?v=nX0wPjNzn3o <- Manifesto Anti-Parasita: Seja um Criador - Fabio Akita

3. "Cobrar" não é vender a licença, é vender a Redução de Fricção

A maioria dos usuários (especialmente o usuário final) não quer baixar o código, configurar dependências, compilar o projeto e resolver erros de build. Eles querem praticidade. Quando você cobra por algo mantido em Open Source, você está cobrando pelo tempo que poupa do usuário ou pelo risco que você tira das costas dele.

Como estruturar a cobrança (ou melhor, a solicitação) corretamente:

Se você encontrou um bug, precisa de uma funcionalidade nova ou quer que o projeto suporte a atualização X, existem formas corretas de interagir com o repositório sem ser um peso morto:

1. O Código é Aberto: Não cobre, Colabore (Pull Request > Reclamação)
Se a ferramenta não faz o que você quer, a atitude de um desenvolvedor de verdade é clonar, resolver e submeter um Pull Request (PR). Reclamar de braço cruzado esperando que o mantenedor trabalhe para você de graça é atestado de incompetência ou preguiça. O projeto é de todos, a responsabilidade de melhorar também é.

2. Abra Issues com Qualidade Técnica (Seja útil, não um cliente de padaria)
Se você não sabe codar a solução ou está apenas começando a estudar, o mínimo que deve fazer é poupar o tempo de quem vai resolver. Esqueça frases como "Parou de funcionar na versão nova, arruma aí".
Uma cobrança decente vem em forma de uma Issue bem documentada:

  • Passos exatos para reprodução.
  • Logs de erro completos.
  • Versão do SO e ambiente detalhados.
    Aja como um investigador técnico ajudando na triagem, não como um usuário leigo de suporte de internet.

3. Financie a Prioridade (Bounties e Patrocínio)
Você ou sua empresa ganham dinheiro usando essa ferramenta de graça no dia a dia? O bug parou a sua operação e você precisa disso para ontem? Pague.
Ofereça um Bounty (recompensa financeira pela issue) ou assine o GitHub Sponsors/Patreon do desenvolvedor. A única forma legítima e ética de "exigir" que o problema de um indivíduo fure a fila das prioridades de um projeto gratuito é remunerando o tempo do mantenedor.

4. Mude a abordagem de "Quando sai?" para "Como posso ajudar a sair?"
Cobrar prazos de quem trabalha de graça nas horas vagas é o auge do desrespeito. Se você quer acelerar o lançamento de algo, ofereça ajuda. Se não tem conhecimento técnico para mexer no core do projeto, ajude testando versões Beta, respondendo dúvidas de outros usuários iniciantes nas issues abertas, ou até mesmo traduzindo e melhorando a documentação. Você alivia a carga do mantenedor, permitindo que ele foque no código que você tanto quer.

5. Silêncio e Gratidão também são contribuições
Se você não tem dinheiro para apoiar, não tem conhecimento para fazer um PR e não tem tempo para documentar... a melhor forma de "cobrar" é não atrapalhar. Apenas reporte o bug com educação e aguarde. A gratidão pela existência de uma ferramenta gratuita que facilita a sua vida já deveria ser o seu estado padrão.

Resuminho para burrinhos

"Cobrar" a comunidade Open Source não é violação ética. Pelo contrário: é o que garante a sustentabilidade e interesse continuo no projeto. Saber como cobrar e valorizar o trabalho dos outros é necessário para qualquer desenvolvedor de verdade.

Quem quer software 100% gratuito precisa entender que o preço disso é aceitar o tempo e os limites do voluntariado do mantenedor. Se quer exigência, prazos e suporte, precisa estar disposto a contratar um serviço.

Carregando publicação patrocinada...
5

Meus 2 cents,

Parabens pelo post !

Tambem me parece esquisito que um usuario de software disponibilizado como opensource e/ou freesoftware se achar na posicao de poder exigir algo.

Todas as principais licencas de codigo aberto possuem clausulas explicitas (geralmente escritas em letras maiusculas para ter peso legal e destaque) que tratam especificamente da Isencao de Garantia (Disclaimer of Warranty) e da Limitacao de Responsabilidade (Limitation of Liability).

    1. Licença MIT

Eh uma das mais curtas e diretas. No seu paragrafo final, ela isenta totalmente os autores:

"THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."

    1. Apache License 2.0

A licenca Apache dedica as Secoes 7 e 8 inteiramente a esse aspecto:

Trecho da Seção 7 (Disclaimer of Warranty): "Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied..."

Trecho da Seção 8 (Limitation of Liability): "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise [...] shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work..."

    1. GNU General Public License v3.0 (GPLv3)

A licenca GPLv3 tem clausulas muito parecidas nas Secoes 15 e 16:

Trecho da Secao 15 (Disclaimer of Warranty): "THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND..."

Trecho da Secao 16 (Limitation of Liability): "IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM..."

Se o usuario, ou pior, uma empresa (que muitas vezes lucra utilizando a ferramenta), precisa de garantias, SLAs de atendimento e correcoes com prazo definido, a solucao eh simples: que pague por um software comercial, compre uma licenca enterprise ou contrate o mantenedor para prestar suporte e consultoria.

A beleza do codigo aberto eh justamente a descentralizacao e a colaboracao. Achou um bug ou precisa muito de uma funcionalidade nova ? O codigo está aberto. Eh so fazer um fork, arregacar as mangas, codar a solucao e enviar um Pull Request.

Ficar exigindo prazos, postura de "funcionario" ou atendimento premium de quem dedica seu tempo livre para agregar valor aa comunidade eh, no mínimo, pura falta de empatia e nocao.

Mais uma vez, excelente reflexao!

Obrigado por compartilhar !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

1

Você sabia que tem gente que paga para usuários testarem um sofware e retornarem um feedback sobre ele?

"Reclamar" pode ser visto como uma coisa ruim por quem tem pouca maturidade, mas reclamar também é contribuir com o projeto. É a pessoa dedicando o tempo dela para baixar, rodar, testar, aplicar ao seu caso de uso real, avaliar os pontos negativos, entraves e problemas encontrados e depois escrever um feedback.

Não existe isso de "a maioria só reclama" como muita gente fala. Não, a maioria não move um dedo sequer para interagir. Não escreve comentário, não manda e-mail, não faz nada... A pequena parcela que reclama são os que estão interessados o suficiente no projeto para fazerem o esforço de testarem, avaliarem e escreverem um feedback. E isso deveria ser valorizado.

-- "Ah, mas a pessoa foi mal educada ao escrever a reclamação dela."

É, lembre-se que ela trabalhou de graça também assim como o desenvolvedor do projeto. Teste de software é remunerável (vide Google se não acredita em mim) e a pessoa fez isso de graça pra você. Cavalo dado não se olha os dentes.

Enfim, sinceramente eu acho esquisito como a imaturidade parece ter se tornado o normal na bolha dev.

2

O seu argumento parte de uma falsa equivalência muito perigosa: confundir QA (Garantia de Qualidade) com birra de usuário.

Aqui estão os pontos para colocar essa visão na perspectiva da realidade:

1. O abismo entre Teste Remunerado e Reclamação Vazia
Sim, empresas gigantes pagam por testes de software. Mas elas pagam por bons testes. Pagam por relatórios estruturados, passos de reprodução, logs anexados e análise técnica. Nenhuma empresa do mundo paga para um usuário simplesmente "reclamar". Reclamar por reclamar não é contribuição, é ruído. Se o feedback não é técnico nem construtivo, e sim um despejo de frustração de quem muitas vezes nem entende como a ferramenta funciona por baixo dos panos, o mantenedor não tem obrigação nenhuma de engolir.

2. A obrigação de saber se comunicar
Não existe essa de aceitar grosseria porque "a pessoa dedicou tempo". Saber se comunicar socialmente é o requisito número um da vida em sociedade. Ninguém é obrigado a interagir com um babaca que justifica a própria falta de educação com um "ah, mas esse é o meu jeito". Se a pessoa não sabe se comunicar com o mínimo de civilidade, das duas uma: ou ela é obrigada a aprender, ou vai ser (com toda a razão) ignorada. Até num jogo de tabuleiro no fim de semana, quem só reclama e não sabe se comunicar estraga a mesa. Na bolha dev, não é diferente.

3. A inversão do "Cavalo Dado"
Você citou que "cavalo dado não se olha os dentes" para justificar que o mantenedor deveria aceitar o feedback mal-educado, já que o usuário "testou de graça". É exatamente o oposto. O cavalo dado é o software, o código aberto, as horas de engenharia que o desenvolvedor entregou de graça para a comunidade. Quem está ganhando algo de graça é o usuário.

Como eu disse no artigo: "Onde ninguém tem a necessidade de atender seu problema individual". O mantenedor não fez a ferramenta para suprir a necessidade específica daquele usuário; ele apenas resolveu um problema e disponibilizou a solução.

4. A Inteligência Emocional do Mantenedor (O outro lado da moeda)
Dito tudo isso, é óbvio que o desenvolvedor também tem o dever de saber agir nessas situações sem se deixar abalar. Desenvolvimento de inteligência emocional é o básico para quem coloca qualquer coisa pública na internet. O mantenedor maduro não entra em desespero, não dá chilique e nem abandona o projeto por causa de um usuário tóxico; ele simplesmente ignora o ruído, fecha a issue sem pena e segue o jogo.

A verdadeira imaturidade não é o desenvolvedor ignorar quem é mal-educado. A verdadeira imaturidade é o usuário se colocar num pedestal, achando que o seu download é um favor tão grande que lhe dá o direito de tratar o mantenedor como seu funcionário. Quem está acostumado a receber restos da vida pode até aceitar esse tipo de tratamento, mas desenvolvedor open source nenhum é obrigado a engolir.

0