Amigos, em meu último post apresentei alguns conceitos sobre comunidades colaborativas para desenvolvimento de software. Neste post , gostaria de dar continuidade ao tema, abordando as metas de nossa comunidade e questões relativas à organização de uma comunidade colaborativa.

Proponho que a principal meta de nossa comunidade seja:

“Criar componentes de interface Web 2.0 e sua infra-estrutura, a partir de requisitos desenvolvidos colaborativamente com o mercado, com foco na usabilidade”.

Dúvida: como administrar algo tão complexo como uma comunidade de desenvolvimento colaborativo? Existem vários modelos para a administração de comunidades:

• Throw code over the all? - Disponibilizar o código para a comunidade, mas para evoluir e manter esse código; só funciona se ele for revolucionário e muitas pessoas estiverem interessadas.
• Desenvolver internamente, postar externamente? - Pessoas olham, usam, passam, porém não se percebe o efeito comunidade.
• Open monarchy? - Aqueles que desenvolverão os requisitos são empregados da empresa, com algum apoio externo. Alguém da empresa concentra as decisões e os demais são desenvolvedores. A empresa controla tudo e atrai voluntários da comunidade.
• Desenvolvimento baseado em consenso? -Discussões, códigos e decisões são públicos. O desenvolvimento e o crescimento da comunidade é rápido, porém caótico e mais difícil de controlar. O código oferecido ao mercado é aberto, pode ser usado por quem desejar e a responsabilidade de quem disponibiliza é restrita. A evolução se dá por meio de consenso com a comunidade.

Apesar de entendermos as dificuldades, me parece que o “Desenvolvimento Baseado em Consenso” é a melhor opção (indico assistir este vídeo, em inglês, aprox. 50 min.). Algo para discutirmos juntos.

A próxima questão que se coloca é: quais são os papéis dentro da comunidade? Para cada projeto, nossa equipe sugeriu os seguintes papéis:

• Moderador: Sempre deverá haver um, que auxilia na tomada de decisões e interfere na solução de conflitos. Cabe a ele o “voto de Minerva”. O moderador é escolhido por votação e é o único que tem o poder de banir membros da comunidade
• Commiters: São as pessoas que definem os requisitos que nortearão o processo de desenvolvimento. São os elementos chaves da comunidade. O commiter é alguém que de alguma maneira já se envolveu com o desenvolvimento daquela peça de código. Não há limite para o número de commiters por projeto. Escolhidos pela comunidade por votação. O commiter tem alto compromisso com a qualidade e assegura que tudo foi testado e devidamente documentado.
• Colaboradores: Aberto a quem quiser participar. Participam do projeto, corrigindo bugs e submetendo patchs, para os commiters decidirem se entra no código ou não. Normalmente iniciam documentando ou testando o código.
• Usuários: Desenvolvedores que acompanham o projeto e baixam códigos fonte ou versões compiladas. Usam os produtos e sugerem requisitos.

Falando um pouquinho sobre o processo de colaboração, gostaria de propor uma divisão de cada projeto em 4 fases distintas:

• Lançamento de um componente para desenvolvimento público através de uma incubadora virtual
• Eleição dos membros da comunidade
• Definição dos requisitos (trabalho dos commiters)
• Desenvolvimento colaborativo
• Promoção dos projetos de incubados para disponíveis para a comunidade

Eis a idéia para aprofundarmos. Com base nos feedbacks, num próximo post entrarei em detalhes sobre a estrutura e o modus operandi da comunidade. Nesse post abordarei também questões como orçamento, plataforma de colaboração, infra-estrutura e quais componentes de software a Datasul pretende liberar num primeiro momento .

Sugestões sobre esses temas todos são muito bem vindas.

Referência:

Producing Open Source Software: How to Run a Successful Free Software Project; Karl Fogel – disponível on-line em FreeTechBooks.