You should really take a look at Darryl Taft’s excellent article on the History of the WebSphere line of business, it is very interesting.

It describes how this adventure started:

Only Sabbah remains at IBM of the three lieutenants. Sabbah, who was Mills’ CTO at the time, is now general manager of IBM’s Rational business unit. Swainson is CEO of CA, and Spector is vice president of research and special initiatives at Google

And how they then initiated the WebSphere (WS) effort with just 25 engineers and how WS moved from an Apache httpd server to a full fledge transactional container, a similar maturation all middleware vendors went through.

It also explains one of the key reason of its sucess: Senior management involvment.

In an e-mail exchange with eWEEK, Trimble added that other factors leading to the success of WebSphere included, “The senior management team was directly involved, in a critical way, by closely managing the interactions between nascent businesses like WebSphere and the rest of the company, ensuring that the WebSphere could leverage IBM’s massive assets without getting destroyed by quarter-to-quarter hit-the-numbers imperatives. And IBM invested steadily in WebSphere over 10 years, even as the rest of the industry went through the dot-com boom and bust.”

It also describes what we have seen for a long time at JBoss: BEA was really the one suffering from JBoss, not IBM. This actually made a lot of sense. Early version of WS were pretty bad - which means that WS users were betting on IBM as large vendor, not on a “best of breed” product vendor. However, that wasn’t the case for BEA customers, which meant that as JBoss was maturing its offering (as of 2004), many BEA customers moved away to the new best of breed product, JBoss.

The article ends with a funny quote from Mills which shows IBM’s love/hate relationship with Open Source:

“Something of this class of software could never be free,” he said. In the mainframe world, IBM has delivered software as source code, but that is not likely to occur with WebSphere, Mills said.

Mr Mills, that’s a great marketing encouragement for your co-workers trying to sell Open Source based products…

Onward,

Sacha

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?

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.

I had a flashback.

Hopefully SUNW will not follow SGI’s path too closely.

And I really mean it.

As you might have seen, SUNW just striked a deal with MSFT. One topic that didn’t make much noise but that was pretty interesting was the cross-support for virtualized environments (i.e. running Windows VMs on top of Solaris for example). That’s pretty good.

However, the part I found pretty weak was the one around SUNW acting as a Windows OEM on its hardware. That just sounds as an attempt to look like a better DELL. What a mission… I thought it would have been much more interesting to see them support Windows on their briliant Niagara CPU by developing a new Windows’ HAL. But then you would have to recompile applications or provide an emulator… for which market size?…

Nah, you are right SUNW, you’d better stick to the honorable mission of trying to be a better DELL.

Onward,

Sacha

Follow-up post here…