Se for um programador pago no projecto então estabeleça as regras daquilo que o dinheiro pode ou não comprar. Isto não significa que tenha que escrever duas vezes por dia para as listas de distribuição de correio reiterando a sua natureza nobre e incorruptível. Isto só quer dizer que deve estar atento a oportunidades onde possa reduzir tensões que possam ser geradas pelo dinheiro. Não necessita de começar presumir que as tensões já existam por aí; necessita, isso sim, de demonstrar que tem consciência de elas poderem potencialmente ecludir.

Um exemplo perfeito surgiu no projecto Subversion. O projecto Subversion foi iniciado em 2000 pela CollabNet, que tem sido o principal financiador do projecto desde o seu início, pagando os salários de vários programadores (nota: sou um deles). Pouco tempo após o início do projecto, contratamos outro programador, Mike Pilato, to join the several developers (disclaimer: I'm one of them). Soon after the effort. By then, coding had already started. Although Subversion was still very much in the early stages, it already had a development community with a set of basic ground rules.

Mike's arrival raised an interesting question. Subversion already had a policy about how a new developer gets commit access. First, he submits some patches to the development mailing list. After enough patches have gone by for the other committers to see that the new contributor knows what he's doing, someone proposes that he just commit directly (that proposal is private, as described in “Committers”). Assuming the committers agree, one of them mails the new developer and offers him direct commit access to the project's repository.

CollabNet had hired Mike specifically to work on Subversion. Among those who already knew him, there was no doubt about his coding skills or his readiness to work on the project. Furthermore, the volunteer developers had a very good relationship with the CollabNet employees, and most likely would not have objected if we'd just given Mike commit access the day he was hired. But we knew we'd be setting a precedent. If we granted Mike commit access by fiat, we'd be saying that CollabNet had the right to ignore project guidelines, simply because it was the primary funder. While the damage from this would not necessarily be immediately apparent, it would gradually result in the non-salaried developers feeling disenfranchised. Other people have to earn their commit access—CollabNet just buys it.

So Mike agreed to start out his employment at CollabNet like any other volunteer developer, without commit access. He sent patches to the public mailing list, where they could be, and were, reviewed by everyone. We also said on the list that we were doing things this way deliberately, so there could be no missing the point. After a couple of weeks of solid activity by Mike, someone (I can't remember if it was a CollabNet developer or not) proposed him for commit access, and he was accepted, as we knew he would be.

Este tipo de consistência dá-lhe uma credibilidade que o dinheiro nunca conseguirá comprar. E credibilidade é uma moeda valiosa a ter em discussões técnicas: é uma imunização contra ver serem questionadas as motivações em discussões técnicas mais tarde. No calor da argumentação, por vezes, as pessoas vêm maneiras não técnicas de ganhar a batalha. O financiador principal do projecto devido aos seu profundo envolvimento e preocupação óbvia quanto à orientação que o projecto toma, apresenta um flanco maior que a maior parte. Sendo escrupuloso na observação de todas as directrizes do projecto desde o início, o financiador apresentará um flanco do mesmo tamanho que os restantes participantes.

(Ver ainda o blogue de Danese Cooper em http://blogs.sun.com/roller/page/DaneseCooper/20040916 para uma história similar sobre acesso ao commit. Cooper era a "Open Source Diva" — da Sun Microsystems julgo que era essa a sua designação oficial — e nessa entrada no blogue, descreve como a comunidade de desenvolvimento levou a Sun a aplicar aos seus programadores os mesmos padrões de acesso a commit que os dos programadores não-Sun.)

A necessiade dos financiadores jogarem pelas mesmas regras que todo o mundo significa que será mais difícil aplicar o modelo de governo do Ditador Benevolente (ver “Ditador Benevolente” em Capítulo 4, Infra-estrutura Social e Política) na presença de financiamento, particulamente se o ditador trabalhar para o financiador principal. Visto a ditadura ter poucas gregas, é mais difícil ao financiador provar que está a cumprir as normas da comunidade, mesmo quando está. Certamente não é impossível. Só exige um líder de projecto que seja capaz de ver as coisas do ponto de vista dos programadores externos, assim como o do financiador e agir em conformidade. Mesmo assim é provavelmente boa ideia ter uma proposta para um governo não ditaturial à espera no bolso de trás, pronto a ser puxado no momento em que haja indicativos de insatizfação generalizada na comunidade.