Sem o código open source, o mundo como o conhecemos pararia abruptamente. Até o software corporativo está cheio dele. E com razão: ninguém beneficia quando investes tempo a reinventar a roda. Ainda assim, o código open source não está isento de riscos.

1. Amadores ou profissionais?

O primeiro grande ponto de interrogação é a qualidade do código. Regra geral, o open source tem boa reputação. Programadores profissionais de todo o mundo trabalham em grandes projetos. Atualizações com código descuidado são limpas e respeitam-se boas práticas. Mas nem todos os projetos têm tantos seguidores como o kernel do Linux. É preciso prestar atenção, sobretudo aos pequenos pedaços de código open source. Um pequeno código útil pode ter sido criado por dez profissionais, mas também por um estudante de primeiro ano muito ambicioso, mas pouco talentoso, a trabalhar sozinho

Algumas regras básicas podem ajudar. Por exemplo, verifica a qualidade da documentação de acompanhamento e o número de commits. Além disso, podes pegar numa amostra aleatória e recorrer à ajuda de ferramentas online. O primeiro passo é estar ciente de que um projeto útil não é necessariamente um projeto de qualidade.

2. Suporte

E depois precisas de ter em conta o suporte. Os projetos grandes e populares encontraram voluntários que os mantêm vivos. Mas, e os pequenos pedaços de código menos visíveis? O projeto de estimação de um guru de Java algures nas montanhas do Nebraska pode revelar-se útil durante vinte anos, até o fundador decidir reformar-se e dizer adeus ao mundo dos zeros e dos uns. E subitamente o projeto fica estagnado, apesar de o código ser uma parte essencial de uma aplicação empresarial que desenvolveste.

É por isso que é boa ideia avaliar o entusiasmo por um componente específico. Vês um commit do mesmo especialista a cada seis meses? Ou há colegas por todo o mundo a trabalhar nele todas as semanas ou todos os dias? Se um projeto que está morto é muito útil, podes, claro, ponderar patrociná-lo. A comunidade de open source dá, desde que as pessoas estejam preparadas para retribuir.

3. O que podes fazer com ele?

Só porque te manténs afastado das grandes empresas não significa que as licenças deixem subitamente de existir. O open source também está sujeito a licenças. Nos projetos pessoais não tens de te preocupar muito com isto, mas quando integras código numa aplicação empresarial, é melhor ponderar muito bem o que estás a fazer.

As licenças de open source têm diversos formatos. Algumas licenças permitem tudo. Nesse caso, podes adaptar o código de um componente sem preocupações e usá-lo na aplicação que estás a criar, independentemente de ser para consumo interno ou externo.

O caso muda de figura com as chamadas licenças copyleft. O código que está sujeito a uma licença deste tipo pode ser usado no teu produto de software sempre que pretenderes, mas espera-se que partilhes as adaptações com a comunidade open source, quando partilhares o software finalizado com o mundo. Se estiveres a criar uma aplicação empresarial de natureza comercial com uma componente de open source, esta condição pode revelar-se problemática.

Então e o código que não tem uma licença designada? Esse está igualmente sujeito às leis de direitos de autor. Usar um tal código em produtos comerciais envolve riscos. Por isso, pensa bem antes de integrares código alheio numa aplicação de negócios.

4. Seguro, mas não infalível

Por fim, é melhor pensar nas repercussões de segurança quando integras o código open source numa aplicação. Como todos podem ver o código open source, ele é por norma muito mais seguro do que as alternativas desenvolvidas no seio das empresas. Quinhentos pares de olhos vêm muito mais do que cinco e, hoje em dia, já ninguém acredita na segurança através da obscuridade.

Mesmo centenas de pessoas podem deixar passar coisas de tempos a tempos. Basta olhar para a popular ferramenta de registo open source Log4j. Ela está integrada em dezenas de milhares de aplicações por todo o mundo, desde aplicações próprias de PME até software de gigantes como a VMware. A Log4j revelou ter apenas uma falha crítica e isso está a ter enormes consequências. Todos os que integraram esse componente de open source numa aplicação têm agora de fornecer uma atualização para a aplicação.

Não há problema com isso, desde que tenhas uma ideia clara de quais os componentes open source que usaste nos teus projetos e fiques de olho nas suas vulnerabilidades. Como tal, regista quais os componentes que integraste e onde, e vai acompanhando regularmente o seu estado.

5. Gestão

Em última análise, há uma regra de ouro: tens de saber o que usas e onde. Se estiveres com atenção aos componentes open source incluídos nas aplicações empresariais e ao desenvolvimento do próprio código open source, não deverás ter problemas tão cedo. Desde que não te esqueças que grátis não é o mesmo que sem licença.