Como Montar uma IBM de Software Livre

Eu sempre acreditei que, usando SL, eu posso criar uma empresa que não fabrique nenhum produto, mas mesmo assim fature alto com soluções de TI. A idéia é bem simples, até. Por exemplo, vamos dizer que um ministério lance um edital para isso:

Precisamos de um sistema para pagar conveniados do programa X, com todos os pagamentos a partir de R$100k auditados, com interface web para o conveniado acompanhar seu processo de pagamento e/ou auditoria, para que ele possa tomar as providências necessárias. Queremos que todos esses números apareçam no Portal da Transparência automaticamente, atualizado mensalmente. Todo acesso dos conveniados e funcionários da administração pública federal devem ser controlados com criptografia.

Até ontem à noite, eu não tinha uma idéia clara de como montar essa empresa, que pudesse atender esse tipo de demanda com SL. Minha visão, para mim, sempre foi muito clara – empresa três-em-um: Centro de Dados + Software House + Soluções. Se, eventualmente, o cliente decidir usar o próprio CD ou de um terceiro, como o Serpro, a empresa poderia passar tudo para lá facilmente (eu construiria as soluções para rodar em máquinas virtuais, como uma nuvem.)

Dai, digamos que essa empresa examina sua linha de produtos de SL (todos adotados, nenhum inventado por eles) e concluem que:

• O módulo financeiro de um ERP (Compieri, digamos) pode controlar as contas do convênio.
• Um AlFresco pode manter scans da documentação.
• Um Bonita Open Solution pode executar o fluxo de auditoria.
• Um eXo Portal pode ser o link com o conveniado.
• Uma solução de BI com Pentaho pode publicar os relatórios no Portal da Transparência.

Suponha que apenas metade desses aplicativos suporta SSO com criptografia. Como resolvemos?

Assim:

• Cada SL em uso na nossa linha de produtos tem sua própria equipe de desenvolvimento.
• Enquanto o 2/3 da empresa cuida de montar a infra-estrutura (CD) e implantar a solução (Soluções) o outro 1/3 (Software House) define as funcionalidades necessárias que ainda não existem.
• Em conjunto com a comunidade, as equipes de cada um desses programas evolui o SL.
• Na última etapa da implantação, a infra-estrutura atualiza o SL para a última versão comunitária, que foi desenvolvida por essa empresa hipotética.

Na verdade, já existem empresas que fazem isso para si mesmas: usam tudo livre e quando um determinado software não tem tudo, eles pagam alguém para fazer e devolver a contribuição à comunidade. Assim eles ganham duas vezes, com o resultado e alimentando o círculo virtuoso do SL.

E existem empresas como a Pentaho e a RedHat, que também fazem isso. Só que elas dão manutenção apenas nos seus próprios softwares, e tem um foco mais ou menos estanque. Elas atendem aqui e pronto. A minha idéia é um passo adiante: vender soluções e atuar como integrador, que é uma prática habitual no mercado de automação industrial.

O truque é a equipe de desenvolvimento: usar Scrum para dar manutenção em SL, como se essa equipe não fosse da empresa, mas uma equipe da comunidade que, por acaso, podemos direcionar para onde precisarmos. Se, de repente, não há demanda interna para melhorias em um determinado produto, essa equipe pode colaborar implementando as melhorias demandadas pela comunidade.

Há um grande impecilho nisso tudo: a equipe de vendas. Imagine ter especialistas em trocentos assuntos diferentes numa mesma pessoa, capaz de examinar a necessidade do cliente e desenhar uma solução Lego com SL. Provavelmente cada equipe de venda teria um especialista em pares de assuntos (Bancos de Dados e SO, BI e ERP, Workflow e BPM etc.), com um generalista capaz de analisar a demanda do cliente e definir a estratégia de implantação.

A vantagem competitiva viria do fato de essa empresa ser especialista na integração e ser co-autora em todos esses SLs. O preço também precisa ser competitivo, claro, mas com o custo de hardware caindo e a sofisticação dos SLs aumentando, isso não deve ficar caro.