O que me intriga é que a Oracle não é tradicionalmente uma empresa de serviços. Ela costuma desenvolver e vender produtos, e a prestação de serviços é feita através de parceiros, como a Concrete por exemplo. Não consegui ter ainda a visão de como essa aquisição vai se encaixar dentro da estratégia da Oracle.

Não sei bem também como será a relação da Oracle com Open Source. A Sun não vinha tendo resultados financeiros muito bons, mas mantinha muitos projetos open source importantes, como o Glassfish, Solaris, MySql, stack SOA e vários projetos Java em geral. Além disso, desempenha um papel muito importante no desenvolvimento de linguagens dinâmicas para a JVM, além do desenvolvimento da própria JVM.

Se em termos de software tenho várias dúvidas, em relação às ofertas de hardware da Sun eu já consigo ter algumas idéias. Um dos principais concorrentes da Oracle é a IBM, que tem um braço bem forte de hardware. Não é raro a IBM ganhar concorrências com a Oracle “dando” o hardware, e vendendo o software. A Oracle não tinha condições de oferecer uma proposta equivalente, mas agora isso será possível.

Além disso, a Sun anunciou recentemente sua oferta de Cloud Computing, que pode ser um mercado que a Oracle quer entrar. Como ela já possui muitas aplicações críticas para empresas, ela pode querer oferecer estas aplicações como serviços, em uma estrutura de Cloud. Posso estar totalmente fora do alvo, mas não duvido que isto seja um objetivo da Oracle para diversificar seu modelo comercial.

Assim como em outras aquisições, muita coisa ainda não está clara, mas já temos vários aspectos para prestar atenção.

Uma questão muito importante no mercado de software é o lock-in de fornecedores, no qual os clientes às vezes se vêem obrigados a manter um fornecedor de software mesmo sem estarem satisfeitos com o serviço/produto oferecido. Discussões em torno disso são muito freqüentes quando comparamos o modelo de desenvolvimento customizado com o trabalho em torno de produtos.

Além destas duas opções já antigas, há uma terceira na moda: Cloud Computing.

Embora eu tenha certas preferências pessoais em alguns cenários, não aponto nenhum desses modelos como o mais indicado de uma maneira geral.

Quando você compra serviços de software customizado, teoricamente o seu investimento inicial será mais baixo do que comprando um produto, mas deve-se avaliar o quão produtivo é o produto, o quanto de esforço você terá para desenvolver de forma customizada, qual é o “time-to-market” desejado, ROI, entre outros fatores. Isso varia demais de um tipo de projeto para o outro, e depende do grau de commoditização dos produtos e do conhecimento do domínio.

Além destes fatores, o lock-in é uma característica importantíssima que deve estar sempre na cabeça das pessoas. Existe uma tendência a achar que o fato de você comprar software proprietário vai necessariamente te prender a um fornecedor. Dependendo do cenário realmente existe uma dificuldade enorme em trocar, mas em outros casos isso é bem mais tranqüilo.

A questão é que com software customizado isso também ocorre muito. Software customizado pode amarrar o cliente até mais do que um produto comercial, dependendo de como for construído, e da participação do cliente no processo.

Sobre Cloud Computing, existe uma enorme febre nesse momento. Todo mundo falando em colocar aplicações “na nuvem”, nos ganhos de custo-benefício, na escalabilidade, e muitas outras “ilidades”. A proposta realmente é tentadora. Você rodar suas aplicações numa infra-estrutura gerenciada por experts do Google, da Amazon ou da Sun parece um sonho realizado. Se você pensar que eles compram hardware muito mais barato que a gente e já têm enormes parques tecnológicos com capacidade ociosa, praticamente fica impossível argumentar contra isso.

Para muitas empresas isso pode realmente fazer sentido. Colocar “na nuvem” serviços que não sejam muito críticos, para empresas de porte limitado. Agora, vamos pensar em empresas que já têm uma enorme gama de aplicações em produção, em datacenters existentes, com políticas de segurança, privacidade, etc.

Será que seria fácil e conveniente ligar a sua empresa “na nuvem”, expondo vários dados críticos e sigilosos, e trazendo riscos de segurança para seu ambiente? Pensem num cliente que já tem um site, uma intranet, ERP, e várias outras aplicações em produção atendendo a fins distintos.

Será que um diretor de tecnologia se sente seguro em abrir sua infra-estrutura para se integrar com redes, computadores e pessoas que ninguém sabe afirmar ao certo onde estão? Você teria certeza de que aqueles dcumentos valiosíssimos da sua proposta comercial não estariam acessíveis pelos concorrentes? Pense em quantas VPNs e configurações complexas de segurança seriam necessárias para adequação a esta nova topologia. Já não é tão sexy, não é mesmo?

Além deste aspecto, o hype em torno de Cloud Computing é tão grande que já estão sendo discutidas possibilidades de interoperabilidades entre Clouds. O mercado ainda está longe de amadurecer, e já vemos discussões comuns em mercados consolidados. Do meu ponto de vista, Cloud Computing pode ser muito interessante, mas é necessário um grau de confiança no fornecedor em níveis que eu raras vezes vi entre pessoas, e muito menos entre empresas.

Depois de tantos anos, comprar software continua muito difícil, e exige um conhecimento cada vez mais sofisticado. O segredo dos projetos melhor sucedidos que eu já vi é a parceria verdadeira entre os fornecedores e os clientes. Projetos de software que dão certo são os que têm pessoas competentes, bem intencionadas e ambiciosas em ambos os lados.

Os melhores fornecedores de software aproveitam cada projeto para trazer o máximo ROI para o cliente, e então conquistar sua confiança e parceria para mais projetos no futuro. E os melhores clientes são os que agem como donos do negócio de suas empresas. Eles buscam todas as oportunidades de melhorar os resultados das empresas, e com isso alavancar suas próprias carreiras.

A Concrete, modéstia à parte, é um baita fornecedor de software. E eu estou tendo a chance de atuar em projetos diferenciados e não há nada mais contagiante para um profissional de software. Estou tendo a chance e a responsabilidade de trazer resultados expressivos para a empresa, e se eu for realmente competente isso trará muitas vitórias para a empresa e para mim (bom, pelo menos eu espero.. ).

Faca nos dentes, sempre em frente

Na minha opinião, a Sun fez e vem fazendo um excepcional trabalho mantendo a plataforma Java como um todo. O problema todo está no contexto que girou em torno disso.

Em um determinado momento a Sun lutava bastante contra a Microsoft e suas soluções Windows/.NET, e de fato parecia que as empresas seriam adversárias. O que ocorre é que a Sun gastou tantas energias combatendo a Microsoft que não dedicou o esforço necessário para conquistar espaço dentro do próprio mercado Java.

O Glassfish V2 foi o primeiro bom servidor de aplicações da Sun, mas ele chegou bem tarde. Muito antes a BEA e a IBM já tinham um vasto portfólio de produtos Java Enterprise, e servidores de aplicação bem melhores do que o antigo Sun Application Server. Com isso, mesmo com o enorme sucesso da plataforma Java, a Sun não estava muito bem posicionada no mercado de software.

Creio que em decorrência deste primeiro problema (a falta de um bom app server), veio o problema que eu acho o mais grave. Na minha opinião o que fez mais falta à Sun é um bom modelo de serviços em torno da plataforma que ela desenvolveu tão bem. A Sun tem muitos grandes engenheiros, mas não conseguiu traduzir isso em muito lucro com Java. Penso que um modelo de serviços semelhante ao da IBM teria sido adequado à Sun, mas para isso eles precisariam de um portfólio de produtos melhor.

O grande (e bem-sucedido) esforço no desenvolvimento da plataforma Java consumiu energias que poderiam ter sido aplicadas na construção de uma linha de produtos mais rica, e com isso o sucesso do Java acabou drenando muito da saúde da Sun.

Mais recentemente a Sun tentou mudar a sua estratégia, e passou a abraçar ainda mais o modelo open-source. Embora isso tenha sido muito bem recebido pela comunidade de desenvolvedores, não podemos dizer que essa mudança tenha trazido mais sucesso para a empresa.

Eu tenho a clara impressão de que a Sun abraçou este modelo sem ter muita noção do que a esperava, mas talvez a sensação fosse de que não havia uma outra alternativa óbvia. A verdade é que a Sun está há anos lutando, mas sem encontrar a estratégia correta. O modelo de negócios em torno de open source foi mais uma tentativa da empresa, mas não estou vendo muitas perspectivas da Sun conseguir deste modelo as receitas necessárias para cobrir seus custos.

Eu fico triste por essas dificuldades da Sun, pois eles fizeram um excelente trabalho desenvolvendo a plataforma Java, mas isso custou a própria saúde da empresa.

E o que poderá vir em conseqüência? Difícil dizer, mas me parece inevitável que a Sun seja comprada por um player de maior porte, como a HP ou a SAP.

Como a Oracle agora é um concorrente direto da SAP em várias linhas, e a SAP começou a investir em Java, talvez faça sentido que a gigante alemã compre a Sun.

Quanto à HP, seria um movimento muito mais coerente do que a compra da EDS, que ocorreu esse ano. Comprando a Sun, a HP teria a stack completa, com hardware HP, sistema operacional e middleware da Sun, e serviços provenientes da EDS. Isto a deixaria em situação semelhante à da IBM, e acho que faria sentido nesse contexto atual.

Não sei qual será o futuro da Sun, mas sinceramente torço muito para que seja próspero, pois seu legado de contribuições ao cenário mundial de software é valioso demais para que a empresa tenha um final agonizante.

Na Globo.com eu trabalhei muito com open source, e estava acostumado a montar as aplicações a partir de componentes “crus”, em vez de usar ferramentas sofisticadas. Open source faz parte da cultura da empresa, e tínhamos uma boa liberdade de escolha de tecnologias e arquiteturas.

Como falei algumas vezes no passado, nós migramos boa parte da arquitetura legada com EJBs para serviços REST usando por baixo o Jersey, Spring e Ibatis. A produtividade no desenvolvimento de serviços REST me agrada muito, e mesmo alguém que não conheça muito de serviços REST consegue desenvolver um serviço sem tanto esforço.

Agora vou trabalhar mais com serviços SOAP, mas usando ferramentas muito produtivas, como o Aqualogic ESB e o Workshop, entre outros. Essas ferramentas facilitam muito o trabalho oferecendo Abstrações Opacas. Como ainda estou muito ligado ao trabalho com Open Source, eu venho tentando no meu tempo vago encontrar ferramentas open source com a mesma proposta.

Neste momento estou tentando encontrar a maneira mais produtiva de se trabalhar com web services SOAP usando open source. No passado eu desenvolvi serviços com o XFire, com o Axis 2 e com o JAX-WS, mas achei interessante reavaliar as opções existentes atualmente.

Nos últimos dias eu fiz testes com o Axis 2, com o Apache CXF e com o JAX-WS.

Eu não gosto muito do Axis 2. Você até consegue desenvolver serviços rapidamente com ele, mas ele gera um código tão sujo que é muito triste colocar qualquer coisa em produção com ele, sabendo que você vai ter que manter depois aquele código. Além disso, para utilizá-lo você precisa levar nada menos que 51 jars para sua aplicação, o que transforma qualquer aplicação em um mastodonte. Um outro problema dessa lista massiva de dependências é que a chance de uma aplicação pré-existente ter conflitos de dependências com o Axis é grande.

Na prática, eu só utilizaria o Axis 2 (e mesmo assim com má vontade) para desenvolver serviços se fosse numa estrutura como o WSO2 Web Services Application Server, que é um servidor de aplicações “dedicado” a serviços Axis.

O Apache CXF oferece um “front-end” com JAX-WS (que é o mais recomendado) e um “front-end” alternativo, que usa o Aegis Databinding. Por enquanto olhei apenas o front-end com JAX-WS, mas não vi nenhuma vantagem em utilizar o CXF em vez da implementação de referência presente no Glassfish. Se pintar disposição eu darei uma olhada no front-end com Aegis Databinding, mas por enquanto não tenho grandes expectativas em relação a ele não.

Para finalizar, fiz muitos experimentos com a implementação de referência do JAX-WS, embutido no Glassfish V2. A forma de trabalho que achei mais produtiva nestes meus testes foi desenvolvendo com JAX-WS no Netbeans (utilizei a versão 6.5).

Tentei desenvolver a partir de classes Java, e a partir do WSDL, e esta última me trouxe melhores resultados.A melhor forma que achei foi começar desenhando os schemas XML com o editor do Netbeans:

Criei um Complex Type para cada classe de domínio, e 1 Complex Type para o Request de cada operação e 1 Complex Type para o Response de cada operação. Tendo feito isso, criei depois 1 Element para o Request de cada operação e 1 Element para o Response de cada operação. Com o schema XML criado dessa forma, criei em seguida o WSDL, com o editor do Netbeans também:

Na criação do WSDL, coloquei nas mensagens de Request/Response das operações os Elementos declarados no schema XML anterior. É importante prestar atenção nisso. Usando Elementos nas mensagens, você está criando serviços no modelo Document/Literal. Se você colocar nas mensagens um Complex Type diretamente, em vez de colocar um Elemento, você estará criando um serviço no modelo RPC/Literal. Eu particularmente prefiro Document/Literal, e o código gerado pelo JAX-WS neste modelo me agrada mais.

A implementação do serviço com JAX-WS ficou parecida com isso aqui:

package org.brunopereira.cadastro;
import javax.jws.WebService;
import org.brunopereira.schema.cadastroclientes.CadastroClienteRequestType;
import org.brunopereira.schema.cadastroclientes.CadastroClienteResponseType;
import org.brunopereira.schema.cadastroclientes.Cliente;
import org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType;
 
@WebService(serviceName = "CadastroClienteService", portName = "CadastroClientePort",
endpointInterface = "org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType",
targetNamespace = "http://brunopereira.org/wsdl/CadastroCliente",
wsdlLocation = "WEB-INF/wsdl/CadastroCliente/CadastroCliente.wsdl")
public class CadastroCliente implements CadastroClientePortType {
public CadastroClienteResponseType cadastrarCliente(CadastroClienteRequestType request) {
System.out.println("Cadastro de cliente foi invocado!! Será feito o roteamento para o serviço adequado!!");
Cliente cliente = request.getCliente();
CadastroClienteResponseType response = new CadastroClienteResponseType();
response.setCliente(cliente);
return response;
}
}

O código do cliente foi gerado bem facilmente a partir do WSDL também, e ficou bem limpo. O que achei bem fraco foi a parte de teste dos serviços tanto no Netbeans como no Eclipse. No Eclipse você só consegue usar os plugins de teste se você tiver desenvolvido os serviços dentro do Eclipse, o que inviabilizou o meu uso. E o Netbeans tem um suporte que só serve pra HelloWorld, pra aqueles serviços de Calculadora, que você passa uns parâmetros primitivos e recebe um resultado simples. A interface do testador do meu serviço ficou dessa forma:

Dá pra ver que não serve para nada além de um HelloWorld basicão.

Bom, de uma maneira geral, o suporte a Web Services no Netbeans é muito melhor do que no Eclipse, que pra piorar só suporta a criação de serviços com o Axis. Até agora a maneira mais produtiva que encontrei de trabalhar com serviços SOAP foi essa que descrevi. Nos próximos dias olharei o que tem de interessante no projeto Metro e no JBoss ESB. Se encontrar coisas interessantes falarei mais por aqui. Ah, e se alguém tiver dicas para melhorar esta forma de trabalho que descrevi, por favor me avisem, pois estou avaliando muita coisa e não dá tempo de dedicar tanto tempo a cada opção dessas.

What I liked the most about the test was that many questions presented different problems and requirements, and asked me to give the most suitable solution. Besides that, most of the design patterns questions were contextual. Based on a given problem, I had to decide which patterns could help in the design of a good solution for the problem. I liked the fact that these questions made me THINK much more than REMEMBER stuff. There were a few questions focused on specific pattern details, but fortunately they were only a small portion of the exam.

There are many EJB/JPA questions in the exam, but if you’re familiar with the technologies, you should have no problem with them. The questions were not tricky. If you know the main aspects of these technologies, you’ll be just fine.

There were several Web Services questions, actually more than I expected. I liked this, because such knowledge is very important for any enterprise architect, and I’m particularly interested in the subject. I have a reasonable experience with web services, and I thought the questions were not very demanding.

The exam objective that I thought was my weakest was security. I didn’t know much about the JVM Security prior to this exam, and now I’m still no expert, but I did learn a few things.

Overall, I thought this was a nice exam and definitely it was more pleasant than I expected. I had 120 minutes to do the exam, but it took me around 80 minutes to finish it. The SCJP and SCWCD exams were more tiresome than this one. When I finished the exam, I wasn’t sure if I had passed, but the same thing happened to me in the SCJP and SCWCD exams, and I did ok.

There are 64 questions in the exam, and the minimum score to pass is 57% (37 questions). I answered 49 questions correctly, which translated into a 76% score.

Now I must checkout the Part 2 Assignment, and design an application during a 1 year span. I definitely won’t touch anything this year, because I must chill out. I hope Part 2 gives me more pleasure than Part 1, and hopefully I’ll learn a few more things.

If anyone’s planning to take this exam and want to talk about it, feel free to contact me, and I’ll try to help.

Foi uma ocasião muito legal. Além de conhecer a rapaziada do grupo, eu também conheci a cidade de Fortaleza e já voltei para casa querendo retornar mais vezes ao Ceará. Do CEJUG eu conheci o Rafael Carneiro, Silveira,  Milfont, Tarso, Rafael “Foquinha” Ponte, Handerson, Igo, René, Paulo, Tales, Marum e mais alguns que eu esqueci o nome

Como eu já esperava o pessoal me recebeu muito bem e foi muito bacana conhecê-los pessoalmente. Além disso, já sou agora conhecedor de uma vasta gama de termos genuinamente cearenses   Diabéisso maxo!

Além de conhecer o pessoal do CEJUG, também tive a oportunidade de conhecer o Maurício Leal e o Kohsuke, ambos da Sun. Ambos são muito simpáticos e me passaram uma idéia legal de bastante coisa que está rolando na Sun.

O Kohsuke é também provavelmente o cara de mais prestígio técnico que já conheci, pois é nada menos que o criador do Hudson e um dos principais responsáveis pelo JAXB e pelo Glassfish v3. Inclusive uma das coisas mais marcantes da participação dele no evento foi trazer a todos o desejo de conhecer melhor o Glassfish e acompanhar as grandes novidades prometidas para esta nova versão. Uma das coisas que mais me interessou é a arquitetura modular com o Osgi. Eles estão apostando no Osgi junto com o Eclipse, e isto me trouxe a curiosidade de conhecer mais detalhes da tecnologia.

Bom, para destacar ainda mais a hospitalidade do pessoal, eles ainda me deram uma cesta recheada de ítens característicos cearenses. Gostei bastante dos presentes e quem quiser degustar a mais pura Ypioca aqui no Rio é só falar comigo

O evento em si foi bem legal e ainda teve uma banda animando o intervalo. Os coitados deram o azar de tocar logo na hora que o povo foi correndo comer, mas quem ficou assistindo curtiu bastante

Depois das palestras, bastante gente foi na confraternização e a bagunça lá foi até depois de meia-noite.

Para finalizar, eu gostaria de agradecer a todo o pessoal da organização lá em Fortaleza e também ao Gaúcho e ao Hildeberto por fazerem um evento tão legal e continuamente levar o CEJUG às cabeças. Esse tipo de comunidade traz uma enorme força ao mercado de software nacional e seria excelente que tivéssemos outros grupos com tanta energia como o do Ceará. Agradeço muito pela oportunidade e deixo meus parabéns à comunidade de software cearense!

Com isso, até o momento o EnterpriseDB já recebeu no total US$ 37,5 mi, o que é bem próximo dos US$ 39 mi que o MySql havia recebido antes de ser comprado pela Sun. Torço para que isso ajude bastante no desenvolvimento do banco de dados e que eles consigam trazer ainda mais qualidade aos seus produtos. O Postgresql é um banco open source muito maduro e confiável já há muitos anos e o EnterpriseDB adiciona recursos interessantes para grandes empresas. Entre as principais forças do EnterpriseDB está a sua garantia de compatibilidade com código feito para o Oracle. Eles garantem por contrato que a sintaxe SQL, tipos de dados, packages, stored procedures, trigger e views desenvolvidas para o Oracle irão funcionar conforme esperado no EnterpriseDB. Isto sem dúvida é um facilitador para empresas que possuam grandes bases Oracle e queiram progressivamente migrar seus bancos de dados.

Eu usei pela primeira vez o Postgresql no começo de 2003, e sempre o considerei melhor que o Mysql. A principal razão pela qual o Postgres perdeu espaço para o MySql foi o fato de que o Postgres não tinha um instalador nativo para Windows antes da versão 8.0, que saiu em janeiro de 2005. O MySql tinha muito menos funcionalidades e confiabilidade, mas como era fácil utilizá-lo no Windows, sua adoção aumentou rapidamente.

Eu ainda considero o Postgres melhor do que o MySql e ele é o meu banco de dados preferido quando eu tenho a liberdade de escolher. Espero que eles continuem desenvolvendo bastante o produto e recebam mais investimentos. Eles merecem um ótimo lugar no mercado de bancos de dados, e torço para que eles consigam tanto ou mais sucesso que o MySql.

Aproveitando esta discussão, algo que me veio à cabeça diz respeito à consolidação das pilhas de produtos no mercado. Será que faria sentido que a Red Hat comprasse o EnterpriseDB e a Oracle comprasse uma distribuição Linux?

A Sun atualmente possui a pilha completa, indo do sistema operacional até o middleware Java, e inclui um banco de dados (MySql). A IBM não vende mais sistemas operacionais próprios (até onde sei), mas suporta bastante o Linux e tem seu banco de dados e o middleware Java EE.

A Oracle tem tudo menos o sistema operacional, especialmente depois da compra da BEA. A Red Hat tem tudo menos o banco de dados. Ambas fizeram compras significativas no passado. Será que veremos as 2 empresas completando sua pilha de produtos em breve?

Isto é algo que eu gostaria de saber, e seria bem interessante ver como o mercado se comportaria depois de tais movimentos.

Os 2 projetos são complementares, já que as funcionalidades de ambos não tem muitas interseções. Ontem o Marc Hadley, um dos principais desenvolvedores do Jersey postou sobre um desenvolvimento que ele está fazendo, usando o Jersey e o Abdera em um projeto de web services Restful. No post do Marc Hadley ele menciona que utilizou os recursos HTTP do Jersey (como mapeamento de URIs em classes e métodos e a capacidade de manipular diversos content-types) juntamente com as funcionalidades do Abdera de manipulação de recursos Atom.

Esta iniciativa foi muito bem recebida pelo James Snell e pelo Dan Diephouse (fundador do XFire), que são os principais desenvolvedores do Apache Abdera. O desenvolvimento destes dois projetos vem trazendo enorme amadurecimento aos web services REST e hoje já é possível desenvolver web services neste formato com grande produtividade e poder.

Claro que os projetos ainda estão em um estágio intermediário de desenvolvimento, mas é deles que virá a adoção mainstream com maturidade desta linha de serviços. Estou acompanhando continuamente o que está sendo feito nesta área, e o que já pude ver até agora é fascinante.

A propósito, os dois projetos são open source e os principais envolvidos fazem parte de empresas como a IBM, Sun, Mulesource, entre outras. O desenvolvimento de software open source é hoje em dia a principal forma de desenvolvimento da vanguarda da tecnologia mundial. As empresas já perceberam o sucesso do movimento e estão apoiando firmemente o mesmo. Não posso deixar de registrar minha profunda satisfação com isso.

Em relação à compra da BEA, espero que a abordagem da Oracle seja abandonar suas linhas de produtos Java e seguir a liderança da BEA nessa área. Os produtos Java da Oracle são infinitamente inferiores aos da BEA, e com esta compra teremos a Oracle com um novo braço tecnológico de muito vigor.

Uma aquisição deste porte ainda demorará algum tempo para demonstrar suas conseqüências, mas agora o pessoal da BEA terá poder financeiro para atuar ainda mais na vanguarda com seus produtos. Seus já excelentes produtos de SOA, BPM, Java e integração com certeza receberão investimentos maiores que os atuais e isto pode interferir nos rumos do mercado, pois agora a Oracle estará muito forte em áreas nas quais ela corria atrás dos outros players.

Muitas perguntas e incertezas surgem em função destas significativas aquisições de hoje, e uma pergunta interessante foi lançada pelo Savio Rodrigues : Quando a Oracle vai comprar a Sun? E pergunto eu: será que a HP não poderia comprar a Red Hat por exemplo?? Nesta consolidação do mercado, muitas coisas interessantes estão por vir. Como desenvolvedor Java, torço para que ambas as aquisições dêem ainda mais anos de sobrevida à plataforma e à linguagem Java. Let’s wait and see

Ainda é difícil saber que impacto isto terá no mercado de uma maneira geral, mas podemos esperar um bom progresso do MySql e torcer para que ele continue com seu modelo open source de muito sucesso. Eu particularmente penso que ambas as empresas têm muito a ganhar com esta compra e que isto trará ainda mais força para o movimento open source.

Quando será que alguém vai comprar o excelente PostgreSql também??