O Sr. Fernando França do Desconstruindo me mandou um e-mail falando sobre seu problema com o fornecedor de um ERP que utiliza o PostgreSQL, mas deixou de dar suporte para novas versões. A última versão que ele suporta é a 7.4 lançada há 5 anos. Para o ritmo de desenvolvimento do PostgreSQL isso é muita coisa mesmo. No entanto, o nosso amigo é brasileiro e não desiste nunca… foi atrás do fornecedor que lhe devolveu a clássica resposta: “O PostgreSQL não possui suporte oficial do fornecedor”.

Quando escuto uma coisa destas, respiro fundo e me preparo para uma longa conversa que se segue abaixo. A conversa não é nova, já foi discutida a exaustão em inúmeros lugares, inclusive aqui e esta infelizmente não será a última. Graças a campanhas difamatórias de grandes empresas este assunto vem a tona sempre que alguém deseja se opor a algum tipo de mudança.

Vejamos os argumentos que estão na ponta da língua de quem usa este tipo de argumento:

É claro que muitos fornecedores acabam acreditando nos bilhões de dólares investidos em propaganda e não na palavra de um simples blog. Mas a questão é que muita gente usa o PostgreSQL e outros softwares livres, tem suporte de qualidade e vão muito bem, obrigado. A maioria deles não grita isto aos quatro cantos por aí, mesmo porque, isto pode ser um diferencial competitivo. Mesmo assim sabemos que existem inúmeros casos de sucesso declarados que mostram a maturidade do PostgreSQL em ambientes corporativos.

O curioso neste caso é que a empresa em questão chegou a desenvolver uma versão para o PostgreSQL. Aqui entra um bocado de especulação pela minha parte. Uma especulação plausível, que pode não se aplicar ao caso em questão, mas certamente se aplica a outros casos. O fato é que há uns 5 anos atrás, na época do estouro do Kurumin, o Brasil experimentou uma certa euforia em torno do Linux. Muita gente apostou que o Software Livre seria a solução para cortar drasticamente os custos de TI e sairam implementando algumas soluções por aí de forma caótica. O resultado para quem partiu para este tipo de abordagem foi invariável: falharam miseravelmente. Ocorre que o Software Livre diminui o TCO da sua empresa, mas não a curto prazo. Inicialmente os custos podem até ser mais altos devido às demandas de treinamento, consultoria e migração. É a médio e longo prazo (3 a 5 anos) que o TCO começa a mostrar uma redução significativa.

Muita gente saiu criando versões de seus produtos compatíveis com plataformas livres. A Borland chegou a lançar o Kilix, uma versão do Delphi para Linux. Mas, muitos desistiram no caminho. Alguns voltaram para os braços das plataformas proprietárias. Muitos migraram de forma irresponsável, outros não souberam se adaptar ao ecosistema do Software Livre e alguns receberam propostas indecorosas para frear suas ações em direção ao Software Livre.

O fato é que se você fornece software proprietário para rodar em uma plataforma livre, você vai descobrir um novo tipo de cliente. Um cliente que começa a gostar da idéia de ter independência de fornecedor. Não se trata aqui de guardar um catatau de códigos fontes do fornecedor na gaveta. Trata-se da opção de não ficar amarrado a um fornecedor para o resto da vida.

Este é o tipo de liberdade que muitos fornecedores de software proprietário não gosta. Afinal, se é verdade que o lucro no mercado de software advém de serviços e não de licenças, ter o monopólio na prestação de serviços em algum nicho é um grande negócio. Se você usa Java, você pode escolher o SO que desejar e SGDB de sua preferência para rodar a sua aplicação. No entanto, se você utiliza o Oracle Application Server, que utiliza o Java e o Apache, você só pode utilizar o SGDB Oracle e só a Oracle pode lhe dar suporte. Você vai encontrar fenômeno semelhante se você utilizar o WebSphere da IBM. Imagine agora que você resolve implementar uma solução de um fornecedor de ponta a ponta? Há fornecedores que podem lhe prover servidores, SO, SGDB, Web Server, ERP, BI e o que mais você possa imaginar. Bom, se você fizer isso, é melhor comprar um bom lote de ações desta empresa, pois você estará tão preso que é melhor ser sócio dela.

Conclusão, se você quer que um fornecedor de software proprietário seja homologado numa plataforma livre, você deve ter muita bala na agulha, caso contrário, o fornecedor dificilmente lhe dará ouvidos.

8 respostas

  1. Gostei muito do post, especialmente a parte da discussão dos “argumentos”. Queria sua autorização para alterar um pouco o texto, tornando-o mais genérico (não tão voltado ao problema do Sr. Fernando França e o PG) e publicar esta nova versão em meu site.
    Escuto com frequencia estas questões em meu dia a dia com os clientes.
    Parabéns pela clareza e oportunidade de seu texto.

  2. Fabio.
    Te agradeço muito a força, atenção com esse ótimo artigo. Em casos como esse, vemos a diferença do que trabalhar com SLA e trabalhar com software proprietário.
    Considero muito negativa a postura como a dessa empresa que tenta justificar sua falta de interesse e descaso pela plataforma aberta com argumentos como os citados.
    Continuo aqui na luta para ver o que será decidido sobre a solução ERP aqui na empresa.

  3. Pelo quadro, dá pra imaginar que a fornecedora de ERP só pode ser a Microsiga, que coloca o postgresql como suportado, mais faz de tudo pra enfiar goela abaixo do cliente, um oracle ou sqlserver da vida (parceiros de vendas deles) e poe meio mundo de dificuldade pra suportar o postgresql (isso se chama concorrencia desleal).

  4. Realmente, problemas como esse não são difíceis de encontrar. Bom vai ser o dia que essas empresas entenderem que software livre não é só uma “alternativa”, mas também um modelo de negócios.

    Eles acham que só porque o software é gratuito, só clientes que não tem dinheiro vão querer utilizar. E assim, acabam fazendo uma implementação medíocre e acabam descontinuando o suporte porque “não querem mais gastar dinheiro com software de graça”.

    Ainda bem que, mesmo que lentamente, isso está mudando…

Deixe uma resposta