Thursday, June 4, 2009

why re-write openoffice in javafx?

Sun and Oracle have been very quiet about the plans for Sun's various and diverse technologies once Oracle's acquisition becomes final later this summer. In a surprise move, Larry Ellison of Oracle appeared onstage at JavaOne this past Tuesday (June 2nd) with Sun Chairman Scott McNealy (after Jonathan Schwartz had left the stage). Larry let lose a number of insights on where he may be headed with Sun's technology portfolio. I recommend that interested viewers take a look at the last part of the 2009 JavaOne opening keynote session.

One of the specific initiatives that Larry mentioned was that Oracle/Sun will port OpenOffice to JavaFX, the new Java scripting language. Now many commentators are dissecting the import of this initiative (take a look at what Gavin Clarke had to say for The Register). Many think it is an unsound effort, but I believe that they are missing the point.

My guess at why Larry wants to port OpenOffice to JavaFX is so he can deliver it as an application service through the cloud. This is an inadvertent shot at Microsoft Office and a direct challenge to Google apps.

That's just my opinion. As an FYI, Sun spent some time during the CommunityOne conference (also held at the SF Moscone Center and just prior to JavaOne) talking about its latest cloud initiative and Sun's monster cloud at the SuperNAP data center in Las Vegas.

Friday, April 24, 2009

oracle may have lassoed the sun, but let the dolphin (and friends) swim free

On Monday, 20/April/2009, Oracle and Sun jointly announced that Sun will be acquired by Oracle effective sometime this summer. In the days following there has been much speculation about what Oracle will do with Sun's various products and technologies. There is a lot of cultural and product fit between Sun and Oracle (certainly more than Sun has with IBM), but there are a few areas in software where Sun and Oracle are significant competitors. Sun has had a lot of these relationships with other companies throughout it's history. At Sun this is referred to as coopetition. Specifically, Oracle and Sun directly compete with their relational database and Java Enterprise products.

Oracle has grown up as the provider of the de facto standard in relational database products. The Oracle Enterprise Database is used by almost every Fortune 500 company and as of 2007 controlled over 48% of the market for relational database software (according to Gartner). The product is highly proprietary -- it is the antithesis of open source software. It licenses for a price in excess of $20K per licensing unit plus support, and a typical system/application can involve more than $1 million in Oracle Enterprise licensing costs. It is the Rolls Royce of database products (with a price tag to match).

MySQL was started in Sweden and grew up in the open source community. MySQL has been a very attractive solution for most web and other deployments requiring an easy to use, reliable database with a low cost. MySQL has historically cost less than 10% as much as a like Oracle Enterprise solution. Sun acquired MySQL (the company) in early 2008 for approximately $1 billion in cash. Sun has continued to foster MySQL's open source status, and primarily sells only support and maintenance contracts around a licensed installation. [As of the date this blog entry was posted, the license cost for MySQL Enterprise is $599 per server, and a MySQL Community license is free]. The symbol for MySQL is a dolphin.

To put the cost differential into more concrete terms, you can look at a TCO calculator on the MySQL website that compares the cost of MySQL to other popular databases. The chart below shows the default values for the calculator, although you are welcome to play with the settings to suit your own situation. In the default analysis, Oracle is 16 times more expensive than a comparable MySQL deployment.


Some recent articles and comments have argued that Oracle Enterprise is far superior to and not comparable with MySQL, and therefore there is no conflict with Oracle buying Sun and taking control of MySQL. But these bloggers do not appear to have a current knowledge of MySQL. One of the key features of an enterprise database is clustering which allows a database to remain operational if a particular instance of that database or the server it is running on fails. This feature was added to MySQL with the version 5.0 release, and it was stabilized with bug fixes in the version 5.1 release in November 2008. Version 5.1 also included some other enterprise features such as query analyzer for improving performance, enterprise monitor for managing the cluster, and greatly improved scalability. This past Monday (the same day as the Oracle/Sun acquisition announcement), MySQL version 5.4 was released along with MySQL Cluster version 7.0. This release includes a number of new features, and performance and scalability improvements that clearly put MySQL Enterprise in direct competition with Oracle Enterprise. For those wanting a good overview of MySQL version 5.4, take a look at Karen Pardin's keynote address delivered last Monday (a busy day) at the MySQL Conference & Expo. The keynote is entitled "State of the Dolphin" and the complete video can be viewed at http://mysqlconf.blip.tv/file/2022181.

One of the more interesting technical analysis presented during Pardin's keynote shows the scalability of MySQL Enterprise (version 5.4) up to 60 nodes. Oracle Enterprise 11g with RAC has a limit of 100 nodes. Realistically, clustered database deployments rarely involve more than 8 nodes, with 3 or 4 being the most common.

Mark Callaghan who leads the MySQL Engineering team at Google presented another keynote entitled "This is Not a Web App: The Evolution of a MySQL Deployment at Google". You can view his keynote at http://mysqlconf.blip.tv/file/2022436/, and read his blog on High Availability MySQL at http://mysqlha.blogspot.com/. Another Google endorsement comes from Chris DiBona, their Open Source Programs Manager, who says “Google runs critical business systems with MySQL and InnoDB. The systems require 24x7 operation with minimal downtime. The systems support large OLTP and reporting workloads. We are very happy with the scalability, reliability and manageability of this software.” It is not accurate for Oracle to present MySQL as a starter database for customers who will eventually move up to Oracle Enterprise.

Most Oracle Enterprise customers are also using MySQL even if only for a lab project or experimentation. Some even use MySQL as a replacement for Oracle Enterprise in application development and testing environments and then convert to Oracle Enterprise when the application goes into production. Customers do this to save money on Oracle licenses. In the current worldwide economic situation, many Oracle Enterprise customers have been examining or are already converting to MySQL where possible. One pro-Oracle blogger has compared Oracle Enterprise to a Maserati sports car. I agree with this analogy, but would point out that most everyday driving does not require a high-priced sports car. For the price differential between Oracle and MySQL in a typical deployment, you can buy several Maseratis.

In the hands of Sun, MySQL's features as an enterprise grade product have flourished. This significantly threatens Oracle Enterprise's long-term position and especially its profit margins. My opinion (admittedly a long time coming in this blog entry) is that MySQL should remain independent of Oracle for the sake of competition and the health of the IT industry. Oracle should spin off MySQL in a separate subsidiary. Oracle can then either sell the subsidiary's shares or distribute them to its current shareholders.

Along with MySQL, Oracle should also include Sun's Java Enterprise products such as GlassFish Enterprise Server, GlassFish ESB, the GlassFish Web Stack, GlassFish Web Space Server, Sun OpenSSO Enterprise, the NetBeans IDE, the HotSpot JVM, and maybe even Java CAPs. These products all compete with Oracle's WebLogic products (including the JRockit JVM and the JDeveloper IDE), and Oracle does not appear to have any use for them (short of cannibalizing a few features). And to finish off the software stack, throw in the OpenSolaris IP.

Oracle executives held a town hall meeting at Sun's corporate headquarters on Wednesday, and most of the discussion focussed on what Oracle will do with Sun including Sun's technologies and products. While it is difficult to read the tea leaves at this point, Oracle has been fairly clear in one area: Oracle does not intend to become a cloud service provider, but will instead try and provide technology products to the cloud. If this is true, then Oracle can also put Sun's cloud initiatives into this subsidiary. The subsidiary could be called something like Moon Cloud.

From Oracle's perspective they really cannot afford to have so much open source software in house anyway lest they trip over some of the open source licensing provisions requiring them to contribute improvements back to the open source community. Most of Oracle's software is highly proprietary and Oracle doesn't need to risk stumbling into open source disclosure requirements.

Many have also speculated on the future career of Sun CEO Jonathan Schwartz. Again in my opinion, Jonathan should be made CEO of this new open source/cloud subsidiary. He comes from a software background and has been instrumental in Sun's open source and cloud initiatives. Let him continue down this path. As an amusing aside, an alias into the Sun website for its open source software initiatives is http://www.sun.com/ponytail.

I don't have any influence over Oracle's decision-making processes, much less the keys to Larry Ellison's yacht (not even the small one). And I also have no influence with the US Justice Department. But here's hoping that all of Sun's open source software products and cloud initiatives get to survive and flourish after the acquisition by Oracle is complete. And in truly independent hands.

Monday, March 30, 2009

new location

This is the new location for my blog. The old location was blogs.sun.com/dador.