Mercado fechará em 5 h 17 min

Abrindo oportunidades: do proprietário ao open source

Boris Kuszka

O open source, por suas características básicas, permite desenvolver e entregar soluções que trazem novos recursos tecnológicos de ponta, melhorando a política de segurança, sempre evoluindo o código de programação e oferecendo uma série de benefícios. Entre os pontos positivos está evitar ficar preso a um fornecedor com a utilização de padrões de mercado e, principalmente, uma grande velocidade de evolução e inovação, seja na modernização de infraestrutura, otimização no uso de recursos ou na implementação de plataformas ágeis.

Optar pelo código aberto é uma decisão estratégica que ajuda a criar tecnologias mais seguras, estáveis e inovadoras, essenciais para a construção e a efetividade de modelos de negócio mais alinhados com as atuais necessidades de mercado. Mas nem sempre a criação de um sistema ou solução open source parte do "zero". Muitas vezes, é possível partir de tecnologias proprietárias para transformá-las em código aberto. É o que chamamos de quebrar as barreiras proprietárias para desenvolver o open source.

A jornada de desenvolvimento do código aberto, geralmente, envolve a criação de um projeto upstream, que permite a colaboração de diversas empresas e indivíduos, para que essa versão gere o produto empresarial final, adequado para data centers profissionais. A busca pela inovação e velocidade de desenvolvimento permite inverter esse caminho. Ou seja, criar projetos comunitários open source a partir de códigos proprietários, depois de substituir todas as tecnologias proprietárias por tecnologias open source.

Um exemplo recente foi visto na demonstração que o diretor global de Experiência em Desenvolvimento da Red Hat, Burr Sutter, fez durante o Red Hat Summit Virtual que aconteceu em abril deste ano, destacando o ACM (Advanced Cluster Management), solução bastante em evidência hoje por permitir controlar vários clusters de containers por um único painel.

O produto veio da IBM com uma mescla de partes open source e proprietárias. De acordo com a política da Red Hat, que segue 100% fiel e comprometida com o open source e seus benefícios para o desenvolvimento do mercado, estamos no processo de abertura do código-fonte para este novo produto. Criamos um projeto upstream do ACM chamado de “Open Cluster Management”, já publicado no GitHub. Essa mesma tecnologia, agora de código aberto, também será usada pela própria IBM para seu CloudPak for Multicloud Management.

Na busca pelos benefícios inerentes ao open source, essa é uma solução cada vez mais desejada: transformar códigos proprietários, ou que não são 100% open source em códigos abertos e projetos upstream para então se alcançar um produto completamente open. A premissa básica é possibilitar que a comunidade tenha acesso a esses projetos, podendo não só contribuir com eles, como criar outros projetos a partir daquelas ideias iniciais. É o ciclo virtuoso do open source do qual tanto temos orgulho. São várias pessoas trabalhando por um bem comum, mas monetizando da forma que melhor convier. Monetizado sim, pois uma solução empresarial open source, apesar de aberta, não é gratuita.

Construindo comunidades

Ao realizar os processos de abertura e adaptação, contudo, é preciso endereçar questões técnicas e legais, o que pode demandar um certo tempo. Afinal, somente tornar o código-fonte de uma tecnologia um código aberto não é suficiente para construir uma comunidade. Na verdade, existem muitos aspectos que precisam ser considerados. Por exemplo, como ficam os direitos autorais?

Além disso, é criticamente importante que a abertura do código seja feita com a confiança de que o projeto resultante poderá dar suporte a potenciais parceiros e ao mercado como um todo. Neste sentido, é preciso separar os projetos upstream – nos quais focamos na inovação compartilhada com desenvolvedores – dos downstream, que têm como foco a integração e a oferta de estabilidade para clientes.

Quando um software proprietário – ou parte dele – tem seu código transformado em open source, há geralmente uma percepção de que esse processo deve ser rápido e indolor. Embora a proposta envolva escolher uma licença e publicar os repositórios de códigos abertos, outras questões surgem ao se passar do modelo proprietário para o open source. Uma parcela importante dessas tarefas não é de engenharia. Na prática, o departamento legal e os times de marketing, liderança de negócios, documentação, suporte e infraestrutura estarão tão ocupados com atividades relacionadas ao lançamento open source quanto a equipe de engenharia.

Na lista de pendências, se houver licenças incompatíveis com a licença-objetivo do projeto, por exemplo, elas terão de ser removidas, substituídas ou reescritas. Pode-se optar por compactar o histórico do código para ocultar informações potencialmente sensíveis ou privilegiadas, uma tarefa da engenharia. A revisão legal para conformidade de exportação, política de privacidade e conformidade de licença pode levar um tempo considerável. Criar o plano de negócios, que justifica o investimento de recursos para tornar o projeto bem-sucedido após o lançamento, e montar uma estratégia, exigem muito esforço das equipes envolvidas no programa de código aberto, desde a liderança de negócios e gerenciamento de produtos até o marketing.

Garantir que haja informações suficientes para responder às perguntas mais comuns dos usuários e boa documentação para iniciantes é outra preocupação das equipes de suporte e documentação. Outro aspecto importante é planejar e executar a criação de um site de projeto completo, com capturas de tela, postagens de blog, vídeos de demonstração e outros requisitos. Em suma, a transformação de um projeto proprietário em código aberto é um pouco como um iceberg: acima da superfície enxergamos apenas uma parcela do trabalho envolvido, sem muitas vezes nos darmos conta da extensa base submersa de atividades necessárias para dar vida ao projeto.

Mais possibilidades abertas

A transformação de código proprietário em open também foi protagonista no desenvolvimento de soluções que, embora existam há 20 anos, vem sendo revisitadas constantemente, principalmente em meio ao contexto da pandemia do novo coronavírus que exige um nível maior de automação pela exigência de acesso remoto aos sistemas tanto das equipes de trabalho quanto dos clientes e parceiros. Esse é o caso do Business Process Modelling, ou BPM. Com mais pessoas focadas em trabalhar digitalmente hoje, há uma maior preocupação em eliminar os processos manuais e que estão fora do fluxo computacional para processos automatizados e totalmente digitais.

A liberação de um projeto proprietário como open source habilita novas capacidades, ressignifica soluções precedentes e impacta a evolução do mercado de várias maneiras. A adoção de uma plataforma comum para colaboração, no entanto, exige foco. Precisamos descobrir para onde se quer ir e quais recursos são necessários para chegar lá. Respeitar o caminho que vimos aqui é o modo mais seguro não só para garantir a transformação de código proprietário para open source, mas também contribuir para que a evolução tecnológica siga na direção de horizontes mais abertos.

Fonte: Canaltech

Trending no Canaltech: