Acredito que a partir do momento que você escolhe usar tecnologias abertas, a forma com que sua equipe lida com esse tipo de desenvolvimento pode ser crucial para a produtividade e o bom andamento do projeto.
Vou listar alguns comportamentos diferentes que você pode ter:
Acho que Open source é como qualquer outro tipo de software (Rendimento baixo)
- Você, ou sua equipe, acha que open source é como qualquer outra forma de desenvolvimento, a única diferença é que ela na maioria das vezes é gratuita.
- Você acha que ela está lá para te servir, que basta instalar, rodar, e tudo tem que funcionar como as outras tecnologias fechadas que você está acostumado.
- Você reclama quando encontra falhas na aplicação, e começa a usar isso de desculpa para o desempenho da equipe.
Pode até ser que, em projetos maiores e mais consolidados (ubuntu, mysql, apache), um comportamento como esse não seja tão prejudicial. Mas pensando em projetos menores, como o próprio Rails ou Ruby Gems, uma postura como essa não lhe trará um bom aproveitamento.
Sou apenas um usuário (Rendimento médio)
- Você entende melhor como funciona o desenvolvimento open source, mas se posiciona como mero usuário.
- Se algo não atende suas necessidades você procura por outras soluções ou espera até que o problema seja resolvido.
- Você acha que é um grande problema quando algo assim acontece, pois sabe que vai impactar o rendimento da equipe.
Esse tipo de comportamento é um pouco melhor do que o anterior. Equipes em que trabalhei que agiam assim com o tempo até acabavam sendo mais críticas para escolher entre as tecnologias (vendo se o projeto ainda é ativo, reputação, etc) e acabavam contornando problemas, mas ainda eram meros usuários e de vez em quando travavam por problemas não tão complexos.
Eu contribuo (Rendimento alto)
- Sua equipe sabe o que é open source e lida com ele com espírito de contribuição
- Se algo não atende suas necessidades você:
- faz um fork do projeto e manda um patch pra equipe que o está desenvolvendo
- cria um outro projeto open que faça o que você precisa (se os que existem são muito diferentes da sua necessidade)
- entra em contato com com a equipe que o desenvolve e reporta o seu problema (e se possível os ajuda a solucioná-lo)
- Fica feliz quando encontra um bug pois ve uma oportunidade de contribuir
Essa situação eu encontrei na equipe que trabalho no momento (Gonow) e foi surpreendente ver o quão mais produtivo é trabalhar assim.
Contribuindo para os projetos você atende suas necessidades de uma forma mais rápida. Você não precisa esperar até que alguém resolva seu problema, o código está lá e equipes open source são extremamente receptivas e gratas por receber patches e novas features (portanto que sigam o foco do projeto e as regras para contribuição).
Contribuir não é tão difícil quanto parece, você vai melhorando aos poucos, vai entendendo melhor como cada projeto funciona, aumenta sua capacidade de ler e entender código dos outros, ve bons exemplos de códigos, entre outros. Só há ganhos.
Você até treina seu inglês!
Lançar projetos open source também é de grande valia. Em um projeto la na Gonow precisávamos de algo que calculasse distâncias entre lugares. Existiam gems que calculavam mas todas faziam isso a partir do raio, nenhuma fazia a partir da rota. Desenvolvemos nossa solução para isso (o go_maps) e o lançamos como open source. Tivemos ganhos logo nos primeiros dias, pois alguns usuários reclamaram de coisas que ele não tinha e percebemos que íamos precisar também. Tivemos esse feedback antes mesmo de lançar nosso projeto aos clientes.
Portanto fica a dica, se você pretende usar open source, saiba que não é apenas um software gratuito, ele é um software colaborativo. Incentive sua equipe a contribuir, se possível dediquem tempo do próprio projeto para isso, uma vez que esses softwares são parte do projeto.
É isso pessoal, nos vemos amanhã no Rails Rumble!
