Flight of the Conchords November 27, 2007Posted by Sacha in /dev/null.
Not sure if you know the band “Flight of the Concords”, they are very good and very funny.
You can find many of their filmed performances on Google Video, here is a good one:
- But do you remember what you said to me?
- Not word for word actually, Jenny, but I remember there were some verbs…
And if you are a true romantic, this one is for you:
Who is (really) driving Eclipse? November 16, 2007Posted by Sacha in IT, JBoss.
There’s recently been a lot of interesting news about Eclipse.
First of all, the Eclipse Foundation has been elected on the SE Executive Committee of the Java Community Process (JCP). A few years back, nobody would have guessed such a thing could happen (not simply that of being elected – but that they would actually run for the election in the first place). It is going to be interesting to see what role the Eclipse Foundation intends to play on the JCP-EC given that more than half of the existing EC members are already members of the Eclipse Foundation (BEA, Borland, Fujitsu, Google, HP, IBM, Intel, Oracle, Red Hat, SAP, SAS), and 8 of them are … Eclipse Strategic Members (8 out of 20!). What is the agenda that the Eclipse Foundation wants to promote that existing EC+Eclipse members don’t? What is the disconnect that Eclipse intends to address?
Then, there is this “Eclipse Runtime Summit” taking place next month in SFO. The proposed goal of the summit is to “Define a strategy how the Eclipse Foundation will deliver runtime technology”. Runtime technology? That’s very interesting. I thought Eclipse was about tooling, not runtime. At least, that’s what I remember was communicated in 2001, when they formed their first board:
Chicago—Nov. 29, 2001–Borland, IBM, Merant, QNX Software Systems, Rational Software, RedHat, SuSE, and TogetherSoft today announced the formation of Eclipse.org, an open consortium of providers of development tools that manages the Eclipse Platform, which is being made available in open source under the Common Public License1. These companies, each of which plans to release Eclipse Platform compatible product offerings, form the initial Eclipse.org board of directors. The bylaws and operating principles of the organization are published at http://www.eclipse.org.
Many companies have participated to the success of Eclipse and helped build its brand and credibility. They did it to solve a specific pain-point this industry was facing at that time: the lack of a common platform on which to build tooling. Now, it seems “some” think that the Eclipse Foundation should move in the “runtime and platforms” space. I find it surprising and wonder if this is really its mission and the reason for what its founding members intended it.
Now, if some companies wants to step up to build and fund a new “runtime&platforms” Foundation, work on building its brand and credibility, that would be a very different story. But hijacking the Eclipse Foundation for this is a pretty aggressive move that seems disconnected from its members.
RHEL just tripled the size of its ISV ecosystem! November 14, 2007Posted by Sacha in IT, JBoss.
Red Hat (RHT) made several important announcements this week: the launch of its “Linux Automation” strategy , ,  and . While the related media coverage was pretty good, most articles perceived it much as a tactical announcement, while it was in fact a very strategic one. Let me show you why.
But first of all, some history… Picture a planet where “Linux” would be a mere kernel and Linux users would pretty much run their own customized distribution, picking up the packages they want and hoping these will work together properly. Now, imagine some big ISV out there, let’s say Oracle, wanting to sell and support its database on “Linux”. How would they do that? ORCL would not only have no way to make sure their database would run on all these custom Linux installations, but they would not even be able to make sure it installs properly! The huge diversity of possible packages and setup would make it a non-starter. Well, that planet did actually exist before the Linux distributions appeared, but it didn’t last long. Once the first distributions appeared, it became possible for ISVs to target a “specific Linux” (API’s, set of packages, directory structure, etc.): Linux was no longer a “big everything”, it became a set of clearly identified distribution brands and versions, each targeting a specific set of packages and API’s. The obvious consequence was that ISVs wouldn’t simply migrate their application to some random “Linux”, they would do it against a clearly identified/branded distribution; this would lead to predictable installation and runtime behaviour. Distributions enabled Linux as a first class Enterprise-OS citizen.
What do you want to run today?
Now, if you look at the profile of the lambda Linux user, that person is most probably not developing applications that directly execute against the kernel API. Instead, that user is mostly installing third-party applications (databases, DNS servers, file servers, ERPs, JVMs, etc.) Consequently, chances are high that, as a user, you are going to elect as your prime Linux distribution the ones that propose the highest number of certified third-party applications => having the largest ISV ecosystem.
While it would be wrong to over-simplify the reasons that led to the success of Red Hat Enterprise Linux (RHEL), one of them is pretty obvious: RHT has built the biggest ISV ecosystem of all Linux distributions (with more than 3’400 certified applications). That’s a very unique value proposal.
What will you want to run tomorrow?
So, how does the future landscape look like for Operating Systems? Well, outside of the two relatively traditional ways to run an OS today (i.e. either directly on the hardware or as a virtual machine on top of an hypervisor), it seems like two additional scenarios are growing in importance: virtual appliances and computing clouds. I’ll describe both and put them in perspective with the announcements RHT made last week.
The first scenario consists of getting your third-party applications delivered to you as a big binary BLOB: a Virtual Appliance. Such appliances consist of a pre-configured/pre-optimized ISV application deployed on a bare-bones operating system, the whole thing packaged as a virtual image that can be run on top of an hypervisor. As an end-user it means that you don’t need to care anymore about installing or optimizing an OS for a specific application or applying a proper set of OS patches for that application; the OS *is* the application. While that model delivers obvious value, it also comes with some threats:
- OS Jungle: the invasion of your IT by random “hidden” operating systems that sneak in through the deployment of virtual appliances. At the end of the day, embedded in an appliance or not, operating systems need to be maintained and supported (and security holes patched). And that’s a job in itself.
- Customizability: ISVs will want to make sure their Virtual Appliance is as efficient as possible and will not want a complete OS if a subset will suffice. A subset means a reduced binary image, but also means less OS patches, hence less downtime.
The first threat leads to the conclusion that OS vendors are the ideal Virtual Appliance OS providers: they avoid proliferation of zillions of random OS and ensure that you get your patches from a single, unified and trusted source. One of RHT’s announcements last week covered that exact scenario: Red Hat not only announced the availability of a highly customizable and supported OS for virtual appliances, but – and this is the cherry on the cake – that this OS is … RHEL itself.
The bottom line is that all ISVs that are certified on RHEL today could decide to provide a Virtual Appliance of their certified application tomorrow with no migration work required: the OS is the same one, coming with the same support (and with specific tools). Now if you compare RHT with other vendors in that field, RHT has some key advantages. For example, compared to a MSFT, RHEL is a truly embeddable and customizable OS: there is no need for a specialized OS that would only increase the ISV’s costs to enter the Virtual Appliance era.
The second scenario, cloud computing, pushes to the extreme the notion of virtualization. With virtualization, you are decoupling the physical hardware from the OS instance. With cloud computing, you are decoupling the physical servers from your CAPEX: you don’t need to buy servers. Instead you are going to rent them (pay-per-use). When is that useful? For example, when you have CPU-intensive tasks that must run very infrequently, such as running some Business Intelligence on your company’s data on a quarterly basis or if you predict your online business will have to go through some exceptional event: instead of buying a multitude of servers that will stand idle 350 days a year, you push your virtual instance images to tens or hundreds of servers “in a computing cloud” that you rent by the hour. While this mode of deployment might not fit all scenarios (because of the way the data is structured, for example, or for privacy concerns), this scenario is going to grow in usage and Red Hat must provide an answer to it.
And that is exactly what Red Hat did last week. RHT announced a partnership with Amazon whereby customers can now deploy their RHEL instances directly on Amazon Elastic Compute Cloud, aka EC2. Customers won’t be forced into an Amazon specific Linux distribution which would have a pretty much empty ecosystem with no ISVs. Instead, they will be able to snapshot their current RHEL instances and push them to EC2 for execution.
Through that series of announcements, Red Hat is lining up its complete RHEL strategy and making it clear that it can fit all deployment scenarios – traditional or emerging – through the exact same RHEL bits. That proves the flexibility of RHEL as a distribution and also factually multiplies the size of RHEL’s ecosystem by further enabling all existing RHEL’s ISV on two new emerging scenarios, Virtual Appliances and Cloud Computing. While that might seem like a trivial statement, it is far from the truth. Just look at VMWare for example: while they are getting great traction in the virtualization field, it is going to be very difficult for them to enter the two emerging fields discussed above, as they have a pretty much empty ISV ecosystem today. And you don’t build an ISV ecosystem overnight (you can partner with one or acquire one, but not build one overnight).
P.S. In a later post, I’ll focus on the cost of virtualization.
Q&A on RHT signing the Sun Contributor Agreement (SCA) November 9, 2007Posted by Sacha in JBoss.
add a comment
We announced this week that we had signed the Sun Contributor Agreement (SCA) as well as the Java SE TCK agreement. Looking at the numerous articles that popped-up left and right, very few remained strictly focus on what this announcement is really about: making sure we have a strong, high-performance, certified FOSS JVM available in Fedora and RHEL. And the OpenJDK project is the best and fastest way to get there, end of story.
If you are interested to know more details about the announcement, we have made available a Q&A interview on JBoss.org. If you have other questions that this Q&A doesn’t cover, feel free to post comments on this blog entry, I’ll do my best to answer them.
add a comment
While watching this autumn’s middleware soap opera (i.e. BEA’s hunting season), I read a few articles about ORCL’s middleware business and was impressed by Larry’s ability to spin stories (given ORCL doesn’t disclose middleware-specific statistics/numbers).
Essentially, Larry keeps telling the market that he is #2 on the middleware market and is its fastest growing player.
Oracle’s middleware new license business grew 82% in the third quarter. That is in stark contrast with BEA, which grew 8% in their most recent quarter, so we are growing ten times, more than ten times faster than BEA.
Over the trailing 12 months, Oracle’s middleware business grew on average over 60%. Again, that is in contrast with BEA’s last year where they grew 12%, so that is five times over the last year, we are growing five times faster than BEA.
Oracle’s middleware business is now larger than BEA’s middleware business, or larger than BEA. It took us a long time, over five years, to catch and pass BEA, but we did it. We did it with a combination of innovation and acquisitions and years and years of determination and endurance and again, I am very proud of what the middleware team has achieved, both in development and marketing and in sales [Sacha: “but most of all I am proud of myself”].
Not only this, but more recently he explained why “his” growth type was definitively more genuine than others:
Microsoft, with their middleware, a lot of which is embedded in Windows, Microsoft being the number 1 player, IBM being the number 2 player, and Oracle being the number 3 player in middleware. We passed all the other niche players. We really separated ourselves from the niche players. BEA, we’re almost twice as large as BEA right now, BEA is shrinking in terms of new license sales. So, it’s come down to the same big three, but we’re growing dramatically faster than our competitors and our target really is to beat IBM because it’s very difficult to measure the size of Microsoft’s middleware business because so much of it is embedded in Windows.
Who is Larry’s Coué’s Method teacher? That guy must be good (and probably the same one that updates Larry on how great his Linux toy story is doing).
Anyway, truth be told, if there is one company generating MOST of its middleware revenue on embedded business, it is … ORCL. And not from some random OEM vendor, but from … ORCL itself. Just go ask people. Outside of their own embedded applications, ORCL’s monolithic AS is pretty much invisible from end-customers. So what’s going on? The most credible theory is that most of their revenue comes from (their own) embedded applications (ERP, DB, etc.) – where customers do not really care whether they deploy on one AS brand or the other; they care about the solution running on top, not about the details of the engine. When you buy a new car, you don’t necessarily care about which tires it will have by default. Same thing here => First explanation: INTERNAL CROSS-CHARGING. What’s more, in some cases, ORCL is giving away middleware licenses to DB/App customers and mark some of the cost down to the middleware rather than the database. But from a revenue recognition standpoint, both products get their share of revenue with an identical discount rate being applied.
Then, there are additional explanations:
- GROWTH BY ACQUISITION. ORCL keeps buying middleware-related products/companies (Collaxa, Oblix, etc.). The revenue related to these acquired products directly feed into their middleware revenue and helps to hide what is the real organic growth of their core middleware offering.
- CROSS-CHARGING OF NEWLY ACQUIRED APPLICATIONS. ORCL bought non-middleware-related product companies (Siebel, PeopleSoft, etc.) and those are now slowly transitioning most of their subsystems (management, etc.) to ORCL’s middleware offerings. Again, this is pretty much like a “forced-conversion” of their products, with no real choice on the underlying platform being used. This is accounting cross-charging, not organic growth.
- GROWTH OF THEIR MAIN BUSINESSES. Given that their overall DB and Application business is growing, ORCL’s middleware business will mechanically grow as well, but again, it doesn’t say anything about the real organic growth of their business: this axis of growth is entirely dependent on their other “true” markets (DB, applications) and on cross-charging accounting.
Consequently, a lot – if not most – of ORCL middleware business is embedded and only growing artificially. Beyond that though, it is impossible to get actual metrics about its true organic growth.
Bottom line: BEA’s acquisition is probably ORCL’s only true way to acquire REAL end-customers.