Projetos open source: saiba como avaliar a colaboração

Saiba como participar desses projetos e medir o sucesso das iniciativas.

Por CIO (EUA)
13 de janeiro de 2009 - 08h20

Se 2008 tem uma palavra-chave ela foi, provavelmente, “comunidade”. Mais e mais companhias buscam a colaboração para projetos de código aberto. Mas seguir a tendência só porque todos estão indo nesse caminho não é uma idéia tão boa assim.

Para ser bem-sucedido, o gestor de TI precisa de um plano detalhado sobre o que a organização precisa e como obter esses objetivos. Além disso, o líder deve desenvolver o projeto de open-source, sem prejudicar a liberdade existente nessas comunidades, chamadas de FOSS (sigla do inglês para Free and Open-Source software Community)

A justificativa para insistir nas métricas dos projetos de FOSS não é desencorajar o envolvimento corporativo com o código aberto, pelo contrário. Organizações podem alcançar o sucesso de forma mais fácil, caso tenham um planejamento e que contemple, desde o início, métricas. Muitas organizações, no entanto, começam com metas vagas ou mal definidas (tal como construir a comunidade) e acabam desapontadas com o resultado. Então culpam o modelo open-source, quando, na realidade, trata-se de uma falha de liderança e falta de direcionamento.

O que esperar
Companhias que buscam a contribuição de comunidades devem saber que leva algum tempo para receber o retorno do investimento. Jogar códigos na parede não é o suficiente para obter contribuições. Os desenvolvedores precisam interagir com a comunidade para ajudar a suportar seus esforços. Geralmente, leva algum tempo para contribuintes externos aprenderem sua porção em um projeto e começar a ser produtivo.

Se a meta é “terceirizar” a maioria do desenvolvimento em comunidades de código aberto, esqueça. Enquanto uma comunidade saudável pode prover contribuições valiosas para o responsável por projetos open-source na companhia, não é um substituto para a equipe de engenharia. Os colaboradores também esperam direcionamento do próprio projeto, e certa governança.

Se isso parece muito limitador, o lado bom da coisa é que as comunidades realmente dão uma grande contribuição a projetos, particularmente em termos de testes, correções, traduções, novas características e até no marketing. As pesquisas da Evans Data sobre o assunto geralmente demonstram que cerca de dois terços dos desenvolvedores que recebe algum tipo de contribuição retorna à comunidade.

Que tipo de contribuição?
Antes de sua companhia deslanchar um projeto de open-source, você precisa decidir que tipo de comunidade quer ver florescer e determinar a natureza da contribuição que o negócio deseja. Quer uma comunidade massiva em usuários, mas não está muito preocupado com as contribuições? Ou é melhor ter uma comunidade pequena que dedica seu trabalho a trabalhar em projetos que mais se aproximam das metas da companhia?

Outra opção é uma comunidade de desenvolvedores que usa e estende tecnologias como o SugarCRM, que tem uma comunidade muito interessante para isso. Colaboradores podem vir com várias roupagens, e um modelo não necessariamente servirá para todos.

Algumas companhias estão contentes com projetos que estão disponíveis abaixo de uma licença de open-source, mas com grande parte do desenvolvimento feito em casa pelos desenvolvedores da casa. Nesse caso você pode medir o sucesso de sua organização apenas por meio da adoção.

Mas, uma vez definido aquilo o que você quer, como saber se está chegando lá?

Como medir o nível de sucesso
Downloads é uma métrica estúpida, dado que uma série de aplicativos baixados nunca é instalada. Há muitas abordagens melhores, se não, de encontrar dados precisos. Você deve querer uma forma de rastrear atualizações e instalações do produto. Por hora, um programa pode “ligar pra casa” depois de instalado (com o consentimento do usuário, claro). Um exemplo é o Smolt, inicialmente desenvolvido pelo Fedora Project, e agora sendo usado também pela openSUSE Project. (Smolt não faz muito mais do que rastrear o número de instalações. Ele rastreia as características do hardware para identificar em que tipo de equipamento o Linux é mais usado).

Outra métrica a considerar é o número de usuários. Por exemplo, o open SUSE Build Service requer que os desenvolvedores registrem-se em uma conta para criar pacotes. Isso permite que rastreemos o número de desenvolvedores registrados, o número de pacotes no sistema e quantos projetos estão sob controle.

É importante pensar que seu sistema de rastreamento pode ter dificuldades na retro-alimentação. Se seu rastreador não distinguir entre os funcionários da sua organização e os colaboradores da comunidade, como você pode identificar o número de bugs reportados interna e externamente? Eles não serão muito eficientes se você não souber quem está fazendo o que.

E, obviamente, você deve encorajar sucesso. Se contribuições em códigos são a meta de sua companhia, uma política de copyright liberal encorajaria colaboradores. Requerer que os colaboradores dêem todos os direitos a sua empresa, provavelmente não irá inspirar muito os desenvolvedores. Mas, se não houver nenhuma política de copyright, podem aparecer dificuldades se sua organização quiser fazer mudanças no meio do caminho, tal como mudar de uma licença de open-source para outra.

Ao estabelecer objetivos claros desde o início, é mais fácil para sua companhia determinar quando o open source é o patamar correto para seu projeto de desenvolvimento de software. Uma vez a decisão é por esse caminho, trabalhe no plano e ajuste as necessidades para obter os resultados desejados.

Joe Zonker Brockmeier é o gerente da comunidade openSUSE