Código aberto é uma coisa boa; boa particularmente para segurança. Neste artigo, no entanto, vamos falar um pouco mais sobre um recurso de código aberto que é sem dúvida uma possível desvantagem e também um benefício: a diferença entre um projeto e um produto.
A principal razão pela qual o código aberto é bom para a segurança é que você pode ver o que está acontecendo quando há um problema e tem a chance de corrigi-lo. Ou, de maneira mais realista, a menos que você seja um profissional de segurança com especial experiência no projeto de código aberto em que o problema surge, outra pessoa tem a chance de corrigi-lo. Esperamos que haja pessoal de segurança suficiente com os conhecimentos necessários para corrigir problemas e vulnerabilidades de segurança em projetos de software dos quais gostamos.
No entanto, é um pouco mais complexo que isso. Em uma organização, existem duas maneiras principais de consumir código aberto:
- Como um projeto: você pega o código, escolhe qual versão usar, compila você mesmo, testa e depois gerencia.
- Como um produto: um fornecedor pega o projeto, escolhe qual versão empacotar, compila, testa e depois vende suporte para o pacote. Geralmente, inclui documentação, patches e atualizações.
Diferença entre um produto e um projeto de código aberto
Basicamente, escolher implantar um projeto em vez de um produto, é tomar a decisão de fazer a produção interna do projeto. Você perde não apenas o benefício da comunidade nas correções de segurança, mas também as significativas economias de escala que são intrínsecas ao modelo de produto suportado pelo fornecedor. Além disso, outras economias que você pode perder são: muitos fornecedores terão vários produtos aos quais oferecem suporte e poderão aplicar conhecimentos de segurança nesses produtos de maneiras que talvez não sejam possíveis para uma organização cujo foco principal não seja o suporte ao produto.
Essas economias se refletem em outro possível benefício para a comunidade de usar um fornecedor: o fato de vários clientes estarem consumindo seus produtos significa que os fornecedores têm um incentivo e um fluxo de receita para gastar em correções de segurança e recursos gerais.
E se um fornecedor falir?
E se um fornecedor que você usa para fornecer uma versão produzida de um projeto de código aberto falir ou decidir abandonar o suporte a esse produto? Bem, isso também é um problema no mundo do software proprietário, é claro. Mas no caso de software proprietário, há três resultados prováveis:
- Agora você não tem acesso à fonte do software e, portanto, não há como fazer melhorias.
- Você tem acesso à fonte do software, mas ela não está disponível para o mundo inteiro e, portanto, você está por sua conta.
- Todas as pessoas são fornecidas com a fonte de software, mas não existe uma comunidade para aprimorá-la, ela morre ou leva um tempo significativo para uma comunidade construir em torno da fonte.
No entanto, no caso do código aberto, se o fornecedor que você escolheu fechar, sempre há a opção de usar outro fornecedor, incentivar um novo fornecedor a aceitá-lo, produzi-lo você mesmo (e fornecê-lo a outras organizações). Porém, se o pior acontecer, siga a rota de produção interna enquanto procura uma solução escalável a longo prazo.
Produto e projeto de código aberto – objetivos diferentes
No mundo moderno do código aberto, nós (a comunidade) ficamos muito bons em gerenciar essas opções, como mostra o crescimento de consórcios de código aberto. Em um consórcio, grupos de organizações e indivíduos agrupam-se em torno de um projeto de software ou de um conjunto de projetos relacionados para incentivar o crescimento da comunidade, o alinhamento em torno das adições de recursos e funcionalidades, o trabalho geral de segurança e a produção para casos de uso que ainda estão mal definidos. Um exemplo disso seria o Confidential Computing Consortium da Linux Foundation.
A escolha de consumir software de código aberto como um produto e não como um projeto envolve algumas compensações. Porém, pelo menos do ponto de vista da segurança, a economia para as organizações é bastante clara. Ainda mais, a menos que você esteja em condições de empregar especialistas em segurança, é mais provável que os produtos atendam às suas necessidades.
Neste artigo, você aprendeu qual é a diferença entre um produto de código aberto e um projeto de código aberto.
Com informações do artigo de Mike Bursell, funcionário da Red Hat, publicado no site Opensource.com.
Leia também:
Vale a pena contratar suporte para software open source?
Open Source Initiative (OSI) anuncia nomeação de novos diretores!
