É plenamente possível ter projetos de software livre cujo processo de desenvolvimento é fechado. O produto é lançado sob uma licença livre, mas os seus desenvolvedores atuam de forma isolada e sem estimular ou mesmo aceitar a participação de quem é "de fora".

E este artigo do Linux.com analisa dois destes casos, que ocorrem em projetos associados a grupos maiores e tradicionalmente abertos à participação da comunidade: o KDE e o Gimp - cujos processos permanecem tão abertos quanto antes.

O primeiro dos projetos analisados é o do projeto Oxygen, descrito como um redesign de ícones em andamento para inclusão no KDE 4. O caso narrado é um pouco menos comum: embora os ícones do projeto estejam disponíveis via licença livre (LGPL) e acessíveis via repositório Subversion público, integrantes do projeto protestaram quando versões correntes do material foram incluídas em um tema para o GNOME por alguém de fora do projeto, antes que eles lançassem a versão definitiva de seu trabalho.

Os desenvolvedores defendem o direito de não ver outros distribuírem seu material antes que eles mesmos lancem a "versão 1.0" seus produtos - mas isto é algo que as licenças livres não oferecem, e o próprio modo de produção aberto não prevê. Pelo contrário, a máxima "release early, release often" estimula o desenvolvedor a abrir mão deste nível de controle bastante cedo no ciclo de desenvolvimento, e é comum vermos forks e derivados de projetos livres que ainda não atingiram uma versão 1.0. No contexto artístico talvez os pontos de vista sejam diferentes, mas se for o caso, a licença livre deve prevalecer, ou ser explicitamente abandonada em trabalhos futuros dos autores que delas discordarem.

O segundo caso analisado é o Gimp UI Redesign, que estuda novidades para o futuro da interface gráfica adotada pelo Gimp. Neste caso, a situação que ocorre é mais comum: a equipe é fechada, e voluntários que procuram passar a integrá-la relatam que são rejeitados. Vários projetos abertos operam desta forma, com equipes definidas e sem mecanismos para a participação direta (e não apenas enviando sugestões) de quem não seja da equipe, mas o autor do artigo se posiciona contra esta prática, dizendo que "se você tem medo de abertura, veio ao lugar errado".

Ao final, o artigo contrasta o posicionamento do Oxygen com o do Tango, que segundo ele é muito mais aberto, e compara também a forma de agir do Gimp UI Redesign com a do projeto Gimp em si, que ele caracteriza como aberto à participação de todos.

E prega que a abertura à participação de todos torna a equipe mais forte, e não mais fraca. Vale a reflexão.

Saiba mais (linux.com).