Soluções de código aberto, geralmente, são de alta qualidade e é possível contar com elas para se operar com confiabilidade. Mas isso não significa que você não precisa fazer "a lição de casa" antes de implementá-la.

Primeiro e o mais importante: agora é preciso lidar com a GPLv3, versão recentemente atualizada da GPL (General Public License ou Licença Pública Geral), da Free Software Foundation (Fundação para o Software Gratuito).

A GPLv3 impõe restrições ao gerenciamento dos direitos digitais e incluiu o Linux, o que pode se mostrar problemático, caso sua companhia planeje revender software baseado em código aberto.

Até o momento, a GPLv3 se aplica a uma minoria. Somente 693 projetos estão emitindo códigos de acordo com ela. Em comparação, 5.219 projetos estão licenciados em conformidade com a GPLv2, o que significa que o mesmo código está disponível sob ambas as licenças.

Não se espera de modo algum que os projetos licenciados segundo a GPLv2 sejam convertidos "em massa" para a GPLv3. Isso acontecerá gradualmente, à medida que os desenvolvedores decidirem sobre os méritos da nova licença quando um lançarem software novo ou atualizado.

O kernel do Linux ainda é emitido de acordo com a GPLv2, mas alguns dos recursos adicionais (add-ons), como o pacote de tradução de arquivos, denominado Samba, em breve estarão em adequação com a GPLv3. Desse modo, o Linux de importantes distribuidores conterá tanto a versão atual quanto a antiga da GPL. Isso quer dizer que "é preciso avaliar o código antes que ele seja inserido atrás do firewall", afirma Theresa Bui Friday, co-fundadora da Palamida, companhia de auditoria de código aberto.

Fatores de risco
A confiabilidade dos sistemas Linux, Apache e Samba está bem estabelecida, mas esse não é o caso dos projetos mais novos. Se você estiver avaliando um protótipo, malas-diretas do projeto fornecem uma visão das questões e dos recursos e oferecem aos potenciais usuários uma percepção daquilo com que é preciso ter cuidado.

Uma lista divulgando a existência de um bug ou falha de segurança também informará as datas em que um problema ocorreu e foi resolvido. Um projeto que tenha uma maior exposição, com duração de seis meses, pode ser um código a evitar.

Sites como SourceForge.net e Ohloh.net fornecem estatísticas sobre o nível de atividade de um projeto, como quantos colaboradores existem, com que freqüência o código é enviado para criação de núcleo e quantos bugs existentes estão esperando para serem resolvidos. O grau de atividade pode ser um sinal de que uma comunidade está prosperando ou fracassando.

Luz verde
Existem alguns meios pelos quais esse novo código pode ser rapidamente examinado. Ferramentas demonstraram bom desempenho para programadores da Eclipse e aplicativos que trabalham com a OpenOffice.org foram aprovados em um teste fundamental de confiabilidade e compatibilidade.

Programas de software que estão sendo aprovados para inclusão em um dos grupos de software, como os LAMP (Linux, Apache, MySQL, e Perl, Python, PHP) são outra rápida medida de confiabilidade. SpikeSource, Covalent, Red Hat, Novell e SourceLabs aprovam determinadas partes de código trabalhando em conjunto. A Sun Microsystems também  testa e distribui PostgreSQL, MySQL e o banco de dados Derby Java, da Apache Foundation, para trabalhar com Solaris e outros softwares da Sun.

Estas ratificações feitas por grupos experientes são importantes. Mas ninguém quer ficar em uma situação em que o software é teoricamente compatível, mas as companhias ou grupos "por trás" dele não são, e logo deixarão de resolver, em conjunto, possíveis problemas operacionais.

Esta é a sexta matéria da série de sete reportagens intitulada Guia de sobrevivência, que o IT Web publica às quartas-feiras.