Como alguém se torna um grande colaborador de um projeto de código-fonte aberto?


10

Eu sei que o conselho padrão para projetos de código aberto e, para começar, é começar a corrigir bugs. Mas tenho a sensação de que esse é o caminho que alguém gostaria de seguir se quisesse ser um testador / reparador de bugs no projeto. Como alguém se torna um colaborador ativo de um projeto de código-fonte aberto? [Ou seja, no nível da arquitetura]


15
Etapa 1 - Torne-se um grande colaborador. Passo 2 - corte um pouco.
Psr

Respostas:


10

Provavelmente isso vai parecer um pouco de tautologia, mas se você quiser se tornar um dos principais contribuidores de novos recursos, use o produto por um tempo, encontre um novo recurso que o melhore, escreva o código para implementá-lo e contribua.

A razão pela qual as pessoas são aconselhadas a começar com correções de erros é que isso as leva a vasculhar a base de código e a se familiarizar com o modo como as coisas funcionam. Isso também fará com que você participe da comunidade de discussão do projeto, qualquer que seja, (geralmente uma lista de discussão ou fórum), para que você tenha uma ideia da direção do projeto. Você se sentiria um pouco tolo se concluir 80% do seu novo recurso apenas para descobrir que alguém está trabalhando nisso o tempo todo e eles acabaram de terminar!


Até aqui, você diria que essa tática é mais política ou mais embaraçosa? [Aka. anunciando um patch em um blog, antes de obter permissão para cometer]
monksy

2
@monksy - não é, pois você normalmente não a tornaria pública, mas a contribuiu por qualquer mecanismo apropriado à base de código. Você está tentando ganhar confiança por meio de uma experiência compartilhada. Você não consegue cometer privs por pessoas irritantes!
Sdg

11
@monksy: não anuncie seu patch em um blog; como você sabe que alguém do projeto vai vê-lo? Se você tiver um patch, leve-o à comunidade de discussão e fale sobre ele lá. É aí que é provável que você obtenha a resposta mais útil. (Se você tiver uma correção de bug, esteja preparado para provar que existe realmente um bug. Isso significa que você entende o que o código deve fazer e pode mostrar um caso reproduzível em que ele faz outra coisa. Verifique se você sabe a diferença entre um erro eo código fazendo algo que é suposto fazer isso você não gosta).
Mason Wheeler

4

Não há atalhos. Projetos de código aberto são extremamente baseados em mérito. Quando você mostrar que é capaz de lidar com tarefas menores, você acabará confiando em tarefas cada vez maiores. Os projetos de código aberto também têm muita motivação dos contribuidores que contribuem com um ou dois patches e depois ainda mais pessoas que "contribuem" com uma ou duas idéias importantes, mas não implementadas, e seguem em frente. Se você quiser fazer contribuições maiores, precisará mostrar que está envolvido a longo prazo.

Dito isto, as melhorias incrementais da arquitetura são bem-vindas, especialmente se resolverem um grande problema de bug ou desempenho. Por exemplo, há vários anos, um dos poucos patches que contribuí para o projeto Cinelerra foi uma alteração na arquitetura da pilha de desfazer, que reduziu significativamente o consumo de memória e a latência para operações que não podem ser desfazidas.

Você encontrará o maior sucesso se estiver resolvendo um problema que está enfrentando pessoalmente, em vez de apenas "se tornar um colaborador de um projeto de código aberto". Quando enviei esse patch para o Cinelerra, não estava tentando contribuir com uma alteração arquitetural em um projeto de código aberto escolhido aleatoriamente, tentando descobrir por que demorou tanto tempo para mudar um ponto de entrada / saída ao editar meus vídeos.


Agradável! Eu sempre quis usar o Cinelerra, mas sempre foi difícil instalá-lo no gentoo. Obrigado pelas contribuições. Mas esse é exatamente o tipo de mudança que estou sugerindo e perguntando. É uma mudança grande o suficiente para deixar as pessoas preocupadas, mas não é uma correção de bug.
22412 Monksy

2

Você pode fazer isso conhecendo aqueles que já estão nessa posição e demonstrando interesse em se juntar a eles, o que é melhor conseguido corrigindo bugs, localizando e participando do desenvolvimento.


Esse parece ser um longo caminho para a tomada de decisões de arquitetura / design. [Eu estou operando sob a premissa de que os garfos são ruins]
monksy

@monksy, parece que você está partindo de uma premissa diferente da que talvez sua pergunta tenha indicado. Se você acha que tem a melhor muito maneira do que um projeto atual não, talvez se envolver em uma conversa aberta chave baixa para entender melhor por que as coisas são do jeito que eles são, e depois de lá ir ...
SDG

5
@ monksy subir a escada leva tempo, você não decide começar do topo, a menos que faça sua própria escada.
Ryathal 30/03/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.