Índice
A primeira pergunta que as pessoas fazem sobre o software livre é "Como funciona? O que é que move um projecto? Quem toma decisões?" Fico sempre insatisfeito com respostas prontas sobre meritocracia, o espírito de cooperação, o código falar por si mesmo, etc. O facto é que a questão não tem resposta fácil. A meritocracia, a cooperação e a execução de código fazem parte da resposta, mas não explicam como é que os projectos são geridos no dia-a-dia e nada dizem sobre como são resolvidos os conflitos.
Este capítulo tenta mostrar as fundações estruturais que os projectos bem sucedidos têm em comum. Digo "bem sucedidos" não só em termos de qualidade técnica, mas também saúde operacional e sobrevivência. Saúde operacional é a capacidade sustentada de um projecto incorporar novas contribuições de código e novos programadores e ter capacidade de resposta aos relatórios de erros que entrem. Capacidade de sobrevivência é a capacidade de um projecto existir independentemente de qualquer participante individual ou sponsor; pense nisto como a probabilidade do projecto continuar mesmo que todos os seus membros fundadores se mudarem para outras coisas. O sucesso técnico não é difícil de alcançar, mas sem uma base de programadores e uma fundação social robustas, um projecto pode ser incapaz de tratar o crescimento que esse sucesso inicial trás ou a partida de indivíduos carismáticos.
Há várias maneiras de alcançar este tipo de sucesso. Algumas envolvem uma estrutura de governo formal, pela qual os debates são resolvidos, os novos programadores são admitidos (e por vezes excluídos), novas características são planeadas e assim sucessivamente. Outras envolvem uma estrutura menos formal, mas maior auto-controlo, para produzir uma atmosfera de justiça em que as pessoas possam confiar como uma forma de governação de facto. Ambos os caminhos levam ao mesmo resultado, perenidade institucional, suportada por hábitos e procedimentos bem compreendidos por todos os participantes. Estas características são ainda mais importantes em sistemas auto-organizados do que em sistemas controlados centralmente, porque em sistemas auto-organizados todos têm consciência que algumas maças podres podem estragar toda a caixa, pelo menos durante algum tempo.
O ingrediente indispensável que serve de argamassa a que os programadores se mantenham unidos num projecto de software livre e os leva a estarem disponíveis para o compromisso quando necessário é a bifurcabilidade: a capacidade de qualquer pessoa a partir de uma cópia do código fonte e usando-o como base começar um projecto concorrente, conhecido como bifurcação. A coisa paradoxal é que é esta possibilidade de bifurcações é normalmente uma força muito maior nos projectos de software livre que as próprias bifurcações, as quais são muito raras. Porque uma bifurcação é má para toda a gente (por razões explicadas em detalhe em “Forks” em Capítulo 8, Managing Volunteers), quanto mais séria uma ameaça de ramificação fica, mais as pessoas estão dispostas a efectuar um compromisso para a evitar.
As bifurcações, ou o potencial para o seu surgimento melhor dizendo, é a razão pela qual nos projectos de software livre não há verdadeiros ditadores. Pode parecer uma afirmação surpreendente, tendo em conta a frequência com que se ouve falar de "ditador" ou de "tirano" num dado projecto de «open source». Mas este tipo de tirania é especial, muito diferente do significado convencional da palavra. Imagine um rei cujos súbditos possam copiar o seu reino completo a qualquer momento e possam mudar para a cópia para governarem como acharem mais apropriado. Esse rei não governaria de modo completamente diferente daquele ao qual os subditos estão sob tutela independentemente do que ele faça?
É por esta razão que projectos que não têm uma organização formal como democracias são, na prática, democracias quando se chega ao momento de tomar decisões importantes. A replicabilidade implica a bifurcabilidade; a bifurcabilidade implica o consenso. É perfeitamente possível que se deseje atribuir a um líder (o exemplo mais famoso é o de Linus Torvalds no desenvolvimento do cerne do Linux), mas isso foi porque assim o escolheram, de uma maneira não cínica e não sinistra. O ditador não tem uma mão mágica sobre o projecto. A propriedade chave de todas as licenças de «open source» é não darem a ninguém mais poder do que a qualquer outra entidade na decisão de como o código pode ser alterado ou usado. Se o ditador começar de repente a tomar decisões más, haverá uma paragem de actividade, seguida eventualmente de uma revolta e uma ramificação. Claro que isto normalmente não chega tão longe porque o ditador faz um compromisso antes.
Mas só porque a bifurcabilidade coloca um limite máximo no poder que uma pessoa pode exercer num projecto não quer com isto dizer que não haja importantes diferenças em como os projectos sejam governados. Não quer que cada decisão venha até à pergunta extrema de quem está a pensar num ramo. Isso seria cansativo muito rapidamente, retirando energia do trabalho propriamente dito. As duas secções seguintes examinam maneiras diferentes de organizar projectos de tal modo que a maior parte das decisões sejam adoptaram sem guerra. Estes dois exemplos são de algum modo extremos ideais; vários projectos caiem no continuo entre ambos.
O modelo ditador benevolente é exactamente aquilo que parece: a autoridade final de tomada de decisão fica com essa pessoa, que, por virtude da sua personalidade e experiência, se espera que faça um uso sábio da mesma.
Embora "ditador benevolente" (ou abreviadamente BD) seja o termo normalmente usado para este papel, seria melhor pensar nele como "árbitro aprovador pela comunidade" ou "juiz". Geralmente os ditadores benevolentes não tomam de facto todas as decisões ou mesmo a maior parte. É improvável que essa pessoa possa ter a perícia suficiente para consistentemente tomar boas decisões em todas as áreas de um projecto, e de qualquer modo, os programadores de qualidade não ficam excepto se tiverem alguma influência na direcção do projecto. Assim os ditadores benevolentes normalmente não ditam muito. Em vez disso deixam as coisas funcionar por si através de discussão e experimentação sempre que possível. Participam nessas discussões eles próprios, mas como programadores normais, normalmente delegando numa pessoa da área da manutenção que tenha mais conhecimento. Só quando é claro que não se está a alcançar consenso e a maior parte do grupo quer alguém que guie a decisão de modo a poder prosseguir." A relutância em tomar decisões por decreto é um traço partilhado virtualmente por todos os ditadores benevolentes bem sucedidos. É uma das razões porque conseguem manter esse papel.
Ser um BD exige uma combinação de traços. Necessita, primeiro que tudo, uma sensibilidade grande sobre a sua própria influência no projecto, que por outro lado trás auto-controlo. Nos primeiros estadios de uma discussão, não deve exprimir opiniões e conclusões para evitar que os outros achem inútil efectuarem dissidências. As pessoas têm que ser livres de se exprimirem, mesmo ideias estúpidas. É inevitável que o próprio BD exprime de tempos a tempos uma ideia estúpida também e, é claro, o papel exige também a capacidade de reconhecer quando se toma uma má decisão; embora isto seja um simples traço que qualquer bom programador deva ter, em especial se se mantiver no projecto a longo prazo.A grande diferença é que o BD pode de vez em quando cometer asneiras sem se preocupar com a perca de credibilidade. Programadores menos seniores podem não se sentir tão seguros e portanto o BD deve usar fraseologia cuidadosa nas critícas ou decisões contrárias sopesando as palavras tanto tecnicamente como psicologicamente.
O BD não necessita de ter as capacidades técnicas afiadas de qualquer pessoa no projecto. Deve ter as capacidades suficientes para trabalhar no código, mas é tudo. A posição de BD não é adquirida em virtude das capacidades de codificação intimidatórias. O que é importante é experiência e sentido de concepção geral, não necessariamente capacidade de produzir boa concepção a pedido, mas a capacidade de reconhecer uma boa concepção independentemente da sua origem.
É comum o ditador benevolente ser o fundador do projecto, mas isto é mais uma correlação do que uma cusa. Todos o tipos de qualidades que tornam uma pessoa capaz de ser bem sucedida no início de um projecto, — competência técnica, capacidade de persuadir outras pessoas a juntarem-se, etc — são exactamente as capacidades que qualquer BD necessitaria. E claro os fundadores começam logo com uma espécie de senioridade automática, que pode ser suficiente para tornar a ditadura parecer o caminha da menor resistência para todos aqueles a que diga respeito.
Lembrar que o potencial de bifurcação dá para os dois lados. Um BD pode bifurcar um projecto como qualquer outra pessoa e alguns fizeram-no ocasionalmente, quando acharam que a direcção que queriam tomar para o projecto era diferente da da maioria dos outros programadores. Devido à bifurcabilidade não importa se o ditador benevolente é root (tem privilégios de administração) nos servidores principais do projecto ou não. As pessoas falam por vezes do controlo do servidor como se fosse a última fonte de poder num projecto quando tal é irrelevante. A capacidade de adicionar ou remover as palavras de passe das pessoas num determinado servidor afecta só a cópia do projecto aí residente. Um abuso prolongado do poder, pelo BD ou por outra pessoa, simplesmente levaria a que o desenvolvimento passasse para outro servidor.
Se o seu projecto deve ter um ditador benevolente ou se seria melhor gerido com um sistema menos centralizado depende largamente em quem está disponível para preencher os papeis. Como regra geral se é simplesmente óbvio quem deva ser o BD então esse é o caminho a seguir. Mas se não houver um candidato imediatamente óbvio, então o projecto deve ter um processo de tomada de decisão descentralizados, como o descrito na próxima secção.