Mesmo depois de você ter tornado o projeto público, você e os outros fundadores irão frequentemente querer manter as questões mais complicadas em um círculo mais interno de comunicações privadas. Isto é especialmente verdade nos dias iniciais do projeto, quando existem muitas decisões importantes a se tomar, e geralmente, poucos voluntários qualificados para tomá-las. Todas as desvantagens óbvias de uma lista de discussão pública irão surgir a sua frente: a demora inerente em conversas por e-mail, a necessidade de deixar tempo suficiente para formar um consenso, a dificuldade em lidar com voluntários inocentes que pensam que entendem todos os problemas mas que não entendem verdade (todo projeto possui este tipo; algumas vezes eles são os contribuidores estrelas do próximo ano, algumas vezes permanecem inocentes para sempre), a pessoa que não consegue entender por que você quer resolver apenas o problema X quando ele é obviamente um subconjunto de um problema Y maior, e assim por diante. A tentação de tomar decisões por trás de portas fechadas e apresentá-las como fato consumado, ou ao menos como recomendações de uma firma com um bloco de votação unido e influente será realmente grande.

Não faça isso.

Mesmo que as discussões públicas possam ser vagarosas e desajeitadas, elas são quase sempre desejáveis a longo prazo. Tomar decisões importantes de modo privado é como jogar spray repelente de contribuidor no seu projeto. Nenhum voluntário sério irá ficar por muito tempo em qualquer ambiente onde um conselho secreto toma todas as grandes decisões. Além disso, discussões públicas possuem efeitos colaterais benéficos que irão durar além de qualquer questão efêmera e técnica de momento:

Finalmente, há a possibilidade que alguém na lista possa fazer uma real contribuição a conversação, trazendo uma idéia que você não havia pensado antes. É difícil dizer a probabilidade disto; só depende da complexidade do código e do grau de especialização requerido. Mas se uma evidência anédota é permitida, eu arriscaria dizer que é mais provável do que alguém intuitivamente espera. No projeto Subversion, nós (os fundadores) acreditávamos enfrentar um conjunto profundo e complexo de problemas, nos quais estivemos pensando duramente por meses, e francamente duvidávamos que qualquer um da nova lista de e-mails poderia dar uma real contribuição para a discussão. Tomamos então a rota preguiçosa e começamos a debater algumas idéias pra lá e pra cá em e-mails privados, até que um observador do projeto^[12] percebeu o que estava ocorrendo e pediu que a discussão fosse movida para lista pública. Com um pouco de receio, nós fizemos—e ficamos espantados pelo número de comentários e sugestões perspicazes que rapidamente apareceram. Em muitos casos as pessoas ofereceram idéias que nunca haviam nos ocorrido. Isso mostrou que haviam algumas pessoas muito inteligentes na lista; Eles apenas estavam esperando pelo debate certo. É verdade que as questões que seguiram levaram mais tempo do que se tivessem sido mantidas privadas, mas elas eram tão mais produtivas que o tempo extra valia a pena.

Sem entrar em generalizações conhecidas como "o grupo é sempre mais esperto que o indivíduo" (todos conhecemos grupos o suficiente para saber disso muito bem), é preciso saber que existem certas atividades para excelência do grupo. Revisão massiva em pares é uma delas; gerar rapidamente um grande número de idéias é outra. A qualidade das idéias dependem da qualidade do pensamento que as originaram, claro, mas você não saberá que tipo de pensadores existem por lá até que você os estimule com um problema desafiador.

Naturalmente, existem algumas discussões que precisam ser privadas; no decorrer do livro veremos alguns exemplos. Mas o princípio básico deveria ser sempre: Se não há razão para ser privada, ela deve ser pública.

Fazer isto acontecer requer ação. Não é suficiente apenas certificar que todos os seus próprios posts vão para a lista pública. Você deve cutucar a conversação privada desnecessária de outras pessoas para torná-las públicas também. Se alguém tentar iniciar uma mensagem privada, e não há razão para isso, então é sua incumbência deixá-la aberta imediatamente. Nem mesmo comente no tópico original até que você tenha direcionado com sucesso a conversação para um local público, ou assegurado que a privacidade seja mesmo necessária. Se você fizer isto de maneira consistente, as pessoas irão entender rapidamente e passarão a usar os forums públicos como padrão.

Logo no início da existência pública do seu projeto, você deve manter uma política de tolerância zero frente a comportamentos rudes ou de insultos em seus forums. Tolerância zero não significa forçar apenas o técnico. Você não precisa remover as pessoas das listas de e-mail quando elas queimam outro assinante, ou tirar o seu acesso a commits por que eles fizeram comentários tendenciosos. (Na teoria, você pode eventualmente ter de recorrer a tais ações, mas apenas após todas os demais artifícios tenham falhado—o que, por definição, não é o caso no início de um projeto.) Tolerância zero significa simplesmente nunca deixar um mau comportamento passar despercebido. Por exemplo, quando alguém envia um comentário técnico misturado junto com um argumento que ataca algum outro desenvolvedor no projeto, é imperativo que sua resposta aborte o argumento de ataque primeiro, até como um problema separado, e somente então continuar no conteúdo técnico.

Infelizmente é muito fácil, e até bem típico, que discussões típicas se transformem em guerras inflamadas. As pessoas dirão coisas por e-mail que elas nunca falariam cara-a-cara. Os tópicos de discussão apenas ampliarão este efeito: em problemas técnicos, as pessoas geralmente acham que existe uma única resposta certa para a maioria das questões, e que discordar desta resposta só pode ser explicado com ignorância ou estupidez. Há uma curta distância entre chamar a proposta técnica de alguémn de estúpida e chamar as próprias pessoas de estúpidas. Na verdade, é geralmente mais difícil dizer onde a discussão técnica terminar e os ataques pessoais iniciam, e que é um dos motivos pelo qual respostas drásticas punições não são uma boa idéia. Ao invés disso, quando você acha que isto está ocorrenco, faça um pronunciamento que reforce a importâmcoa de manter as discussões amigáveis, sem acusar qualquer um de ser deliberadamente venenoso. Tais pronunciamentos de "Bom Policiamento" tem uma tendência infortúnia de soar como um professor de jardim de infância lecionando uma aula sobre bom comportamento:

Tão formal quanto soa tais respostas, elas tem um efeito notável. Se você expor o mal comportamento, mas não solicitar uma desculpa ou reconhecimento por parte do agressor, você deixa que as pessoas esfriem e mostrem seu melhor lado por se comportarem com mais decoro da próxima vez—e elas irão. Um dos segredos de se fazer isto com sucesso é nunca fazer da agressão o tópico principal. Deve sempre ficar separado, um rápido prefácio para a parte principal da sua resposta. Aponte de relance que "nós não fazemos as coisas desse jeito por aqui," e volte-se para o conteúdo real, e desta forma você dá as pessoas um assunto dentro do tópico para resposta. Se alguém reclamar que não mereceu tal repreensão, simplesmente recuse a aprofundar-se neste assunto. Ou mesmo não responda (se você acha que eles estejam apenas desabafando e isso não requer uma resposta), ou peça desculpas se você exagerou e que é difícil de detectar as nuancias em e-mil, e então retorne ao tópico principal. Nunca, nunca insista em um reconhecimento, sendo público ou privado, de alguém que tenha se comportado inapropriadamente. Se eles escolherem por vontade própria a se desculparem, ótimo, mas pedir que eles o façam só causará ressentimento.

O objetivo geral é que a boa etiqueta seja vista como o comportamento interno do grupo. Isto ajuda o projeto, pois desenvolvedores podem sair (até mesmo de projetos que eles gostam e querem ajudar) por guerras inflamadas. Você pode simplesmente nem saber que eles saíram; alguém pode espreitar a lista de e-mail, e ver que é preciso aguentar as agressões para participar do projeto, e decidem em não se envolver. Manter os forums amigáveis é uma estratégia de sobrevivência a longo prazo, e é mais fácil de fazer isto enquanto o projeto ainda é pequeno. Uma vez que faça parte da cultura, você não terá de ser a única pessoa a promovê-la. Ela será mantida por todos.

Uma das melhores maneiras de promover um desenvolvimento produtivo da comunidade é colocar as pessoas para olhar o código uns dos outros. Uma certa infraestrutura técnica é necessária para se fazer isto efetivamente—em particular, emails de commit devem ser ligados; veja “Commit emails” para maiores detalhes. O efeito de emails de commit é que toda a vez que alguém efetua o commit de uma mudança no código fonte, um e-mail é enviado mostrando a mensagem de log e as diferenças da mudança. (ver diff, em “Vocabulário do Controle de Versão”). Revisão de código é a prática de revisar todos os emails de commit a medida que eles chegam, procurando por bugs e possíveis melhorias.^[13]

A revisão de código serve a vários propósitos simultaneamente. O exemplo mais óbvio é a revisão em pares no mundo do código aberto, e ajuda diretamente a manter a qualidade do software. Todo bug que existe em um trecho de software ficou lá por ter sido "comitado" e não detectado; portanto, quanto mais pessoas verificando os commits, menor a quantidade de bugs existentes. Mas a revisão de código também serve para um propósito indireto: ela mostra para as pessoas que o que elas fazem realmente importa, porque alguém obviamente não lava um tempo para revisar um commit a menos que realmente se importe com o seu efeito. As pessoas fazem seu melhor trabalho quando elas sabem que outros separam um tempo para avalia-lo.

Revisões deveriam ser públicas. Até mesmo em ocasiões quando eu fico sentado na mesma sala física com outros desenvolvedores, e um de nós realizou um commit, tomamos cuidado para não fazer a revisão verbalmente na sala, e ao invés disso a enviamos para a lista de emails de desenvolvimento. Todos se beneficiam vendo a revisão acontecer. As pessoas olham o comentário e algumas vezes acham falhas nele, e até mesmo quando elas não acham, isso os faz lembrar que a revisão é uma atividade regular e esperada, como lavar a louça ou cortar a grama.

No projeto Subversion, não fizemos no início uma prática regular de revisão de código. Não havia garantia que todo código seria revisado, mesmo que de vez em quando alguém pudesse verificar uma mudança se estivesse particularmente interessado naquela parte do código. Os bugs escapavam e realmente poderiam e deveriam ter sido pegos. Um desenvolvedor chamado Greg Stein, que sabia o valor da revisão de código por experiências anteriores, decidiu que ele iria servir de exemplo revisando cada linha de todos os commits que fosse para o repositório de código. Todo commit que qualquer um tenha feito era em breve seguido por um e-mail do Greg para a lista de desenvolvimento, dissecando o commit, analizando possíveis problemas, e ocasionalmente elogiando um trecho inteligente de código. Imediatamete ele achava bugs e práticas de codificação sem otimização que teriam escapado sem nem terem sidos notados. Incisivamente, ele nunca reclamou de ser a única pessoa revisando cada commit, mesmo que isso lhe tomasse um bom tempo, mas ele falava dos elogios sobre a revisão de código sempre que tinha chance. Logo, outras pessoas, incluindo a mim, passaram a revisar os códigos regularmente. Qual era a nossa motivação? Não foi porque o Greg conscientemente nos envergonhou. Ele tinha provado que revisar o código era uma maneira valiosa de gastar o tempo, e que alguém podia contribuir tanto para o projeto revisando a mudança dos demais quanto escrever novos códigos. Uma vez demonstrado, isso se tornou um comportamento esperado, ao ponto que algum commit que não gerava nenhuma reação poderia deixar o committer preocupado, e perguntar na lista se alguém teve a oportunidade de rever. Mais tarde, o Greg mudou para um emprego que não o deixava com muito tempo para o Subversion, e teve que parar com as revisões regulares. Mas nesta época, o hábito estava tão arraigado para todos nós como se fizesse parte desde de o início.

Comece a revisar desde o primeiro commit. Os tipos de problemas que são mais fáceis de encontrar revisando diferenças são vulnerabilidades de segurança, vazamento de memória, comentários ou documentação de API insuficientes, erros de índices de listas, incoerências entre chamador/receptor, e outros problemas que requerem um mínimo de conhecimento do contexto para identificar. No entanto, até mesmo problemas de larga escala como falhas ao abstrair padrões repetidos em um único local se torna identificável após a realização de algumas revisões, pois o histórico de diferenças anteriores mostra as diferenças em relação a versão atual.

Não se preocupe caso você não encontre nada para comentar, ou que você não sabe o suficiente sobre todo o código. Haverá normalmete algo a dizer sobre quase todos os commits; mesmo que você não encontre nada a questionar, você pode encontrar algo para elogiar. O que é importante é deixar claro para todo committer que o que eles fazem é visto e entendido. Claro que as revisões de código não absolvem os programadores da responsabilidade de rever e testar suas mudanças antes de realizar o commit; ninguém deve depender da revisão de código para identificar problemas que devem ser identificados por si próprio.

Se você está tornando um projeto aberto, um que já tenha desenvolvedores ativos acostumados a trabalhar em um ambiente com o código fechado, certifique-se que todo mundo entenda que uma grande mudança está por vir—e certifique-se que você entenda como será sentido do ponto de vista deles.

Tente imaginar como a situação é percebida por eles: antigamente, todas as decisões de código e designs foram feitas de outros programadores que conheciam o software mais ou menos igualmente bem, e que todos recebiam as mesmas pressões do mesmo gerenciamento, que conheciam as qualidades e fraquezas uns dos outros. Agora você está pedindo a eles que exponham seus códigos para o crivo de estranhos diversosm, que formarão julgamentos julgamentos baseados apenas no código, sem a ciência de que as pressões do negócio puderam ter forçado a certas decisões. Esses estranhos farão diversas perguntas, questões que levam os desenvolvedores existentes a perceber que a documentação que ele deram duro ainda é inadequada (isto é inevitável). Ainda por cima, os recém-chegados são entidades desconhecidas sem rosto. Se um de seus desenvolvedores já se sentia inseguro em relação as suas habilidades, imagine como isso será exarcebado quando os recém-chegados apontarem as falhas no código em que ele escreveu, e pior, fazer isso na frente dos demais colegas. A menos que você tenha um time de codificadores perfeito, isso é inevitável—na verdade, isso provavelmente ocorrerá com todos eles no início. Isso não é por que eles são mals programadores; simplesmente qualquer programa a partir de um certo tamanho tem bugs, e a revisão em pares irá mostrar alguns destes bugs (veja “Pratique uma Revisão de Código Visível” anteriormente neste capítulo). Ao mesmo tempo, os próprios recém-chegados não se submeterão muito a revisão em par no início, pois eles não podem contribuir com código até eles estarem mais familiarizados com o projeto. Para seus desenvolvedores, pode parecer que as as críticas só aumentam, nunca diminuem. Assim, há o perigo de uma mentalidade de retomar a forma que estava.

A melhor forma de prevenir isto é avisar a todos sobre o que está por vir, explicar, e dizer a eles que o desconforto inicial é perfeitamente normal, e assegurá-los que irá melhorar. Alguns destes avisos devem ser dados de maneira privada, antes que o projeto esteja aberto. Mas você pode achar de grande ajuda relembrar as pessoas nas listas públicas que esta é uma nova forma de desenvolvimento para o projeto, e que levará algum tempo para ser ajustado. A melhor atitude que você pode tomar é liderar pelo exemplo. Se você não vê seus desenvolvedores respondendo questões suficientes de novatos, ficar apenas dizendo a eles para responder mais questões não irá ajudar. Eles podem não ter ainda um bom senso do que garante ou não a resposta, ou pode ser que eles não saibam como priorizar o trabalho de codificação com uma avalanche de comunicações externas. A maneira de fazê-los participar é você mesmo participar. Faça parta da lista pública de e-mails, e certifique-se de responder algumas questões por lá. Quando você não possuir o conhecimento de alguma questão, então visivelmente deixe-a nas mãos de um desenvolvedor que o tenha— e observe para ter certeza que ele retornará com uma explicação ou ao menos uma resposta. Naturalmente será tentador para os desenvolvedores mais antigos cair em discussões privadas, como eles já eram habituados. Esteja inscrito na lista de e-mails internos onde isso possa acontecer, desta forma você poderá pedir que tais discussões sejam levadas para as listas públicas imediatamente.

Existem outras preocupações a longo prazo com a abertura de um projeto inicialmente fechado. O Capítulo 4, Social and Political Infrastructure explora técnicas para unir com sucesso desenvolvedores pagos com não-pagos, e o Capítulo 9, Licenses, Copyrights, and Patents discute a necessidade de uma diligência legal ao abrir um código que pode conter sofware escrito ou de "propriedade" de terceiros.