César Taurion, um dos executivos da IBM publicou o seguinte texto:
(fonte: IBM)
Outro dia participei de um debate sobre Open Source, onde um dos principais temas debatidos foi o modelo de desenvolvimento. Acho que vale a pena compartilharmos algumas idéias… Existem dois métodos básicos de desenvolvimento de software: os princípios catedral e bazar. Estes nomes foram cunhados a partir do célebre trabalho “The Cathedral and the Bazaar” de Eric Raymond. O método batizado de catedral é baseado no planejamento centralizado, com evolução top-down e rígido relacionamento entre a gerencia e os desenvolvedores, quanto a prazos, metodologias adotadas e tarefas, dentro de uma hierarquia organizacional. O desenvolvimento é interno à empresa e apenas nos ciclos de teste alfa e beta é que o produto é exposto ao mercado, através de uma restrita e controlada comunidade de usuários (individuais ou empresas clientes) que se prontificam a cooperar nos testes e depurações. Mas todo o código fonte é proprietário e fechado ao mundo externo e restrito apenas aos olhos dos desenvolvedores da empresa que produz o software. É o método tradicionalmente adotado pela indústria de software em seus produtos comerciais.
O princípio bazar, como o nome indica, é baseado em uma forma mais livre e colaborativa de desenvolvimento, sem centralização do seu planejamento e execução. É o modelo típico Open Source. O desenvolvimento é efetuado em rede, por uma comunidade de desenvolvedores voluntários, sem vínculos entre si, em uma organização virtual e informal. A comunicação é efetuada pela Web, sem fronteiras geográficas e existem apenas alguns princípios que regulam o trabalho. A liderança do projeto não é definida de maneira prévia e formal, mas emerge naturalmente pelos méritos de um determinado membro da comunidade.
Os códigos são revisados pelos próprios pares (peer review) e geralmente o melhor código é selecionado (meritocracia). Como não existe um departamento de marketing nem acionistas influenciando prazos, o ritmo de desenvolvimento é direcionado pela disponibilidade de tempo e dedicação dos desenvolvedores. O método bazar gera uma forte tendência de gerar código de alta qualidade. O código é lido e analisado por diversos, as vezes centenas, de desenvolvedores, o que acelera o processo de depuração e correção de erros. A decisão de liberar o código é fruto de consenso do grupo e não uma imposição de marketing, como muitas vezes ocorre em um projeto comercial.
Geralmente é necessário a figura de um líder ou mantenedor, que se encarrega de coordenar as mudanças e decidir (muitas vezes em colegiado) quando o produto pode ser liberado. Os ciclos de teste e revisões são constantes e o feedback é contínuo. Todos, a qualquer momento, podem interceder e comentar sobre o código, uma vez que este é livre e disponível a todos.
Os princípios de desenvolvimento em comunidade ainda não são totalmente conhecidos. Apenas nos últimos anos é que os primeiros estudos comportamentais de como a comunidade desenvolve software, gerencia e cobra tarefas, e como os contextos organizacionais são desenvolvidos é que começaram a ser desenvolvidos.
Mas já sabemos de algumas coisas. Uma é a importância do mecanismo de controle dos projetos. Ao contrário do modelo hierárquico, com rígidas normas de controle e subordinação, o modelo colaborativo tem outras características, algumas positivas e outras extremamente desafiadoras. Em um projeto fechado, típico de softwares proprietários, uma equipe de desenvolvedores profissionais são alocados a tarefas de acordo com suas especializações e gerenciados quanto ao cumprimento de prazos e orçamentos. No projeto de Open Source, a equipe é virtual, interage pela Internet (email, newsgroups, wikis, etc) e não existe subordinação direta. A participação dos desenvolvedores no projeto é voluntária e portanto não está submetida aos padrões de gerenciamento típicos dos projetos fechados.
Este modelo gera algumas incertezas, advindas do próprio modelo de contribuição voluntária. Como não existe uma rígida subordinação ou contrato empregatício, os colaboradores podem variar em muito de intensidade em suas colaborações. Podem contribuir intensamente como podem, sem prévio aviso, desaquecerem em suas colaborações. Não existem planejamentos de produção e medidas de produtividade tipo “colaboradores estarão desenvolvendo quantas linhas de código por determinada unidade de tempo”. Também não existem divisões formais de trabalho, com prévia alocação de desenvolvedores à determinadas tarefas.
Para contrabalançar estas incertezas, alguns mecanismos de governança são adotados nos projetos de Open Source. Embora não exista hierarquia rígida, acaba-se criando um modelo de hierarquia informal, com o mantenedor e alguns membros assumindo posição de liderança e gestão do projeto. Cria-se um mecanismo de gestão centralizada, onde um grupo pequeno de colaboradores assume um papel executivo, responsabilizando-se pelas decisões e rumos do projeto. Esta organização é criada informalmente, impulsionada pela própria necessidade de existir uma estrutura razoavelmente estável, que oriente e direcione os esforços do restante da comunidade. Entretanto, ao contrário de projetos tradicionais, este papel não é assumido por escrito ou por posição hierárquica em uma empresa, mas por reputação ou conquista de espaço.
Na prática, acaba sendo criado um sistema hierárquico informal, baseado na meritocracia, com os desenvolvedores mais atuantes e experientes desenvolvendo as tarefas mais avançadas (codificação de novas funcionalidades e melhorias de desempenho) e os colaboradores menos experientes assumindo tarefas mais simples, como depuração de código.
Uma outra questão, inerente ao modelo colaborativo é o processo de seleção da codificação a ser inserida no projeto. Os colaboradores contribuem com seus códigos, e estes precisam passar por mecanismos de filtragem para serem aceitos e incorporados ao corpo do software. Não existem regras únicas. Os mecanismos podem variar de decisões autocráticas a sistemas de votação, sendo estes também variando de abrangentes (todos interessados podem votar) a votos restritos a um comitê selecionado de colaboradores.
O modelo colaborativo exige também mecanismos eficientes de controle de versões. Como a contribuição de novos códigos é livre, é necessário que o mantenedor gerencie cuidadosamente que pedaços de código deverão ou não ser incorporados ao software e decida quando o volume de modificações for suficiente para que seja liberada uma nova versão.
Outro aspecto importante é que os projetos de Open Source devem ser modulares para permitir o trabalho de muitos colaboradores simultaneamente.
O método colaborativo quebra o tradicional paradigma criado por Fred Brooks em seu famoso livro “The Mytical Man-Month” onde ele observava que adicionar mais programadores a um projeto em atraso simplesmente aumentaria este atraso. Um programador em 12 meses não é igual a 12 programadores em um mês. A razão seria simples: um maior número de desenvolvedores envolvidos aumenta a complexidade e os custos da comunicação entre os integrantes do projeto. A complexidade aumenta exponencialmente enquanto que a quantidade de trabalho adicionada seria aumentada apenas linearmente. O método colaborativo simplesmente ignora este fato e propõe que quanto mais desenvolvedores são incorporados ao esforço de escrever código livre, mais eficiente é o produto gerado.
E quanto à correção de bugs? Bugs não são novidade no software. O próprio processo de construção de software é baseado na descoberta e correção de bugs. O processo de depuração de software é um processo cuja eficiência aumenta quase linearmente na direta proporção do número de depuradores envolvidos na tarefa. É um processo que tem muito a ganhar com o paralelismo de atividades, pois não demanda muito esforço de coordenação e gerenciamento. Os depuradores não precisam de muita interação entre si, apenas precisam ser coordenados por um responsável pela decisão de aprovar ou não as correções.
O método colaborativo potencializa o processo, pois permite que milhares de desenvolvedores analisem e testem peças de código, depurem os erros e submetam as correções aos coordenadores dos módulos do sistema. É um processo similar ao sistema acadêmico de revisão de textos científicos para publicação, conhecido como “peer review” ou revisão pelos pares, quando um ou mais revisores atestam a qualidade do texto e sugerem correções e modificações. Este processo garante o nível de qualidade e integridade dos textos científicos a serem publicados.
Entretanto, o modelo de desenvolvimento bazar muitas vezes negligencia alguns aspectos como a questão do prazo e definição clara do escopo. Muitos softwares Open Source começam com uma parte do código sendo disponibilizada e algumas vagas intenções de escopo. À medida que o software é desenvolvido comunitariamente, o próprio escopo muda sensivelmente. Prazo pode ser fundamental para alguns produtos de software. Como a contribuição é voluntária, o modelo colaborativo não pode forçar prazos. Assim pode-se questionar a validade do método bazar para desenvolvimento de softwares que necessitem de escopo e prazos bem definidos.
Com o tempo, diversas variantes do princípio colaborativo vem sendo adotados. Vemos hoje projetos de Open Source onde a gestão está a cargo de uma determinada empresa, que sustenta financeiramente a iniciativa, pagando desenvolvedores e custeando muitos dos esforços da comunidade de voluntários. Mas, mesmo neste caso, as decisões são tomadas pela comunidade e não pela empresa. Em outros projetos, a gestão está a cargo de uma fundação, sustentada pela doação de empresas e indivíduos.
O modelo de Open Source tem seu processo de desenvolvimento efetuado por métodos que em muitas vezes contradizem os parâmetros básicos da engenharia de software, aprendidos nas salas de aula. É uma quebra de paradigmas…Mas tem dado certo, basta ver os inúmeros projetos de sucesso. Por que não olhar com mais atenção este modelo?