julho 23rd, 2010 by cochise

Continuando com a série sobre o desenvolvimento comunitário de jogos, vou entrar em mais detalhes sobre os modelos de gestão de grupos, um modelo por post. O primeiro é o do déspota benevolente.

Este modelo é, até onde eu sei, o mais usado pelas empresas que produzem RPGs de qualidade “profissional”. Existe um designer da linha que é a pessoa com o dele na reta que em última instância toma as decisões. Esta é a essência deste modelo. Uma pessoa que tem a responsabilidade e o poder em última instância de alterar, vetar ou colocar coisas.

Vários projetos de software livre funcionam assim, como por exemplo o kernel Linux, cujo déspota é o próprio Linus Torvalds e a linguagem de programação Python, cujo déspota é van Rossum. A primeira vista é complicado entender porque alguém iria contribuir com um projeto que está nas mãos de um terceiro que toma sozinho as decisões. No entanto como tudo na vida a situação é um pouco mais complicada.

O déspota do projeto tem uma grande responsabilidade sobre ele e é a pessoa que tem a obrigação de conhecer todo ele. No mundo da programação estas pessoas são conhecidas como “code guru”. Para exemplificar, o kernel Linux tem mais de dez milhões de linhas de código. Poucas pessoas conseguem ter uma visão geral sobre ele e menos ainda entender bem como cada parte se relaciona com as outras. Em projetos complexos como o kernel Linux, Forgotten Realms, Vampiro a Máscara, Dragonlance ou Ao Cair da Noite é preciso que haja pelo menos um “code guru” que entenda completamente o conjunto, e a partir dessa compreensão que só ele tem assuma a responsabilidade de permitir ou não alterações.

O déspota precisa ter além dessa compreensão sobrenatural do conjunto uma visão muito clara dos objetivos do projeto, de modo que o conjunto de pequenas contribuições não o afaste desse objetivo o invés de aproximar.

Exatamente por estes motivos as empresas gostam desse modelo. Porque existe alguém responsável que pode ser facilmente identificado e porque facilita o planejamento de longo prazo. No caso das empresas a maioria (ou todas) das “contribuições” é feita por escritores pagos, então é uma situação fácil de ser gerenciada. No caso de comunidades abertas e voluntárias tudo fica mais difícil.

Para começo de conversa é necessário que haja uma relação de confiança entre os colaboradores e o déspota. Que eles percebam que essa é uma posição de responsabilidade  que via um futuro melhor para todos. Sem isso, as pessoas simplesmente não irão contribuir.

Em segundo lugar é preciso que as pessoas não se sintam usadas no sentido financeiro da palavra. RPG tende a gerar produtos comenrcializáveis. Todos nós somos muito suscetíveis diante da ideia de trabalhar de graça para alguém.

Por fim, em projetos comunitários é preciso haver discussão e opiniões voando para todos os lados. Não é porque a decisão e a responsabilidade final ficam nas mãos de uma pessoa que as outras não podem opinar. No mundo do software livre as propostas ficam em uma “lista de espera, onde são debatidas por toda a comunidade e só depois de um período de discussão o déspota decide. Sua decisão não é completamente solitária, mas embasada pela discussão de toda a comunidade.

Este modelo de tomada de decisões costuma funcionar melhor para projetos grandes e complexos que para pequenos. Isso tem a ver com a necessidade de um déspota e com o ego os seres humanos.

Nas próximas partes da série teremos o “conselho” e o “bazar”.