Nosso doctor da comunidade contou como ele começou no Rails, em como foi chato ver pela primeira vez o tutorial de Rails de 15 minutos e como ele largou o Visual Studio e mudou para Rails.

Antes de fazer hacks em código as pessoas faziam hack em carros e o Dr Nic era triste pois os pais dele não deixaram ele hackear o carro, já que eles precisavam usá-lo. Depois apareceram os hacks de hardware, mas eles eram caros. E então apareceu o código, onde você não precisa gastar dinheiro nenhum para começar a hackear. No passado não havia tanto código quanto hoje, então hoje é muito fácil estudar código e olhar código para hackear.

Foram apresentados algumas estatísticas do número de projetos opensorce no sourceforge, rubyforge e github. É notável, pois há cerca de 6500 projetos no rubyforge, enquanto já existem 19000 no github!

Mais uma vez, assim como o Chad Fowler, uma palestra falando sobre reconhecimento pessoal. Dr Nic incentivou a colaboração, fazendo uma analogia com dinheiro. Se você tem $1,000 que você não pode gastar em lugar nenhum, para que serve esse dinheiro? Essa foi a relação que ele fez com os segredos de código.

Defendeu uma mudança no pensamento em relação a grupos e permissões, dando mais incentivo ao individuo. Na opnião dele simplesmente dizer que algo está quebrado é uma coisa muito lenta. Então normalmente ele interfere num projeto enviando um patch, pois este diz tudo que diversos e-mails não resolveriam. É algo como andar na frente. Em suas palavras: “There is no them”.

Falou sobre as diversas atividades que os desenvolvedores podem ter dentro de um projeto opensource e como cada uma dessas atividades individuais são importantes. Existem diversas oportunidades de contribuição em projetos opensource, inclusive os projetos não mais mantidos do Dr Nic. Enfatizou bastante a questão da não necessidade de permissão para fazer as coisas, e sobre como o git facilitou a nossa vida nesse sentido.

Ele citou o exemplo de um cara que trabalha com ele que programa em Cocoa, mas que não entende nada de software opensource, que não contribui com a comunidade. E mais um vez está a importancia dos blogs para divulgar a cultura opensource e mostrar para esse tipo de pessoa sobre como trabalhar colaborativamente pode favorecer a todos.

Os caminhos para se tornar bom na comunidade: aprender controle de versão(svn e git), aprender unit testing, começar um blog, aumente a sua bagagem técnica e na comunidade

Ele focou bastante ao falar do tdd. Ele não mexe em código que não tem teste, no máximo auxilia na documentação. E ainda falou das facilidades já oferecidas pelo Rails.

Sobre o blog ele falou da importancia que o blog teve para torná-lo conhecido e sobre como isso pode ajudar os profissionais para se tornarem também. Enfatizou que não é preciso escrever textos formais no blog, o importante é contribuir com qualquer coisa que você tenha aprendido. Isso ajuda você no futuro e ainda ajuda a comunidade.

Participar de conferências, mostrar o seu código, corrigir o código dos outros, fazer (boas) perguntas em forums, traduzir coisas para o português e para o inglês.

Don’t keep secrets! Compartilhe, compartilhe, compartilhe!

Esse é o caminho para o awesomeness!