Changes in the IT industry seem to happen like plate tectonics motion: in spades.

Last week, ORCL announce they had closed their BEAS acquisition. That was fast, less than four months! This probably shows that this acquisition was just a blip on the radar of ORCL’s highly exercised M&A team. As a consequence of this acquisition, the market suddenly got much simpler with one less vendor in Gartner’s magic quadrant. Given ORCL’s past claims that they owned such a big chunk of the middleware market share, some might find it surprising that the EU didn’t consider this new Frankenstein as a monopoly… It will be very interesting to see what they keep/throw away from their multiples middleware stacks. If you are a customer one of their customers, feel free to contact us, we’ll be glad to tell you all about freeing your infrastructure from vendor lock-in

SpringSource also announced their GPL3/proprietary “application server” (yes, we are in 2008). While I can understand that some of SpringSource’s execs and VCs are motivated by a quick exit strategy, I was a bit shocked by their announcement: going proprietary from a BSDish offering is quite a jump. I doubt everybody at SpringSource must be considering this move as compatible with their DNA - never go against your DNA. I predict SpringSource’s next board meetings will be pretty “energetic”. Also, their dance around OSGi was a bit disappointing. JBoss has been using a microkernel since 2001 and we know exactly why decided not to go straight with OSGi as the core of our next microcontainer, but instead provide an OSGi “personality” on top of our POJO-based microcontainer - providing much more powerful feature than a raw OSGi implementation). It seems SpringSource still need to go through that 7-years learning experience.

Last but not least, SUN announced their Q3 report and missed the street’s expectations, by quite a bit… In the same, spasm, they announced they would cut their workforce by 1′500-to-2′500 employees! Fast forward by a few days and voilà, this week at the Moscone Center (SFO, SUN hosts JavaOne, its yearly party. Bad timing, very bad timing to party.

The AS-war is over, les jeux sont faits.

Onward,

Sacha

For most of us, professional life is about meeting the next challenge, finding the “next thing” that will make you happy when you wake-up every morning (or slightly later if you are an engineer).

Last week, Ryan Campbell, our head of QE for JBoss, decided it was time for him to join the dark side and move onto the other side of the QE lab: after helping us make even stronger software, he is going back to his roots, that of code writing. Hence, bugs. Ryan joined JBoss in 2004 and has done a phenomenal job, building up our complete QE team, setting up our processes, and always fighting for what he thought was “the right thing”(c). Ryan, your future is bright! In turn, this also means that if you think you can be JBoss’s next QE-superstar (Ryan has set the bar high - no amateurs please), contact us!

At about the same time as Ryan’s change, another talent was joining our company; Rich Sharples, key individual in the Glassfish project at SUN Microsystems. He’s only been in the company for a few weeks, but I am already impressed by the quality of his work. Great ideas, fast brain, …I like that :). So welcome Rich, you are going to do great things at JBoss!

BTW, we have many other open positions, so if you are the best, you might want to consider joining us.

Onward,

Sacha

Update 1: You can read Rich’s blog here.

From SUN’s MySQL analyst call (seekingalpha.com), Jonathan Schwartz:

By our estimates around 20% or so of the deployments that we see with MySQL run on Solaris but the most important statistic there is there are about 75% of the deployments we see with Solaris don’t occur on Sun hardware. We are interested, and to some extent, you are pointing up the incredible revenue synergies that are at hand here because we can not only bring a breadth of services and technology offerings to the MySQL customer and user base but we can also bring the MySQL customer opportunity to our customer base.

I hope not to become the source of FUD on this as I really don’t see SUN trying to force MySQL customers onto Solaris, that wouldn’t be a smart move. Rather, I just wanted to be one of the first to utter the phrase “SAMP” following the acquisition

Onward,

Sacha

P.S.: “SAMP” is the copyright of Thomas Heute

Happy 2008, etc.

I haven’t been blogging much in the past few weeks: I’ve been busy working on JBoss’s plan for next fiscal year (FY09), JBoss World Orlando (4 weeks away!) and the current transformation of RHT into discrete business units. Still, today’s announcements are a good enough justification to restart blogging.

BEAS

For BEAS, it was a simple matter of WHEN and HOW MUCH, and this, despite Larry’s very subtle negotiation tactics. Now that it did happen, the WHEN doesn’t matter anymore. As for the HOW MUCH, no need to rely on wicked free cash flow models here, I bet Larry woke up one morning and simply decided that he couldn’t wait for Icahn to finish his job. He wanted his BEA. Now.

• Charles, how much did we offer last time?
• 17$
• How much did Alfred want?
• 21$
• What’s the average of the two?
• 19$, Larry…
• OK, go back to Alfred with 19$ and let’s close it
• Shouldn’t we wait for Icahn to finish his…
• Do you know where I left the keys of my boat’s hangar? I am pretty certain I left them on my desk…

Thank you for simplifying things Larry, a great help.

MySQL

(First of all, congrats to the team at MySQL, you did the right thing and hitting a 10 digits price is amazing and a great victory for OSS valuations.)

So, in the case of MySQL, it is not so much the HOW MUCH, but the WHY that I fail to fully grasp. Make no mistake, I get the good ol’ dream of the complete FOSS stack (I am also contaminated by that virus); but while it is appealing in theory, it usually fails to match the reality of most candidate companies. And here, that doesn’t make a lot of sense. Sure, one could argue that with such a low valuation (lower than their revenue) and $3.5 billion in the bank, it was a good time for the RHT-wannabe to complete their FOSS stack. But the database market is very specific, with its own set of rules, its own sales cycle, its own decision makers and this increased complexity is certainly not going to help streamline Sun’s execution, especially in sales. They’ll probably be able to leverage their channels pretty fast, and this can be powerful given MySQL’s strong presence in OEM, but the same tactic won’t easily apply to the enterprise DB market. Consequently, I still fail to grasp the obvious synergies that were hinted at during SUN’s quarterly call (peace of mind, storage, servers, etc.). It is going to be interesting to see how they execute on that one.

My bet is that 2008 is going to be a year of accelerated consolidation in the software market. Let’s keep a close eye on the dominos.

Onward,

Sacha

P.S.: While reading posts on these two topics, I found an article on TSS that was referring to a blog entry from Professorial Rod Johnson. I found it amusing on several fronts. First, I really liked the not-so-subliminal call for an exit strategy. I couldn’t imagine that the AS-agnostic SpringSource’s CEO would go so far in exhibiting his love for BEA. As a final teaser, most probably to hint at who their common enemy is, there is this great quote: “The vision and leadership at Sun suggests that they will make this acquisition a success–unlike Red Hat with JBoss, due to incompatible sales models and culture clashes.” Speaking of cultural clash and incompatible sales model, has Rod realized yet that SUN is … a hardware company?

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:

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.

Onward,

Sacha

.

Red Hat (RHT) made several important announcements this week: the launch of its “Linux Automation” strategy [1], [2], [3] and [4]. 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.

Genesis

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.

Virtual Appliances

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.

Cloud Computing

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.

Conclusion

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).

Onward,

Sacha

P.S. In a later post, I’ll focus on the cost of virtualization.

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.

Onward,

Sacha

.

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.

Onward,

Sacha

.

I was reading Savio’s recent post on BEAS: essentially he suggests that much like IBM, BEAS should move to a bait-and-switch strategy and adopt Geronimo as their black duck entry level offering.

First, Savio goes onto a car comparison to show how BEAS would benefit from a mediocre entry-level AS offering to better fight Open Source competition. While I am not going to comment on Savio’s car taste (vs. mine), I’d like to thank him for the Toyota comparison as it expresses very well why IBM is very wrong with its Geronimo bait-and-switch strategy. Essentially, he states that offering like WebSphere CE and JBoss AS play a Toyata Yaris role vs. the Toyota Camry camp of the Weblogic and WebSphere.

Truth is that JBoss AS is not the Yaris Savio likes to depict. JBoss AS is a full featured mature EE implementation and the numerous ex-[BEA¦IBM] customers that have migrated complex and critical applications to JBoss AS can attest this. From there, Savio’s demonstration is pretty much broken.

What Savio doesn’t realize is the kind of message the WebSphere CE (as in Children Edition) strategy sends to the market: “we have a baby version based on Geronimo and a strong, performing version for the adults - WebSphere. Now, you have to know that we have no real compatibility between the two, so now is the time to make your choice Mr. Customer: are you developing a useless baby app that will never ever evolve in deployment size or are you a smart person?”. This along with IBM’s declarations that IBM and Open Source are the best buddies, is a cognitive dissonance that most people have a hard time buying into. If IBM was serious about middleware FOSS, they would be basing all of their WebSphere product lines on top of Geronimo (and possibly even leveraging FOSS for this). Truth is that such a solution would not work (at least in the mid term) with IBM’s business model and revenue expectations. Hence the dirty trick. So Savio shouldn’t even try to make us believe that “customers benefit, and that’s why we’re all here“: you are just trying to protect your crown jewels, and that’s very fine, you just have to be clear on your real objectives. (Remember, cognitive dissonance is your worse marketing enemy.)

Savio, I understand that IBM might feel a bit alone with its Geronimo embarrassment, but that’s certainly not a good reason to wish BEAS even more trouble.

Onward,

Sacha

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”