Os prós e contras do código aberto para empresas

As aplicações de código aberto se estabeleceram firmemente nos sistemas de TI de grandes e médias empresas. Dominando segmentos como servidores web, bancos de dados e análises, as soluções de código aberto agora também são usadas extensivamente para conteinerização, aprendizado de máquina, DevOps e, é claro, desenvolvimento de software. Muitas empresas estão migrando para o código aberto para tarefas não relacionadas a TI, como CRM, produção de conteúdo visual e publicação de blogs. De acordo com a Gartner, mais de 95% das empresas do setor de TI usam soluções de código aberto, mas mesmo entre empresas que não são de TI o número está acima de 40% – e crescendo. E isso não inclui os muitos casos em que bibliotecas de código aberto são usadas em aplicativos proprietários.

Escolher entre código aberto e fechado está longe de ser fácil: não é apenas uma questão de pago versus gratuito, ou suporte versus nenhum suporte. Ao decidir sobre qualquer solução de TI, as empresas precisam considerar uma série de aspectos importantes.

Custos e cronograma de implementação

Embora muitas vezes não haja taxa de licença para soluções de código aberto, a implementação não é gratuita. Dependendo da complexidade da solução, pode ser necessário gerenciar o orçamento relativo à alocação da equipe de TI, contratar consultores especializados ou até mesmo contratar desenvolvedores que adaptarão constantemente o aplicativo às necessidades do seu negócio.

Há também o modelo de licenciamento híbrido, que permite usar uma edição comunitária de um aplicativo gratuitamente, mas a versão estendida com recursos “corporativos” ainda exige uma licença paga.

Além disso, muitos produtos de código aberto não são fornecidos com documentação completa e/ou atualizada ou cursos de treinamento para usuários finais. Para grandes implementações, essa lacuna pode ter de ser preenchida internamente, custando tempo e dinheiro.

A vantagem do código aberto na fase de implementação é, obviamente, que ele permite testes completos. Mesmo se você planeja implantar uma solução desse tipo como hospedagem gerenciada ou com a ajuda de um contratado especializado, realizar um piloto (prova de conceito) por conta própria é muito mais eficaz do que assistir a demonstrações em vídeo das próprias soluções. Você verá imediatamente como a solução é funcional e aplicável para o seu negócio específico.

Ao comparar soluções de código aberto e fechado antes da implementação, é importante entender quanto tempo há disponível para testes e se você tem a opção de alterar o produto em seus estágios iniciais. Se os prazos não forem urgentes e a resposta para a segunda pergunta for sim, o teste completo de um produto de código aberto faz sentido.

Custo de suporte

O suporte diário e a configuração de muitos aplicativos de código aberto em escala industrial, bem como sua adaptação a altas cargas de trabalho, exigem conhecimento altamente específico e aprofundado por parte da equipe de TI. Se isso não estiver disponível, esse know-how terá que ser comprado – por meio da contratação de especialistas ou terceirização. Os tipos mais comuns de terceirização envolvem ajuda especializada específica do aplicativo (formato Red Hat) ou hospedagem gerenciada otimizada para uma solução de TI específica (Kube Clusters, WP Engine ou formato semelhante).

Obviamente, o suporte pago também é padrão para soluções proprietárias; não é apenas o código aberto que precisa disso. Os custos, entretanto, são comparáveis. Como mostra a prática, o suporte técnico anual para um aplicativo corporativo típico de código aberto é apenas de 10 a 15% mais barato do que para soluções proprietárias.

Correção de bugs, novos recursos e dimensionamento

Embora as soluções maduras de código aberto sejam atualizadas regularmente com recursos expandidos e correções de bugs, muitas vezes pode acontecer ocasiões nas quais os desenvolvedores não priorizem um bug crítico para um determinado negócio. Isso é ainda mais comum no caso de solicitações de recursos. Ou seja, você tem que sentar e esperar pacientemente ou gastar o precioso tempo de seus desenvolvedores (internos ou contratados) escrevendo o código necessário. O que é bom é que isso é teoricamente possível; o ruim é que tal caminho pode resultar em um gasto grande e imprevisível.

Observe que a hospedagem gerenciada elimina a preocupação de instalar patches e atualizar aplicativos, mas não pode ajudar com esses ajustes individuais. Uma empresa que tem essa necessidade entra essencialmente no mercado de desenvolvimento, e deve escolher o formato da extensão que cria: uma bifurcação do produto de software principal ou uma adição ao ramo de desenvolvimento principal em parceria com os desenvolvedores originais do aplicativo. É aqui que entram em jogo os benefícios estratégicos do código aberto, ou seja, flexibilidade de uso e velocidade de inovação.

Integração e suporte entre plataformas

Para soluções multicomponentes em larga escala, que trocam dados ativamente, a integração e a compatibilidade com diferentes plataformas podem desempenhar um papel importante na escolha do produto de software. A prioridade aqui é o suporte de formatos da indústria para armazenamento e troca de dados, além de interfaces de programação de aplicativos (APIs) bem documentadas. Às vezes, uma solução de um único fornecedor com código-fonte fechado pode atender a esses requisitos melhor do que um monte de soluções de código-fonte aberto, mesmo aquelas que são de alta qualidade. Mas é sempre útil estimar o custo de ajustar uma solução de código aberto se ela vencer em outros critérios e tiver passado na fase de prova de conceito.

Riscos, segurança e compliance

Como sempre, a realidade é bem mais complicada que isso. Em primeiro lugar, muitos aplicativos de código aberto têm milhões de linhas de código, que ninguém pode auditar por completo. O grande número de atualizações desse código apenas complica ainda mais a tarefa. Dito isto, pequeno não significa seguro. Por exemplo, a vulnerabilidade Shellshock baseada em Bash não foi detectada por 20 anos!

Em segundo lugar, o problema das dependências é agudo, pois os aplicativos e o código têm sua própria cadeia de suprimentos. Um aplicativo de código aberto pode usar uma biblioteca de código aberto de terceiros, que por sua vez vincula-se a outra biblioteca de terceiros, e é improvável que aqueles encarregados de verificar o próprio aplicativo analisem todas as bibliotecas. Os riscos dessa cadeia já foram demonstrados várias vezes: uma vulnerabilidade na biblioteca de registro gratuita Log4j afetou milhares de grandes soluções de código aberto, impactando grandes empresas como Amazon, Cloudflare e Elastic; um ataque substituindo bibliotecas npm por homônimos maliciosos funcionou na Apple e na Microsoft; e a decisão de um desenvolvedor independente de não oferecer suporte à pequena biblioteca left-pad no repositório npm derrubou mais de mil aplicativos e sites populares (incluindo o Facebook) por várias horas.

Fonte: xkcd.com/2347

Outro problema com as dependências é o licenciamento. As licenças de código aberto são bastante específicas e nenhum pagamento não significa nenhum detentor de direitos autorais. O próprio aplicativo e suas bibliotecas podem vir com várias licenças, e a violação das mais rígidas (Copyleft) é repleta de litígios. Semelhante ao processo bem estabelecido de auditoria de segurança de TI e mitigação de vulnerabilidades, os principais usuários e desenvolvedores de software de código aberto devem ter um processo semelhante para verificar regularmente a conformidade da licença – idealmente semi-automatizado.

Tudo o que foi dito acima não significa que o código aberto seja a pior escolha do ponto de vista da segurança da informação. Você só precisa entender todos os riscos: a equipe de implementação precisa avaliar a cultura de desenvolvimento e a frequência de atualizações de segurança em aplicativos contendores e controlar dependências e licenças (por exemplo, usando uma lista de materiais de software). Além disso, se sua empresa estiver trabalhando no campo de desenvolvimento de software, é uma boa ideia verificar todos os pacotes de código aberto em busca de vulnerabilidades e funcionalidades maliciosas.