A organização de uma equipe de desenvolvimento de software livre ocorre de maneira bastante incremental e colaborativa, inicialmente de modo informal, mas que pode chegar a englobar uma estrutura bastante complexa dependendo da evolução do projeto.
O processo de desenvolvimento do software livre facilita a troca de experiências entre desenvolvedores, a evolução constante dos produtos e o intercâmbio de conhecimento entre os pares.
Apesar da imagem aparente de liberdade total e de um comprometimento parcial, não existe liberdade total no desenvolvimento. A organização do trabalho é extremamente importante, existindo hierarquia e delegação de responsabilidade.
A coordenação do trabalho dos membros da comunidade é utilizada ferramentas simples por meio da Internet, como: correio eletrônico, listas de discussão, controle de versão e acompanhamento de defeitos.
Segundo Arakaki e Turine (2005), as pessoas evolvidas em projetos de Software Livre podem ter sua participação classificada pelo tipo de papel que exercem:
• Usuários não-participantes: sem interesse em discutir ou ajudar no desenvolvimento do
software. É nesta classe que se enquadram a maioria das pessoas. Por exemplo, fazem teste funcional do software, mas em geral não informam os erros encontrados;
• Usuários participantes: são os que ativamente contribuem para o projeto informando os
problemas e discutindo as funcionalidades. Responsáveis por boa parte do teste funcionam provendo feedback para os autores em relação aos erros e inconsistências;
• Desenvolvedores esporádicos: usuários com conhecimento de programação e disposição
para alterar código-fonte e produzir alterações. Normalmente essas alterações são de caráter localizado, reparando um pequeno defeito ou implementando uma pequena extensão em nível de funcionalidades;
• Desenvolvedores ativos: têm responsabilidade por módulos do código-fonte ou por
implementar funcionalidade mais extensa ou mais complexa. Entre estes está o mantenedor central.
Tanto os desenvolvedores esporádicos como ativos participam também ativamente nas discussões, fazendo suporte ao usuário, e discutindo modificações com outros desenvolvedores sobre questões de projeto e implementação. Em projetos de dimensão um pouco maior existem listas e canais separados para discussão relacionada especificamente ao desenvolvimento. Desta forma, ficam mais isoladas as discussões entre usuários finais, que geralmente não estão interessados nas questões mais técnicas associadas ao desenvolvimento de software (REIS, 2003).
Estes membros da comunidade possuem uma cultura altamente racional, onde todas as suas ações são decididas metodicamente através de raciocínio lógico e justificativas tecnológicas. (YAMAUCHI, Y. et al., 2000).
Na grande maioria dos projetos cabe ao fundador da comunidade ou idealizador o papel de coordenação inicial do projeto, definindo as atribuições de cada um dos integrantes. Quanto maior a contribuição de um desenvolvedor da equipe, maior será sua reputação.
Com isso, no andamento normal e o eventual crescimento da equipe, surge então um conceito bastante singular presente na hierarquia do desenvolvimento de software livre: a meritocracia.
Neste conceito, a posição social/hierárquica de uma pessoa é determinada pela sua capacidade intelectual e esforço (YOUNG, 1958). As posições hierárquicas são conquistadas, em tese, com base no merecimento, e havendo uma predominância de valores associados à educação e à competência.
O grande problema do mérito do conhecimento técnico como mecanismo de distinção entre os membros num projeto de software livre é que os colaboradores mais avançados, visando manter o seu status quo perante a comunidade, muitas vezes acabam por dificultar a difusão de conhecimento com os novos membros (menos experientes). Nesse sentido observa-se um mecanismo de controle (FOUCAULT; MACHADO, 2004) que se imprime sobre os que não estão completamente inseridos no contexto da comunidade.
2.8.1 Hierarquia
Para fornecer uma visão hierárquica de maior organização de uma comunidade de software livre, Arakaki (2005), classifica em privilégios e níveis de poder os papéis exercidos pelos membros. Como parâmetros de referência para definir o nível em que cada papel se encontra na hierarquia de uma comunidade de software livre utilizamos: o poder de tomada de decisão e o acesso aos recursos do projeto (Tabela 3).
O poder de tomada de decisão indica quais participantes têm a competência de definir os rumos do projeto (competência de gerenciar na prática o projeto), para fornecer ou retirar responsabilidades a outros membros da comunidade.
A questão do acesso aos recursos é definida pela capacidade que os participantes possuem maiores ou menores privilégios de acesso aos recursos para o desenvolvimento. Estes recursos são: sistemas de gerência de configuração, sistemas de rastreamento e acompanhamento e gestão das mudanças.
A tabela abaixo resume s privilégios e poderes de decisão, em relação ao projeto, de cada nível hierárquico citado anteriormente:
Tabela 3: Hierarquia de Privilégios e Poderes de Decisão dentro de um Projeto de Software Livre
Nível Privilégios Poder
1 Todos Todos
administração nas listas de discussão, acesso de escrita aos arquivos da página do projeto, uso da ferramenta de rastreamento / acompanhamento de mudanças para envio de correções de bugs e modificação do estado da correção, acesso às ferramentas de geração de pacotes de versões, realização de construções do projeto no repositório principal do projetos
contribuições serão integradas ao código do projeto, definição de acesso de escrita aos recursos do projeto (repositório, página, entre outros), decisões de aspectos técnicos para evolução do projeto e participação de decisões junto à liderança do projeto.
3 Acesso total ao repositório de dados do projeto, postagem de mensagens nas listas, acesso de escrita aos arquivos da página do projeto, uso da ferramenta de rastreamento e acompanhamento de mudanças para envio de correções de bugs e modificação do estado da correção
Participar de votações (dependendo da forma de organização da comunidade) para definir prioridades no projeto (roadmaps)
4 Acesso de leitura ao repositório de dados do projeto, envio de mensagens nas listas, uso da ferramenta de rastreamento e acompanhamento de mudanças para envio de correções de bugs e modificação do estado da correção
Nenhum
5 Acesso de leitura ao repositório de dados do projeto, envio de mensagens nas listas de discussão, uso da ferramenta de rastreamento e acompanhamento de mudanças para envio de eventuais bugs
Nenhum
6 Acesso de leitura ao repositório de dados do projeto, envio de mensagens nas lista de discussão
Nenhum
7 Acesso de leitura ao repositório de dados do projeto (documentos públicos)
Nenhum Fonte: Arakaki, 2005.
Na figura seguinte (Figura 8), apresentam-se os diversos participantes com seus devidos papéis dentro da comunidade: Quanto menor o nível em que o papel se encontra, maior o poder do indivíduo (ARAKAKI, 2005).
Figura 8: Papel dos Membros X Nível Hierárquico Fonte: Arakaki, 2005
O aspecto fundamental da hierarquia do papel dos membros da comunidade é que qualquer membro de um nível superior da hierarquia pode executar funções referentes a membros de nível inferior. Entretanto, a recíproca da execução das funções não é verdadeira.
Portanto, um membro de líder de módulo pode sugerir modificações, bem como ele mesmo implementá-las sem perder seus privilégios. O membro estará apenas executando uma função que é de responsabilidade de um outro papel. Por outro lado, os membros de nível inferior
não têm privilégios além daqueles rígidos pré-definidos para ele dentro de seu mérito dentro do projeto.