O software livre entrou para as empresas de forma desgovernada, para facilitar uma aplicação web ou gerenciar sistemas menores. Mas a tendência aponta para uma utilização mais séria dos sistemas de código aberto e, para isso, é preciso traçar uma política de gerenciamento bem definida e embasada, o que maximiza as recompensas e minimiza os riscos. Veja as recomendações do Gartner para essa política de software de fonte aberta.
Por Mark Driver - 31/05/2007 16:12
ANÁLISE Muitas empresas modernas estão considerando a utilização de soluções de sistemas de fonte aberta por uma variedade de motivos e essa é uma tendência que continuará crescendo nos próximos anos. Os fornecedores de TI, que representam 80% do mercado global, entretanto, não devem permitir que os softwares de fonte aberta penetrem facilmente nas empresas. Diante das dificuldades, cabe às áreas de TI evitar que os sistemas abertos entrem de forma desapercebida em suas empresas, sem controle e de forma desgovernada, como aconteceu no passado.A proliferação desenfreada de qualquer ativo empresarial (software ou não, fonte aberta ou fechada) produzirá níveis inaceitáveis de riscos técnicos e legais para as empresas.Incorpore os seguintes aspectos em sua política de fonte aberta:
Entenda os detalhes de toda licença de fonte aberta vinculada aos produtos e projetos que você pensa em adotar.
Entender os detalhes do licenciamento é um passo crucial na aquisição de software, seja ele de fonte aberta ou fechada. Nos sistemas abertos, as licenças são bem diferentes dos acordos tradicionais de usuário final de softwares de fonte fechada. Essas diferenças fundamentais definem a proposta de valor do modelo de software aberto, mas elas também podem gerar confusão e quase sempre levar a equívocos substanciais que, se não resolvidos, podem resultar não apenas em um retorno sobre o investimento não realizado, mas também num risco legal significativo.
As licenças de fonte aberta não apenas diferem drasticamente de seus correspondentes de fonte fechada, como também diferem umas das outras.Conseqüentemente, não basta se tornar familiar unicamente com a principal definição de fonte aberta. No lugar disso, você também deve examinar os detalhes de uma variedade de licenças principais. É preciso também categorizar detalhadamente as licenças em relação àquelas que são inadequadas às necessidades estratégicas de sua empresa. O mais importante, contudo, é projetar situações de “adequação de objetivos” para cada licença. Por exemplo: licenças recíprocas (ou copyleft, com liberdade para copiar) podem ser aceitáveis para uso do tipo caixa preta, onde o acesso ao código fonte não é necessário para o uso rotineiro.Entretanto, esse estilo de licença, vinculado à uma biblioteca de classe, pode acionar um sinalizador vermelho para muitas iniciativas de TI.
Se sua empresa não tiver os recursos internos para tratar das questões de licenciamento com esses detalhes, contrate assistência jurídica de um advogado com conhecimento em leis de licenciamento e de propriedade intelectual.
Comece com uma auditoria abrangente de todos os ativos de software utilizados na empresa.
Determine quais dos seus ativos de software são licenciados como fonte aberta e se outros possuem código de fonte aberta embutido. Além disso, solicite essas informações a cada um de seus fornecedores de software comercial. Depois examine cada produto para garantir que você esteja utilizando em conformidade com seus termos de licenciamento. Empresas como Black Duck Software (www.blackducksoftware.com) e Palamida (www.palamida.com) oferecem soluções que podem automatizar esse processo de auditoria e aperfeiçoar iniciativas contínuas de conformidade.
Muitas empresas se surpreenderam com a penetração da fonte aberta que ocorreu de forma desapercebida durante os últimos anos.
Além do mais, a fonte aberta está penetrando na empresa embutida num número cada vez maior de soluções comerciais. Invista num processo rigoroso de auditoria de divulgação para futuras aquisições de software que incluam não apenas canais de terceiros externos, como também soluções internas.
Meça o desenvolvimento de cada solução de fonte aberta que você pensa em adotar.
Nem todos os projetos que usam fonte aberta são criados da mesma forma. Alguns nunca adquirem a força suficiente para o sucesso e todos amadurecem em tempos diferentes. Há uma grande diferença entre um projeto que estabeleceu uma evidente massa crítica, como Linux, JBoss ou Apache, e um que é menos desenvolvido. Um nível aceitável de desenvolvimento está amplamente baseado em métricas básicas e universais. Qual o tamanho da comunidade? Há canais comerciais de serviço e suporte? Com qual freqüência o projeto é atualizado? O projeto é executado por um grupo sem fins lucrativos estabelecido ou por fornecedor estável? Essas perguntas precisam sempre ser respondidas.
Determinar um nível aceitável de maturidade é uma métrica relativa que pode ajudar. O Hype Cycle de fonte aberta do Gartner é um ponto de referência útil, e outros recursos, como a Classificação de Legibilidade do Negócio (www.openbrr.org), também podem ajudar.
Entenda os mecanismos de projetos por trás das soluções que você pensa em adotar.
Assim como as licenças de fonte aberta diferem significativamente umas das outras, os mecanismos por trás do desenvolvimento de soluções abertas também variam amplamente. Alguns projetos são vinculados a fornecedores comerciais. Essas iniciativas quase sempre oferecem um serviço comercial mais robusto e opções de suporte no início do desenvolvimento do produto, mas, freqüentemente, o fazem ao custo de comunidades colaboradoras menores e menos ativas.
Outros projetos, como o Apache Software Foundation, são modelados por meritocracias que estimulam uma vasta gama de contribuições de comunidades maiores. O importante é que os mecanismos de projeto ditam o nível de controle e governança que influenciam uma grande variedade de fatores, como segurança e redução dos riscos. Em outras palavras, projetos bem executados afetam dramaticamente fatores como maturidade e risco.
Garanta provedores de serviço e suporte de confiança para cada projeto de fonte aberta que você adotar.
A barreira extremamente baixa para entrar na fonte aberta exige que cada adotante receba um canal seguro e de confiança para cada solução que deseja ter. Deixar de fazê-lo abre a empresa para riscos significativos, como Cavalos de Tróia e vírus.
Adquirir uma cópia do Linux de uma fonte bem estabelecida, como Red Hat, Novell ou Debian, é muito diferente de baixar uma distribuição de um web site anônimo. Além disso, determine se você aceitará suporte de uma única fonte e o bloqueio que funcionará com ela. Assim estará criando uma fonte aberta não tão diferente comercialmente de uma fonte fechada ao longo do tempo.
Toda política corporativa de fonte aberta deve especificar claramente as expectativas do serviço e do suporte. Alguns projetos mais simples, como Apache Struts, podem exigir apenas um treinamento básico e alguns manuais de referência de qualidade; outros exigirão contratos de suporte em nível de serviço mais robustos, como implementações do Enterprise Linux.
A combinação entre o perfil tecnológico e as situações de uso, como implementações de missão crítica, determinará que canais são necessários.
Estenda a gestão de vulnerabilidade às soluções de fonte aberta.
Os processos de avaliação de vulnerabilidade e de gestão de correções e de configuração devem ser estendidos a todos os softwares de fonte aberta, para garantir que caminhos para ataques não sejam abertos. Embora as soluções de fonte aberta não sejam inerentemente mais vulneráveis a questões de segurança do que as de fonte fechada, elas também não são imunes a esses riscos.
Determine o nível de proteção legal que você precisa para cada projeto.
Numa situação ideal, todo pacote de software viria acompanhado de um contrato que protege o usuário de possíveis problemas de propriedade intelectual. Alguns fornecedores de fonte aberta oferecem indenizações, como Red Hat, Novell ou MySQL.
Além disso, o nível e as limitações de garantia e indenização diferem significativamente, mesmo entre os fornecedores que fornecem esses contratos.
Os usuários não podem obter uma proteção completa para todos os produtos que utilizam. Entretanto, ao lidar com canais de suporte comerciais, solicite indenização por violações de Propriedade Intelectual (PI) de direitos autorais e de segredo comercial. Se não houver indenização, então o valor do ativo deve ser ponderado contra seus riscos legais potenciais. Por exemplo: a solução representa um benefício que excede seus riscos pragmáticos?
Mesmo sem uma indenização explícita, um projeto de fonte aberta pode ter uma forte política de governança que minimize os riscos de PI.
Estabeleça uma cadeia de comandos descendente a partir do nível mais alto da gerência para garantir o cumprimento da política.
Você deve adotar uma estrutura na qual inspeções e equilíbrios possam ser aplicados para criar uma estrutura compatível de cumprimento das políticas traçadas. Idealmente, as diretrizes da política devem fluir por toda a empresa a partir no nível mais alto da gerência. Em casos onde as estratégias de TI são distribuídas num amplo espectro de unidades de negócios semi-autônomas, crie uma abordagem de força-tarefa que estabeleça acordos de conformidade de cada unidade de negócios.
Defina normas corporativas de envolvimento com a comunidade de fonte aberta.
A comunidade em torno das soluções de fonte aberta estende-se além de seus programadores principais. Todo usuário faz parte do efeito de rede que impulsiona o modelo de software de fonte aberta. Cada adotante deve decidir cuidadosamente que nível de envolvimento terá com a comunidade em relação a cada produto que utiliza.
Estabeleça normas de envolvimento em relação aos seguintes fatores para cada solução de fonte aberta que você utilizar:
- Nível 0: Alavanque a fonte aberta, mas não envolva a comunidade diretamente.
- Nível 1: Submeta solicitações de recursos e relatórios de defeitos à administração da comunidade.
- Nível 2: Submeta as soluções de problemas à comunidade para potencial inclusão nas distribuições de base.
- Nível 3: Submeta novos recursos criados à comunidade para potencial inclusão nas distribuições de base.
- Nível 4: Assuma ativamente a responsabilidade por uma solução de fonte aberta como sua mantenedora principal (ou seja, torne-se um líder da comunidade).
As empresas de TI que podem empregar efetivamente esses fatores para criar uma política de software comercial de fonte aberta encontrarão o maior número de benefícios a partir de uma grande quantidade de opções potenciais de fonte aberta disponíveis. Além do mais, a não adoção de uma política assim deixará as empresas cada vez mais vulneráveis a riscos técnicos e legais que ultrapassam os benefícios da utilização de sistemas de fonte aberta.