Com mais de três anos lidando basicamente com servidores de aplicação de código aberto, é estranho trabalhar com software fechado. No meu projeto atual temos um problema envolvendo transações entre dois Application Servers (AS) de fornecedores diferentes. Um destes fornecedores é conhecido pela qualidade do produto, o outro pela falta desta. Para piorar, uma mistura de framework e conjunto de ferramentas geradoras de código também fechada gera os EJBs envolvidos.
O problema em questão é como os EJBs são gerados e porque determinada transação não está efetuando rollback. O fornecedor diz uma coisa…como saber se é assim mesmo? Trabalhando com software livre é fácil: basta olhar o fonte. Com nossos fornecedores a coisa complica e no final eu tenho que mantêr aberto três PDFs de três especificações Java EE e comparar com o comportamento do servidor na base do tentativa e erro. Pelo menos temos padrões!
Nós sabemos onde está o problema, más não podemos nem resolver nem ajudar o fornecedor a fazê-lo, porque não temos acesso aos fontes deste componente. Mesmo que consiga identificar, dificilmente o fornecedor vai corrigir o problema pois isto implicaria em um bugfix. Vai ficar pra próxima versão, na verdade já foi corrigido na versão seguinte mas nós estamos, como quase todo mundo, presos a uma versão específica e migrar não é uma alternativa.
No meu projeto anterior o cliente tinha suporte direto do JBoss Group (agora divisão da Red Hat). Eu já gostava muito do servidor em si e fiquei surpreso com a qualidade do suporte. Mesmo não sendo nenhuma Fortune 100, sempre fomos atendidos rapidamente e com muita atenção. Não mandam um indiano que nem tem acesso ao código nos atender, as pessoas que desenvolvem o sistema estão envolvidas diretamente e o código está a sua disposição, os patches que eles mandam podem ser inspecionados. Havia um branch da série 3.2.x personalizado para a empresa, com bugfixes que só entraram oficialmente no JBoss 4.0.
Mesmo antes de ter suporte pago, eu já resolvi muitos bugs olhando como JBoss e Tomcat são implementados. Para a maioria dos programadores parece coisa de louco, mas não é. É um programa Java como qualquer outro e as partes mais críticas geralmente não dão problemas graves. Um bom time pode facilmente utilizar esta informação apra detectar bugs mais estranhos e até enviar o patch com a correção para o projeto. A diferença é que mesmo que seu patch seja rejeitado (alguns meus já foram), você pode, ao menos, integrar no seu servidor, na sua cópia do código.
Por melhor que o suporte seja, por mais qualidade que o servidor tenha, por mais que o vendedor te leve para almoçar no Porcão, tecnologia livre te abre os olhos e é difícil fechar depois. Quem nunca teve problemas com suporte de fornecedor que atire a primeira pedra. Muitas vezes é problema interno de comunicação deles, o cara que te atende não conhece o sistema mais que você. Outras é picaretagem mesmo, os caras dizem uma coisa quando fazem outra. Me lembro de um cliente que adquiriu um certificado digital caríssimo (na época que eram muito caros) para seu site só para descobrir algum tempo depois que o servidor que eles usavam não suportava certificados, ao contrário do que dizia o folder da empresa.
Em outra ocasião um programador no meu time ficou dias discutindo no telefone com o estagiário que a empresa colocava de suporte. Nós havíamos achado o bug, sabíamos onde estava mas a empresa se negava a aceitar como bug deles, colocava a culpa na aplicação. Com a pressa de um prazo já alongado duas vezes estourando, autorizei que ele descompilasse a classe em questão e ele mandou (para a surpresa do fornecedor) um patch. Como o fornecedor era uma empresa pequena, acabaram incorporarando no produto e fazendo um release de emergência. Eles ouviram muitas piadinhas da minha equipe até o fim do projeto…
Hoje em dia software livre não é mais tabu, é uma realidade. Mais e mais empresas estão permitindo seu uso, Tomcat é onipresente e JBoss tem crescido muito (falta de suporte oficial nacional é um problema, todo contrato tem que ser com a sede, em Atlanta). Vamos ver quantas idas ao Porcão serão necessárias para vender caixas-pretas daqui há alguns anos.