Ajustando o Tom

Até agora nós cobrimos as tarefas que são feitas uma só vez durante a configuração do projeto: escolher uma licença, organizar o web site inicial, etc. Mas os aspectos mais importantes ao iniciar um novo projeto é a dinâmica. Escolher um endereço para lista de e-mails é fácil; garantir que as conversas sejam sobre o tema e produtivas é completamente outro assunto. Se o projeto está sendo aberto após anos de desenvolvimento interno e fechado, seu processo de desenvolvimento irá mudar, e você terá que preparar os desenvolvedores existentes para esta mudança.

Os primeiros passos são os mais difíceis, pois os precedentes e expectativas para condução futura ainda não foram definidos. Estabilidade no projeto não vem de políticas formais, mas de uma sabedoria compartilhada e difícil de definir que se cria com o tempo. Existem geralmente regras escritas também, mas elas tendem a ser essencialmente uma destilação dos acordos intangíveis que sempre evoluem que realmente guiam o projeto. As políticas escritas não definem a cultura do projeto tanto quanto o descreve, e mesmo assim aproximadamente apenas.

Existem algumas razões de porque as coisas funcionam desta forma. Crescimento e alta rotatividade não são tão prejudiciais para o acumulo de normas sociais quanto alguns podem pensar. Enquanto a mundança não acontece muito rapidamente, há tempo para que os recém-chegados aprendam como tudo funciona, e após eles aprenderem, eles mesmos irão reforçar o processo. Considere como as músicas infantis sobrevivem por séculos. Existem crianças hoje cantando mais ou memos as mesmas rimas assim como as crianças faziam centenas de anos atrás, mesmo que não haja crianças viva agora que estavam vivas na época. Crianças mais novas ouvem as canções cantadas por mais velhos, e quando elas crescem, voltarão a cantá-las para as mais novas. É claro que as crianças não estão se engajando em um programa consciente de transmissão, mas a razão da música sobreviver é todavia que elas são transmitidas regular e repetidamente. A escala de tempo de projetos de software livre pode não ser medida em séculos (não sabemos ainda), mas as dinâmicas da transmissão são muito similares. A taxa de rotatividade é entretanto mais rápida, e precisa ser compensada por um esforço mais ativo e deliberado da transmissão.

Este esforço é mantido pelo fato das pessoas geralmente aparecem esperando e procurando por normas sociais. Isto é apenas como os humanos são feitos. Em todo grupo unificado por um objetivo comum, as pessoas irão instintivamente procurar por comportamentos que as marquem como parte do grupo. O objetivo de estabelecer precedentes previamente é fazer que estes comportamentos "do grupo" sejam úteis para o projeto; uma vez estabelecidos, eles serão em grande parte auto-perpetuados.

A seguir estão alguns exemplos de coisas específicas que você pode fazer para ajustar bons precedentes. Eles não representam uma lista exaustiva, apenas uma ilustração da idéia que ajustar um espírito colaborativo logo cedo ajuda tremendamento um projeto. Fisicamente, cada desenvolvedor pode estar trabalhando sozinho em uma sala, mas você pode fazer muito para que eles possam sentir como se eles estivessem trabalhando juntos na mesma sala. Quanto mais eles se sintam assim, mais eles irão querer trabalhar no projeto. Eu escolhi estes exemplos em particular porque eles aconteceram no projeto do Subversion ( (http://subversion.tigris.org/), o qual eu participei e observei desde o início. Mas eles não são únicos ao Suversion; situações como essas irão surgir na maioria dos projetos de código aberto, e deveriam ser vistas como oportunidades para começar tudo com o pé direito.

Evite Discussões fechadas

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:

  • A discussão irá ajudar a treinar e educar novos desenvolvedores. Você nunca sabe quantos olhos estão acompanhando a conversação; mesmo que a maioria não participe, muitos podem estar acompanhando silenciosamente, colhendo informações sobre o software.

  • A discussão treinará você na arte de explicar problemas técnicos para pessoas que não estão tão familiares com o software quanto você está. Esta é uma habilidade que requer prática, e você não obtém esta prática falando com pessoas que já sabem o que você sabe.

  • A discussão e suas conclusões estarão disponíveis em arquivos públicos para sempre, permitindo que futuras discussões evitem seguir os mesmos passos. Veja “Conspicuous Use of Archives” no Capítulo 6, Communications.

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.

Corte o Mal pela Raiz

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:

Primeiro, vamos por favor parar com os comentários (potencialmente) mal-educados; por exemplo, chamar o design para a camada de segurança do João de "inexperiente e ignorante dos princípios básicos de segurança do computador." Isto pode ou não ser verdade, mas em qualquer um dos casos não há motivos para este tipo de discussão. João fez sua proposta de boa fé. Se há nela deficiências, aponte-as, e iremos corrigí-las ou encontrar um novo design. Eu tenho certeza que o Mário não quis insultar João de maneira pessoal, mas a frase foi um deslize, e iremos tentar manter as coisas de maneira construtiva por aqui.

Agora, sobre a proposta. Acredito que Mário esteja certo ao dizer que...

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.

Pratique uma Revisão de Código Visível

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.

Ao Abrir um Projeto Anteriormente Fechado, Seja Sensível a Magnitude da Mudança

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.



[12] Nós não entramos na seção dos créditos ainda, mas apenas para praticar o que pregarei mais tarde: o nome do observador era Brian Behlendorf, e foi ele que mostrou a importancia de manter todas as discussões públicas a menas que haja uma necessidade específica para privacidade.

[13] Assim é como a revisão de código geralmente é realizada em projetos de código aberto, de qualquer tamanho. Em projetos mais centralizados, a "revisão de código" pode também significar diversas pessoas que sentam juntas e com impressões de código fonte, buscam problemas e padrões específicos.