5 fatores para usar código-fonte aberto em software proprietário

Vantagens do software de código livre

Os desenvolvedores podem facilmente obter, modificar e integrar inúmeros pacotes de código-fonte aberto em diversos projetos de software. O uso do código-fonte aberto para habilitar recursos e processos básicos em um projeto de software proprietário pode economizar tempo nos ciclos de desenvolvimento e os criadores de códigos gratuitos podem focar em funcionalidades essenciais e que capacitem negócios.

Mas embora os elementos de código aberto confiram benefícios tangíveis para projetos de desenvolvimento de software, eles podem impor desafios e limitações a um aplicativo proprietário, especialmente se o projeto for destinado ao uso comercial. As organizações devem avaliar a gestão e integração de componentes de software de outros criadores, suas prioridades de projeto, responsabilidades, licenciamento e segurança antes de selecionar código-fonte aberto para um projeto.

1. Integração e gerenciamento de software de código aberto

Muitos componentes de código aberto têm uma série de alternativas e variações. Por exemplo, os desenvolvedores podem selecionar entre dezenas –e às vezes centenas– de opções de código aberto de motores de UI. Você precisa avaliar e vetar cada opção para garantir que funcione com o design mais abrangente do seu projeto. Alguns códigos-fonte abertos requerem integração com outros componentes, e você deveria testar cada ponto de integração para garantir a qualidade do software.

Além disso, software de código aberto é atualizado para corrigir bugs, melhorar o desempenho e adicionar recursos, o que significa que os componentes do projeto proprietário devem ser reavaliados e examinados quando alterações ocorrerem no projeto de código aberto.

A integração de código aberto em software proprietário pode criar um pesadelo para gerentes de projetos. Quando um projeto de software distribuído depende de centenas de componentes de código aberto, o tempo e o esforço necessários para simplesmente rastrear cada componente, suas compatibilidades e suas atualizações podem afetar o ciclo de desenvolvimento do projeto.

2. Suscetibilidades do código aberto

O processo de avaliação e validação do código-fonte aberto deveria incluir uma análise do componente durante a consideração do planejamento e codificação.

Uma equipe de software pode querer código-fonte aberto que atenda às suas necessidades urgentes para certas funcionalidades –mas considerar apenas o que eles precisam hoje poderia causar problemas mais tarde. Leia sobre as perspectivas futuras do código, incluindo grandes modificações em potencial. Se o componente não tiver sido atualizado em algum tempo –alguns chamam esses projetos de abandonware– ou não suporte fundamentalmente os recursos que seu projeto deverá exigir no futuro, considere usar trabalho interno ou outras opções de código aberto.

O código-fonte aberto não oferece garantias de qualidade ou desempenho. E ao contrário do software comercial, o código normalmente não possui garantias de que haverá suporte em caso de falha ou má execução. As empresas assumem total responsabilidade pelo desempenho de seus projetos, mesmo que a culpa do desempenho fraco ou de um erro seja diretamente de um elemento de código-fonte aberto. Ao usar código-fonte aberto em projetos de softwares proprietários, considere cuidadosamente as garantias e limitações de responsabilidade delineadas em sua licença.

3. Licenciamento e propriedade intelectual

Embora o software de código aberto seja livre para obter, alterar e trabalhar com ele, ele não é de domínio público. Softwares de código aberto são lançados sob uma licença, como a Licença Apache 2.0; Licença BSD; Licença Pública Geral GNU (GPL), Biblioteca GNU ou GPL Menor; Licença do MIT; ou Licença Pública Mozilla 2.0. Cada licença delimita os termos de uso e distribuição.

Geralmente, licenças de software de código aberto não restringem significativamente a capacidade de uma empresa de adquiri-las e usá-las. Assim, um produto de software proprietário e comercial pode contar com componentes de código aberto.

No entanto, as empresas devem saber se e como uma licença poderia causar problemas. O GPL GNU exige que os usuários liberem quaisquer trabalhos derivados sob a mesma licença GPL GNU. Se uma empresa obtém e modifica código-fonte aberto sob GPL GNU, ela deve liberar o código modificado sob copyleft - o que significa liberá-lo em código aberto, também.

Em alguns casos, todo o projeto de software é considerado um trabalho derivativo do código-fonte aberto que ele usa, e todo o código-fonte do projeto proprietário estará sujeito à distribuição de código aberto nos termos da licença. Por essa razão, os tomadores de decisão de negócios podem impedir que os desenvolvedores usem código-fonte aberto para um projeto, mesmo que ele se encaixe nos requisitos e critérios de funcionalidade do grupo.

4. Prioridades do negócio

Não considere a adequação de um componente de código aberto para um projeto apenas em termos de tempo e dinheiro economizados. Avalie se o componente ajuda ou não a cumprir suas metas de negócio.

Para obter uma vantagem competitiva, as empresas se baseiam em inovação de recursos de software e desempenho eficiente. Os desenvolvedores deveriam sempre procurar por oportunidades para inovar –quer isso signifique que eles reduzam o tempo do projeto encaixando código-fonte aberto nele ou criando componentes personalizados que atendam às necessidades exatas de um aplicativo.

Por exemplo, desenvolvedores de um projeto de ferramenta de visualização e renderização poderiam adotar o software de modelagem 3D de código aberto Blender como base, mas não há nada que impeça seus concorrentes primários de fazer exatamente a mesma coisa. Portanto, a ferramenta resultante iria carecer de diferenciação para conquistar clientes em potencial.

5. Segurança de software de código aberto

Um ecossistema de código aberto rico e ativo é um terreno fértil para códigos vulneráveis e maliciosos. O mercado de código aberto é o exemplo final do caveat emptor, que em latim significa "compre por sua conta e risco".

A segurança do software de código aberto depende do feedback da comunidade –que é mais eficaz quando um projeto é mais popular– assim como a varredura constante por vulnerabilidades. Ao usar código-fonte aberto em software proprietário, as empresas devem arcar com os riscos e implementar verificações de segurança além das contribuições informadas pela comunidade para garantir que o software atenda aos seus padrões corporativos.

Por exemplo, desenvolvedores e testadores devem examinar o código-fonte aberto para identificar spyware incorporado e outros malwares, assim como vulnerabilidades que podem deixar o projeto de software proprietário aberto a ser explorado por agentes maliciosos.

As organizações que dependem do código-fonte aberto em projetos de software devem usar ferramentas de teste de vulnerabilidade para eliminar a suscetibilidade a problemas como estouros de buffer, falsificação de protocolo de endereço, ataques distribuídos de negação de serviço e envenenamento de cache. Os testes de vulnerabilidade podem ser incorporados na cadeia de entrega de software.

Você deve avaliar essas cinco áreas-chaves para cada projeto e para cada peça de código-fonte aberto. Os componentes de código de código aberto são todos regidos por termos específicos de licença, são construídos com diferentes graus de desempenho e estão sujeitos a inúmeros problemas de qualidade em potencial.

O fator comum em todos os casos de uso de código-fonte aberto em projetos de softwares proprietários é que a responsabilidade recai sobre o negócio, não o criador do código. Crie políticas de como usar inteligentemente o software de código aberto e como validar, gerenciar e otimizar seu código.