Aplicações Comerciais utilizando o PostgreSQL
Esse é o artigo escrito pelo Sr. Fabio Telles, do PostgreSQL Brasil, em seu site (Savepoint) sobre o recente problema com o qual me deparei. É um caso que podemos chamar de clássico e recomendo a leitura a todos já que o texto coloca muito bem essa questão. Aproveito para agradecer a ele e a todos da comunidade de software livre e aberto.
Trecho: “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. (…)”
Enviado por Fernando França (fernandoΘdesconstruindo·eng·br) – referência (midstorm.org).
@brlinuxblog
Feed RSS
É a mentalidade típica de quem vende aplicativos proprietários e acontece exatamente a mesma coisa quando vendem uma solução envolvendo somente softwares proprietários. O fato de usarem o Postgresl ou mesmo um linux como parte da solução que vendem para eles é meramente uma questão de economia de custos e mesmo assim quando o cliente pede muito, porque na maioria das evzes eles gostam mesmo é de vender produtos dos “parceiros”, onde ganham umas comissões e vantagens.
Aqui no Brasil (e creio que na maioria dos países também) a mentalidade da maioria das software-houses é empurrar soluções proprietárias do alto a baixo, mesmo que aumente brutal e desnecessariamente o custo total da solução. Quando o cliente não tem grana para regularizar completamente a solução eles empurram o problema para o cliente mas ao mesmo tempo alguns ainda têm a coragem de sugerir soluções envolvendo a pirataria ou uso indevido de licenças acadêmicas, domésticas ou para desenvolvedores dos softwares. Falo isso porque já me sugeriram essas coisas.
Mas ao mesmo tempo os gerentes de TI adoram ler aquelas revistas de TI para executivos e enchem a boca para dizer que a solução que adotaram envolve produtos das grandes empresas de software proprietário. Dizer que resolveu com softwares livres por uma fração do preço e com a independência do fornecedor não dá muitos créditos na hora daquelas eleições ridículas de personalidades de TI que algumas revistas publicam todo ano. Lembram daquele gerente de TI idiota do Pão-de-Açúcar que não usaria linux nem com um .38 na cabeça ?
Quantas vezes a gente não vê um software de versão x.y que sua empresa comprou ser certificada apenas para o windows versão ABC e o banco de dados proprietário DEF versão G.H ? E muitas vezes a gente fica esperando eternamente uma versão nova que suporte as versões mais novas desses requisitos ? E, quando existe, é preciso ainda pagar um upgrade que custa 80% de uma licença full ?
Por isso sou a favor de sistemas livres ou que pelo menos o fornecedor entregue o código-fonte para você ter como adaptá-lo às suas necessidades ou possa continuar a usá-lo no caso de uma insolvência do fabricante.
Achei o título do post aqui do Br-Linux meio desfocado com o assunto, mas tudo bem.
Sobre o artigo em si, excelente, serve como uma referência quase que perfeita para rebater os típicos argumentos repletos de FUD de gente que resiste a qualquer solução em Software livre.
O problema não é esse. Trabalhei muitos anos em empresas que vendem soluções prontas. O custo de dar manutenção em várias versões de banco e de sistema diferentes é alto, por isso tem de tomar cuidado com atualização de versão, mesmo de releases. Por isso, mesmo com softwares livres, tínhamos suporte contratado de empresas para facilitar. Mas quando não existia empresa que oferecia suporte, tem de ser cauteloso.
Imaginem sua empresa com 80 clientes em várias cidades e estados diferentes. Alguns vão atualizar o banco de dados, outros não vão. Alguns vão instalar uma distribuição de Linux, outros vão instalar outra. Daí você vai montar o upgrade de versão pro cliente e vai funcionar no cliente X mas não funcionar no Y. Você não tem a mesma versão que ele instalada, vai ter de preparar um ambiente de homologação equivalente, adaptar o script (ou fazer vários). Se o cliente tiver dúvida na configuração do sistema, ou se a configuração sua conflitar com alguma aplicação dele, você vai ter de oferecer o suporte…
E a cada versão lançada, o problema se multiplica, porque no mundo real nem todo mundo se mantém atualizado.
Por isso
Concordo com você em parte Marcos, mas acho que o foco nesse caso gira em torno do fato da empresa em questão, se apresentar como suportando essa plataforma, o PostgreSQL, e no fim das contas, agir com descaso.
Gostaria de lembram também, que a empresa em questão não é nenhuma instituição de caridade, visto que em minha empresa, pagamos especificamente uma taxa denominada: “atualização tecnológica”…
Mas aí, acredito que o papel da empresa seria adotar (considerando que seja uma distribuição linux) uma distribuição padrão. A exemplo, debian. desse modo, todas as atualizações de versões do postgres do debian passariam a ser suportadas pela empresa.
Entretanto, muito melhor seria se fosse software livre mesmo.
eu acho que é assim que tem que funcionar também ‘llp’.
não da pra vender uma solução que vai depender do sistema instalado ter ou não X versão do postgresql, o ideal é vender um padrão, ou exigir no minimo (como a empresa em que trabalhei fazia) versões para os pacotes, e antes de fechar o contrato e tdo fazer o teste para garantir que funciona.