Qual é a resposta canônica para "é open source, envie um patch"? [fechadas]

É um ponto difícil: como o usuário não paga, direta ou indiretamente, por um produto, ela não pode pedir que um recurso seja implementado. Não é como se você fosse uma parte interessada ou um cliente direto que encomendou o produto e nem mesmo um usuário final de um produto comercial.

Dito isto, "enviar um patch" não é uma resposta válida. Não é educado. Não é correto. Mesmo para um produto de código aberto. "Enviar um patch" é a versão curta de:

"we don't care if you like our product or not. Go and modify it if you want, but don't bother us with your customer requests."

Que tal enviar um patch?

Bem, não é tão fácil. Para fazer isso:

• Você deve conhecer o (s) idioma (s) usado (s) no projeto de código aberto.

• Você deve conseguir carregar o código-fonte do controle de versão para poder modificá-lo.

• Você deve ter todas as versões corretas de quaisquer dependências de compilação instaladas (incluindo bibliotecas de tempo de execução e ferramentas de compilação).

• Você deve ser capaz de compilar este código-fonte , o que não é tão óbvio em alguns casos. Especialmente, quando um grande projeto leva algumas horas para compilar e exibir 482 erros e milhares de avisos, você pode ser corajoso para pesquisar a origem desses erros.

• Você deve entender muito bem como o projeto é feito , qual é o estilo de codificação a ser usado, se houver, como executar testes de unidade, etc. Se o projeto não tiver uma documentação decente (que é frequentemente o caso de projetos de código aberto), pode ser muito difícil.

• Você deve se adaptar ao projeto e aos hábitos dos desenvolvedores que participam ativamente do projeto. Por exemplo, se você usa o .NET Framework 4 diariamente, mas o projeto usa o .NET Framework 2.0, não é possível usar o LINQ, nem o Code Contracts, nem outros milhares de novos recursos das versões mais recentes da estrutura.

• Seu patch deve ser aceito (a menos que você faça a alteração apenas por si mesmo, sem a intenção de compartilhá-lo com a comunidade).

Se sua intenção é participar ativamente do projeto, você pode fazer todas essas coisas e investir seu tempo para isso. Se, por outro lado, há apenas um pequeno bug irritante ou um recurso simples que está faltando, gastando dias, semanas ou meses estudando o projeto, então fazer o trabalho em poucos minutos é irracional, a menos que você goste.

Então, há uma resposta canônica para "é open source, envie um patch"? Acho que não. Ou você explica para a pessoa que ela é indelicada ou simplesmente para de falar com ela.

A resposta canônica é enviar um patch.

Esta é a resposta padrão quando os desenvolvedores não acham que farão algo em qualquer período de tempo razoável, mas tem sido repetidamente levantado.

É injusto quando é repetidamente trazido à tona, mas a pessoa que mais recentemente mencionou isso não sabe disso, e apenas recebe "nós estamos recebendo correções para isso" imediatamente. Nesse caso, o mantenedor está cansado da discussão, mas o usuário acha que é um novo tópico. De qualquer forma, muito provavelmente, se você começar a "receber patches" imediatamente, você não deve levá-lo pessoalmente, mas pode querer ler os arquivos e o rastreador de bugs para obter mais detalhes sobre o assunto.

Se você mesmo estiver fazendo uma solicitação repetidamente, "tomar patches" tem a intenção de ser uma tarefa relativamente educada, contra algumas alternativas menos educadas ...

E, claro, há mantenedores grosseiros que dirão "tomar remendos" sem nenhuma explicação para ninguém, mas eu diria que é uma minoria.

Se você já manteve um projeto de código aberto com muitos usuários, saberá que há 100 vezes mais solicitações do que os mantenedores poderiam obter, e muitas dessas solicitações são importantes para o solicitante, mas seriam escandalosamente difícil, ou iria perturbar muitos outros usuários, ou ter alguma outra falha que só é visível com uma compreensão global do projeto e da base de código. Ou às vezes há apenas julgamentos, e leva muito tempo para discutir cada um de novo.

A maioria das empresas não-abertas não lhe dará acesso aos desenvolvedores, e você receberá o tratamento silencioso ou uma história polida, mas falsa, do suporte ao cliente. Então, no open source, pelo menos você tem algumas opções (pagar alguém para codificar o recurso, etc.) e enquanto os desenvolvedores podem ser rudes, pelo menos eles dão respostas diretas. Eu prefiro ter "não" do que o habitual "está em nosso roteiro ... [2 anos depois] ... ainda está no nosso roteiro" algo que eu recebi de vários fornecedores ...

Então eu não acho que haja uma resposta. Talvez o mantenedor de software livre esteja realmente ocupado, talvez seja um idiota, mas de qualquer forma, eles provavelmente têm um trabalho duro e entrar em um debate sobre quem tem a última palavra não vai a lugar nenhum. O melhor que você pode fazer é contribuir de alguma forma e tentar ser construtivo.

Talvez não seja um código, mas possivelmente há muita análise e documentação de cenários de usuário que você poderia fazer. Quando eu estava mantendo o gerenciador de janelas do GNOME, muitas vezes teria sido útil para as pessoas analisarem um problema globalmente considerando todos usuários, e realmente anotar os problemas e prós e contras e o que deveria acontecer de uma perspectiva global.

(Em vez disso, o normal era começar a flamar como se fosse o único usuário que importava e não havia compensações. E enquanto isso era ótimo, e era um ponto de dados, e muitas vezes eu conseguia ficar educado ou até mesmo resolver o problema deles) eventualmente ... o fogo não faz com que nada aconteça mais rapidamente. Apenas confunde emoções com o assunto e desperdiça o tempo de todo mundo.)

O motivo pelo qual você recebe essa resposta não é que os mantenedores são idiotas, mas você não os convenceu adequadamente da proposição de valor deles trabalhando no seu recurso para você .

A melhor resposta é iniciar um diálogo sobre o valor do seu recurso para a comunidade como um todo , para ver se você pode convencê-lo a mudar de idéia. Talvez eles estejam certos e saibam mais sobre as necessidades de sua própria comunidade do que você - mas, novamente, talvez não.

Se o recurso é valioso para você e de pouco ou nenhum valor para a comunidade, acho que o dinheiro é um excelente motivador, enquanto reclama de sua atitude não é.

What's the canonical retort to “it's open source, submit a patch”?

Não há uma resposta razoável que possa fazer alguma diferença. Tentar persuadir os voluntários a fazer algo que eles não têm intenção de fazer é um desperdício de tempo ... ou pior.

Suas opções são:

• Faça o que a resposta sugere; isto é, implementar o recurso e enviá-lo como um patch. É chamado "dando algo de volta".

• Encontre alguém que esteja disposto a implementar o recurso para você por dinheiro real. Pode ser o próprio projeto (por exemplo, em troca de patrocínio), alguém associado ao projeto ou algum "codificador de aluguel" aleatório.

• Encontre um produto alternativo.

Se você recebeu essa resposta quando fez uma sugestão "útil", pense em como poderia ter respondido se estivesse no lugar dele. Por exemplo, como você responderia se pensasse que a sugestão não valeu a pena / bem pensada / inteligível / etc, mas não teve tempo ou paciência para se engajar em um debate prolongado?

Estou envolvido em um projeto OS de código aberto de longa duração, e uma das coisas mais irritantes são as pessoas que se sentam na "galeria do amendoim" e o estimulam com um fluxo de sugestões sobre como fazer coisas "melhores" que:

• são incompletas, ininteligíveis ou francamente sem sentido,
• são ideias não experimentadas com uma chance objetivamente baixa de sucesso,
• exigiria muito esforço para implementar e / ou
• são contrários aos objetivos declarados do projeto.

Muitas vezes, a melhor resposta é desafiar a pessoa a se envolver no projeto ... e esperar que ele dê a dica ... para "calar ou calar a boca". Infelizmente, os mais irritantes não dão nem uma dica.

Naturalmente, a outra resposta a essas pessoas é não responder de todo, ou ignorá-las completamente.

A resposta seria razoável se você e o programador em questão fossem iguais, e soubessem quase o mesmo sobre a base de código e a linguagem e todas as outras coisas relevantes para essa coisa específica que você está apontando.

Você não é igual (ou você provavelmente teria feito isso), então eu sugiro que uma resposta apropriada seja:

"Não há como eu conseguir fazer o mais rápido e melhor que puder, e é por isso que pedi a você que me ajudasse em primeiro lugar. Por favor!"

Eu acredito que vai contra a natureza humana fundamental dizer "ah, sim, essa coisa que eu passei um bom tempo e é muito boa, é tão simples que qualquer um pode vir da rua e se sair tão bem um trabalho como eu posso ".

A réplica canônica é separar o projeto.

A resposta canônica para "enviar um patch" é:

"I don't have the skills, experience or time required so can you please tell me where to ship the cases of beer to the guy who can do it for me"

Envie um caso de teste abrangente .

"Se você fizer isso, vou incluí-lo" é muito melhor que "não".

Se você não puder fazer o trabalho por um motivo ou outro, explique a circunstância ao mantenedor do projeto em particular.

Se você não estiver disposto a contribuir de alguma forma para um projeto de código aberto que gostaria de usar, então você deve procurar suporte comercial ou outro produto comercial.

"Obrigado pela resposta".

Porque:

• A preço zero, a demanda (solicitações de recursos) excede a oferta (codificadores disponíveis para implementar esses recursos).
• Desculpas em qualquer coisa que é fornecida gratuitamente não tem classe IMHO.
• Esse é o objetivo da FOSS: pessoas trazendo vegetais e carne para adicionar nutrição à sopa de pedra. Se eu não posso contribuir com algo, então eu deveria estar agradecido por poder comer de todo, e não reclamar que não estou comendo melhor.

Você não precisa dizer nada. O próprio fato de os desenvolvedores terem respondido é indicação suficiente de que eles já sabem que o problema existe e que causa dor para (pelo menos alguns) usuários.

No final do dia, nada do que você disser vai convencer o desenvolvedor a trabalhar para você se não quiser.

Um bom projeto de código aberto terá um sistema de solicitação de bugs / recursos onde os usuários podem enviar bugs / recursos e outros podem votá-los para que os mantenedores possam identificar o que é importante para a comunidade como um todo. A maneira mais rápida de obter seu recurso no lugar é enviar um patch para ele. Período ... não há maneiras de contornar isso.

A resposta "enviar um patch" é muito rude, já que assume várias coisas:

1. Todos os usuários do programa são programadores ou todos os repórteres de bugs são programadores.
2. Todos os programadores conhecem a linguagem em que o programa se encontra.
3. Todos os programadores conhecem todos os tipos de problemas que um programa de qualquer tipo pode ter.
4. Todos os programadores têm tempo livre para trabalhar em um projeto de código aberto.

Mesmo se assumirmos que o respondente "enviar um patch" sabe tudo o que foi dito acima, isso simplesmente faz com que a afirmação soe como "X horas do meu tempo valem mais do que as ordens de magnitude mais de horas do seu tempo para acelerar e corrigir o problema ".

Geralmente, quando recebo uma resposta grosseira de um desenvolvedor quando pergunto sobre um problema que tenho ou envio um bug, paro de usá-lo . Eu não uso mais o uTorrent (não é open source, mas o ponto permanece) por exemplo, porque as respostas que recebi em seu fórum de "suporte" foram tão rudes. Eu enviei um problema que tive no fórum do Bug Reports. O encadeamento foi imediatamente bloqueado com um link para outro encadeamento sobre um problema semelhante, mas diferente em um encadeamento (que também foi bloqueado, é claro). Nesse meio tempo, abri um tópico no fórum de discussão geral perguntando se alguém encontrou uma solução alternativa para o problema. No tempo que levou para salvar esse tópico e voltar e ver que meu primeiro thread tinha sido bloqueado, meu thread em geral foi bloqueado e minha conta do fórum banida por comportamento perturbador. Eu desinstalei o uTorrent e não voltei desde então.

Apenas responder "enviar um patch" é um IMO grosseiro, mas ainda assim ... se você usar um software de código aberto para qualquer coisa séria, você deve estar preparado para cuidar dele caso seja necessário.

O seguinte é baseado em um post de Jeremias Maerki (da Apache FOP fama):

If something doesn't work for you, you have several options:

• This is open source: you can fix it yourself.
• If you cannot fix it yourself, you can wait until someone has free time and thinks it is fun to implement.
• If that doesn't happen, you can find or hire someone to do it for you.

Acho que é uma versão completa muito válida da resposta "enviar um patch".

Toda vez que vejo isso, imediatamente começo a procurar por um produto alternativo. Para mim isso é um sinal perigoso de que os mantenedores não se importam com seus usuários (ruim se o seu projeto é usado em qualquer lugar) ou perderam o interesse pelo projeto. Ambas geralmente significam que o projeto vai morrer em breve ou será afetado pela estagnação, já que os desenvolvedores se recusam a levar o projeto adiante

(Note que eu não estou dizendo que o primeiro relatório de bug que você vê com esse tipo de resposta é executado. Você tem que olhar para uma tendência geral. Se a maioria dos relatórios de bugs termina com esse tipo de resposta, siga este Se forem apenas alguns, então esses são provavelmente os pedidos de recursos que não se encaixam nos objetivos do projeto ou são extremamente específicos ao uso)

Como @MainMa disse que começar a contribuir para um novo projeto é muito difícil. A maioria dos desenvolvedores não entende isso, já que eles estão trabalhando no projeto há meses / anos e faz sentido para eles. Isso às vezes pode ser um erro honesto.

Eu, ocasionalmente, brinco que o software livre pode ser livre como na cerveja, livre como na fala ou livre, assim como você recebe o que você paga.

Enquanto eu digo em tom de brincadeira (eu trabalho para uma empresa que usa muito OSS), mas acho que há uma verdade lá - se você quer suporte de nível comercial, então você precisa usar software comercial com um acordo de suporte adequado, ou encontre uma solução de software de código aberto que lhe permita esse nível de suporte (geralmente através de alguém sendo pago para fornecê-la, mas potencialmente através de sua organização empregando ou atribuindo recursos de desenvolvimento para trabalhar nela).

"Enviar um patch" é enfurecedor, mas destaca algo sobre o OSS e talvez seja um lembrete de que o OSS não é adequado para todos em todas as situações, pelo menos não sem ter certeza de que você tenha uma estrutura de suporte sólida para (internamente, pago ou através da comunidade).

Muitas vezes pensamos em software que é livre como na cerveja, mas não como na fala (ou seja, freeware não aberto). Talvez este seja um caso em que devemos pensar sobre o software tão livre quanto na fala, mas não como na cerveja.

Mude para uma alternativa bem mantida.

A partir da minha experiência com projetos de código aberto bem mantidos é que, se você criar um relatório de bugs bem definido ou uma solicitação de recurso, ele terá uma chance muito alta de ser implementado.

"Eu posso trabalhar em apenas uma coisa de cada vez, mas posso reclamar de muitas coisas ao mesmo tempo. Acho que ambas as funções são úteis." - akkartik no ycombinator .

Eu considero que quando um está trabalhando em um projeto, fornecendo releases e suporte, um contrato implícito de suporte implícito entre dev e user surge. O desenvolvedor assumiu a responsabilidade implícita de suportar a base de código para seus usuários, incluindo a adição de recursos mediante solicitação.

"Enviar um patch" é basicamente dar o dedo para os usuários, na minha opinião. Isso é contextual - às vezes é um esforço muito grande para implementar, às vezes isso destruiria o projeto existente ou incorreria em creaturite, ou qualquer outra série de outras razões. Mas, no final das contas, está dizendo: "estrague você, não faça isso". O que, em minha opinião, é, em algum nível, uma violação desse contrato não dito.

Existem várias maneiras de fazer isso.

• Proposta de recurso e votação. mas isso leva tempo.

• Seja contratado por uma empresa que precise fazer o patch. Obviamente, esta é a melhor solução, mas prepare-se para colaborar com o cara que faz o software de código aberto que você deseja atualizar.

• Descobrir por que o recurso não foi implementado em primeiro lugar também é importante. Muitas vezes, o recurso está fora da linha do projeto de software: a equipe não quer esse recurso, não se sente necessário ou apenas acha que não é a melhor maneira de fazer algo. Neste caso, você deve apenas bifurcação do projeto e faça você mesmo.

• Use software proprietário que faz o que você quer.

• Lembre-se de que o software OOP geralmente facilita o processo de integração de um recurso.

• Lamentar em uma lista de discussão, no irc ou em um fórum apenas irritará os programadores, e dará munição aos proponentes de OSS.

Não há nada que você possa dizer que irá fazer fazê-lo. Afinal, por que ele deveria? Por causa dos desejos de um usuário? Não é bom o suficiente.

Mas , se você puder coletar um número razoável de usuários e dar razões racionais ("eu quero isso" não é uma razão racional). por que esse recurso pode ser útil, em geral e para você e um número de outros, ele pode mudar de idéia.

No entanto, há também um caso especial que deve ser considerado. Isso um dev. está cansado de desenvolver o aplicativo, lentamente, desejando abandoná-lo (tem outras coisas para fazer), e assim ele está lentamente abatendo solicitações de recursos. Além de tentar convencê-lo a liberar o código, neste caso não há praticamente nada que você possa fazer, mesmo com relação ao anterior.

Projetos de código aberto, em particular, são amigáveis a prêmios ou financiamento do desenvolvimento de um recurso em particular, mesmo que o novo recurso não chegue aos lançamentos oficiais.

Além disso, sim, uma das ideias por trás da publicação de código aberto é que todos e cada um tenha o direito e a responsabilidade de fazer suas próprias contribuições.

Com código fechado, seu melhor recurso é reunir um grupo estatisticamente importante da base de usuários que deseja soluções como as que você deseja.

Na minha experiência, essa resposta geralmente é dada se a solicitação do usuário não se encaixa no objetivo do projeto. Acontece quando as pessoas pensam que você vai implementar tudo o que elas propõem para você, e um pouco mais - de graça, de código aberto e um ótimo e feliz futuro.

'Enviar um patch' é uma resposta relativamente rude (e deve ser evitado, é claro. Especialmente nesta forma concisa e nítida. Há muitas maneiras de expressar mais ou menos a mesma mensagem - por exemplo 'convide' os usuários a ajuda, porque você não tem tempo para implementá-lo por conta própria). Mas, como é, é um claro indicador "pare de desperdiçar meu tempo". Como tal, não há muito que você possa fazer sobre isso, nem há resposta 'canônica'.

A melhor resposta que posso pensar é realmente apresentar um patch . Supondo que seu patch funcione, você pelo menos provou que a idéia não é totalmente irrealista. Normalmente, isso significa que as pessoas encarregadas do projeto irão reconsiderar a proposta.

"enviar um patch" é uma desculpa legítima para ideias que não se encaixam nos objetivos do projeto. Provavelmente é melhor, a longo prazo, apenas dizer que a idéia é uma droga ou se você está tentando usar o projeto para algo bem fora do escopo pretendido, mas "ei, se você acha que o que está pedindo é tão trivial, por que não t tentar encaixá-lo em nossa base de código existente "às vezes é apropriado.

Se for menor e realmente útil para os usuários do projeto, basta enviar o relatório do bug, descrever claramente o problema, dar passos para se reproduzir, indicar que você está usando a versão atual e deixá-la em isso.

O que pode parecer uma pequena mudança simples que ajudaria muitos usuários a serem realmente uma grande dor de cabeça que ninguém usaria além de você. Esse é o melhor caso para "enviar um patch".

Também é possível que você tenha se deparado com um caso como o notório mantenedor da glibc que parece ter uma mentalidade de que seu sistema é o universo, sua interpretação das especificações é a palavra de deus, e isso é tudo que existe para isso, independentemente de quantas pessoas prefeririam o contrário.

Eu sugeriria criar um projeto para implementar o recurso em sites como o RentACoder / ELance / etc, e postar sobre isso no fórum original do projeto de código aberto. Qualquer um dos programadores nos projetos de código aberto, incluindo o autor, agora tem um incentivo financeiro para considerar sua solicitação.

Na verdade, me inscrevi apenas para responder a essa pergunta.

Existe necessidade de uma resposta? Essa resposta é geralmente usada quando o desenvolvedor sabe sobre o problema, mas não o considera importante.

Vou dar um exemplo ao vivo. O Ubuntu baixou o suporte systray (mas pode ser contornado pelo white listando um app) e adicionou novos indicadores de aplicativos. alguns aplicativos como o jupiter contavam com suporte systray, então o desenvolvedor falou sobre o workaournd em vez de adicionar suporte a indicadores de aplicativos, então pedi ao desenvolvedor para adicionar o indicador de app suppory a resposta foi "Envie-nos patches. " ao pedir a razão pela qual eles escolheram não implementar isso. havia este

I have no interest in spending my time building support for a libra1ry that I will never use just because someone with a lot of money demands it by blacklisting my applications ability to function properly on his Linux distribution simply because he can.

If it was a real technical problem, I would probably take action but this is purely a political maneuver, so no I don't think so.

No, I'll just whitelist it

Feira suficiente. o desenvolvedor tem razão para não implementar um recurso, mas está disposto a aceitar patches. isso não é realmente rude e ofensivo, então não houve necessidade de uma réplica.

linha de fundo: a réplica canônica seria para enviar o patch, mas se você não puder, não há necessidade de uma resposta

Inicie uma recompensa pelo recurso que você deseja.

Ou saia e compre o produto que afirma fazer exatamente o que você quer e abuse do pessoal de suporte ao descobrir que o marketing não corresponde às suas expectativas.

O melhor que consigo pensar é "você é uma merda".

Desculpe, obviamente, isso não é muito útil, mas acho que esta é apenas uma das situações mais lamentáveis em que o usuário está completamente ferrado. Um apelo brutalmente honesto à consciência do desenvolvedor é um último esforço.

Você poderia tentar oferecer ( tosse ) "doações" para ter seu problema resolvido, mas temo que tal prática, se tornada comum, leve a uma perda muito grande de integridade na indústria, como correções de bugs nunca devem ser lucrativas, seja para software "Livre" ou comercial.