Cloud to boost proprietary software use?

I’ve argued that Cloud vendors are in a better position to monetize open source products than open source software vendors themselves.  I’m not alone in this thinking.  In William Vambenepe’s post, “Cloud + proprietary software = love”, there may be yet another reason for open source vendors to drink the Cloud Kool-Aid with caution.

Vambenepe’s writes:

“If Cloud providers get it right and software vendors play ball, the ‘proprietary vs. OSS’ debate may become more favorable to proprietary software in the Cloud than it is on-premise.”

Vambenepe’s argument centers on Cloud computing alleviating buyers from the hassle of license management.

“The removal of license management as a concern may not make a big difference to large corporations that have an Unlimited License Agreement, but for smaller companies it may take a chunk out of the reasons to use open source software. Not only do you not have to track license usage (and renewal), you never have to spend time with a sales rep. You don’t have to ask yourself at what point in your beta program you’ve moved from a legitimate use of the (often free) development license to a situation in which you need a production license.”

With license management being equally unnecessary for open source or proprietary software in the Cloud, buyers can focus on other selection criteria such as costs. Unlike development or unsupported usage scenarios, both open source and proprietary products have an associated license costs in the Cloud.  This is obviously for products delivered and supported by the Cloud provider or the Cloud provider’s partner.  To make Vambenepe’s point, I decided to compare pricing for WebSphere Application Server and the most closely related Red Hat product available on Amazon EC2.  Amazon charges $0.795 per hour to run the IBM WebSphere Application Server on Novell SUSE Linux on a Standard Small Amazon Machine Image (AMI) in the US.  This charge includes Amazon EC2 costs and the per hour license costs of Novell SUSE Linux and WebSphere Application Server.  Alternatively, Amazon charges $1.21 per hour to run JBoss Enterprise Application Platform on Red Hat RHEL on a Standard Small EC2 instance plus a monthly $119 recurring fee.  [UPDATE: 2009-12-11: Rich makes the point I am comparing apples to oranges.  That was not my intention. I simply picked the only two application server Amazon Machine Images (AMIs) that I could easily find pricing for. And in retrospect, my intention was not to compare proprietary versus open source pricing in the cloud, but rather to compare the price differential of proprietary versus open source products in the cloud versus on-premise.] Obviously this is simply one comparison and other comparisons will play out in favor of open source product pricing on the Cloud.  But that’s not the point. As Vambenepe argues, both open source and proprietary products require a license in the Cloud, and the license cost differential doesn’t always favor open source product in Cloud environments.

With license management a wash and license cost differential being much more balanced than one may instinctively think, Vambenepe argues that choosing proprietary software in a Cloud deployment is likely to be an easier decision than on-premise.

Tim Bray wrote “Makes all sorts of sense to me” when tweeting about Vambenepe’s post.

What do you think?

Follow me on twitter at: SavioRodrigues

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

 

Open source license smackdown debate

We’ve all seen the news about the waning use of the GPL open source license. It’s also becoming clear that a handful of OSI approved licenses are going to win out over the sixty-plus OSI approved open source licenses.  Which licenses are winning, why, and which license should you use for your open source project?  Great questions.  Go ahead and ask them here.  They’ll get answered by three open source luminaries on August 31st.

The Free and Open Source Software Learning Centre (FOSSLC) has arranged a live debate (in Ottawa and on free webcast) to discuss the GPL, the Eclipse Public License (EPL) and the BSD license.

Alfresco’s Matt Asay will be defending the GPL.  The Eclipse Foundation’s Executive Director and Mike Milinkovich will be backing the EPL.  Finally, Coverity’s Open Source strategist and BSD board of director will be representing the BSD.

Go ahead and submit your questions before the event attend virtually or in person if you’re in Ottawa, Canada.

My pragmatic nature says that the smackdown will end in a three-way tie.  Deciding between the GPL, EPL, BSD or other open source license should be a result of which license best helps attain your business goals.  It’s also important to consider the ecosystem around your product.  For instance, it’s no coincidence that the latest incarnation of the JBoss messaging project uses the Apache license, not the LGPL which most other JBoss projects use.  The project team felt that the Apache license would ensure that the project’s code could be more easily included into products from the ecosystem. Being pragmatic, it’s not just for Canadians anymore.

 

VMware plus SpringSource, more hype than substance, today

Let me start with a few disclaimers.  By virtue of working in the IBM WebSphere Application Server team, I compete with SpringSource. I know, and like, several of the key people at SpringSource.  I’m happy that their hard work paid of with such a large exit. While I compete with SpringSource, I’m excited that this acquisition will raise the bar for vendors that I care about, and ultimately, customers will benefit the most.

There has been a lot of analysis about VMware’s acquisition of SpringSource.  By in large, the analysis has taken the vision of Clouds and PaaS laid out in VMware’s press release as a likely outcome.  Let me try a different approach by discussing what VMware really bought.

VMware bought SpringSource because “Spring is everywhere”:
Yes, but sadly for VMware, no.  The Spring Framework is widely used in the enterprise Java market.  From my own experience, many WebSphere customers use the Spring Framework on top of WebSphere.  But many WebSphere customers use the competing EJB open standard in place of the proprietary, but open source, Spring Framework.  The most recent Eclipse user survey results found that of the 436 respondents building server side applications, 47.5% were using the Spring Framework and 38.3% were using EJBs.  This data clearly demonstrates that customers exhibit a need for choice significantly higher than proclamations of Spring’s enterprise Java domination would suggest.

With such a high usage penetration, one could expect a significant revenue base for SpringSource.  Yet, SpringSource is estimated to have driven $20 million in revenue, or maybe bookings, mainly from professional services.  This is a very respectable base for a company with 150 employees.  IDC however estimated the 2008 Application Server market at nearly $3.8 billion.  So, while the Spring Framework is widely used, SpringSource has not been able to extract significant market share as a result.

VMware may believe that adding their brand and sales reach to the SpringSource portfolio will drive higher revenue from the Spring Framework and related Spring products.  Redmonk’s Stephen O’Grady subscribes to this view, using the MySQL acquisition by Sun as a proof point.  I disagree because a framework is different than a database and the other Spring products have nowhere close to the penetration of the Spring Framework, as I discuss below.  Additionally, if a customer has been using the Spring Framework for the past 5 years without a support contract or subscription, why acquire support or a subscription now?  The only reason for doing so will be if VMware and SpringSource disadvantage the open source Spring Framework in favor of the enterprise, commercially licensed, Spring Enterprise. The community uproar the last time SpringSource tried this approach leads me to believe that VMware and SpringSource won’t go down this path again.

VMware bought SpringSource because SpringSource now has a “Build-Run-Manage” story:
Yes, but sadly for VMware, no.  Trying to build a significant business selling support subscriptions to the large number of Spring Framework users proved to be a tough nut to crack.  The key insight for SpringSource was that customers paid for runtimes and integrated administration and management of runtimes, not for frameworks.  SpringSource responded by acquiring Covalent and Hyperic in order to deliver two runtimes, SpringSource tc Server and SpringSource dm Server with administration and management capabilities via Hyperic.  SpringSource has introduced a “build-run-manage” marketing campaign which always makes me chuckle as I recall IBM using Build-Run-Manage back in the early 2000s.  I understand that SpringSource is attempting to educate the market that they are no longer only a framework provider, but rather, now have not one, but two, runtimes that customers can purchase.

It’s arguable that one or both of these products will become the basis for VMware’s beachhead into the middleware market.  So what are the prospects for tc Server and dm Server?

Since tc Server is aimed at Tomcat usage, it’s important to ask what customers running large Tomcat environments used before tc Server came to market?  Well, some used Tomcat without support.  Others used JBoss, Geronimo, GlassFish and WAS Community Edition which deliver Tomcat inside.  Finally, others purchased Tomcat support from Covalent, OpenLogic etc.  For the most part, customers who have not purchased Tomcat support or management for 5+ years are not going to buy a product now.  If the customer was missing some of the management capabilities that tc Server provides, by now, the customer has built this capability in house. I know of several large Tomcat users that fall into this situation.  The customer now has to consider the sunk costs of their custom code versus the cost of acquiring a new product.  Next, customers that have purchased Tomcat support are targets for tc Server.  But these customers are also being targeted by JBoss, Geronimo, GlassFish and WAS Community Edition.  Finally, tc Server can compete against JBoss, Geronimo, GlassFish and WAS Community Edition.  It’s not yet clear that tc Server provides differentiated value that will allow it to win disproportionately against the other products.  The important insight is that very few Tomcat users are using just Tomcat.  They use other parts of a Java Enterprise Edition (JEE) stack, such as JMS messaging or Web Services.  So given the choice of tc Server with just Tomcat runtime features or a JEE product which includes Tomcat and other JEE APIs is not as cut and dry as SpringSource’s marketing would suggest.

In the nearly 10 months since dm Server became generally available, I’ve frankly heard of virtually no customer usage.  But don’t take my word for it.  As your neighborhood Java developer if they’ve heard of dm Server, or if they’ve used dm Server.  The key issue with dm Server is that it’s proprietary.  Developers and their managers were comfortable using the Spring Framework because, while the framework was proprietary, they could easily move their applications across multiple standards-based JEE application servers.  Protection from vendor lock-in was delivered by the runtime application server.  Customers continue to expect this.  If you build a dm Server application, there is exactly one runtime it will run on.   Hence, dm Server fails the vendor lock-in test, and its adoption is a testament to this failure.  This is however a fixable problem for VMware.  dm Server could be evolved to meet the forthcoming JEE 6 Web Profile specification, which Geronimo, GlassFish, JBoss, WebLogic and WebSphere are all expected to support.

VMware is going to find that broad usage of a framework or having a Build-Run-Manage story does not easily translate into customers migrating off their existing Java standards compliant application server runtime to a proprietary runtime.

VMware bought SpringSource because of the Cloud & PaaS angle:
Yes, but we’ll see.  Cloud and PaaS are the two reasons that VMware and SpringSource have claimed as motivations for the acquisition.  I couldn’t say it better than Redmonk’s Stephen O’Grady:

“In time, yes, quite possibly. And there’s little question that SpringSource offers VMware an intriguing opportunity to be what 10gen, Project Caroline, et al have to date failed to be: the EngineYard or Heroku for Java, permitting seamless deployment of Java applications to on or off premise cloud infrastructure. But this is, to me, a longer term revenue opportunity, as VMware’s cloud pieces are still coming together and its hardware and datacenter capabilities are neglible relative to competition such as Amazon, IBM or Microsoft.”

Additionally, whether VMware and/or SpringSource will acknowledge it, customers are already deploying Java applications to a dynamically provisioned and policy-based managed cloud.  This isn’t a two or three years from now capability.  As we speak customers are using IBM WebSphere CloudBurst Appliance with WebSphere Application Server and WebSphere Virtual Enterprise to achieve what VMware CEO claimed is: “something our partners aren’t doing yet” when asked by a financial analyst if this deal would alienate partners.  The point is not to discuss IBM products, but rather to highlight that the VMware and SpringSource future vision is already a reality.  And it’s a reality that is driving significant IBM WebSphere revenue around an on premise cloud environment. Again, this is a today statement.

Lastly, since an application runtime environment is critical to a PaaS or Cloud deployment, I’d go back to the fact that SpringSource’s runtime environments, tc Server and dm Server, are starting from a standstill in an uphill battle for revenue share.  While VMware works to establish tc Server and dm Server penetration, VMware will have to be careful not to alienate their application server partners; the ones whose products are driving virtually all of the application server spending today.  This level of coopetition is doable, but not easy.  But hey, VMware has 420 million reasons for doing difficult, but necessary, things.

VMware bought SpringSource because of Microsoft:
Yes. Larry Dignan’s excellent analysis of the acquisition highlighted some very interesting data from a financial analyst, Pritchard:

“In our view the acquisition highlights the vulnerability VMware has in its exposure to Microsoft. We estimate north of 80% (may be as high as 90%, with the rest being Linux) of VMware virtual machines are running Windows server and an application developed in Microsoft’s .NET environment. This is a key strategic vulnerability as Microsoft has a history of absorbing functionality such as VMW that is essentially a layer in the Microsoft stack. Ultimately SpringSource technology may enable VMW to add enterprise Java workloads to diversify away from Windows.”

Microsoft is clearly going after VMware with HyperV inside of Windows Server 2008 R2:

“We’ve got a great solution. It’s a sixth the cost on average of what we see in the marketplace. Evangelizing the tax that VMware is getting from the product is something we look forward to competing with in this environment. Again, it’s about getting specific. It is about getting aggressive, and that’s where we’re headed.”

In an effort to guard against Microsoft marginalizing VMware’s core virtualization business, the SpringSource acquisition puts VMware at odds with Java runtime vendors who collectively represent the approximately 50% of the enterprise market not associated with .NET.   I don’t see how SpringSource helps VMware versus Microsoft in the estimated 80 percent of VMware environments where the application has been developed on .NET as Pritchard suggests.  If the application is .NET based, and the hypervisor is running on top of a Windows host, then this is Microsoft’s customer to lose to or win back from VMware.  VMware is clearly looking past its current deployments where Windows and .NET dominate, to a new Java-based Cloud and PaaS environment. But we already covered that aspect and the competitive hurdles in the Cloud/PaaS portion of this post.

It’s not just Microsoft that is marginalizing the value of a hypervisor.  As mentioned above, IBM WebSphere CloudBurst Appliance and WebSphere Virtual Enterprise treat the hypervisor as an infrastructure component of equivalent value to the host operating systems.  Said differently, the hypervisor, like the operating system has little impact on the application performance, reliability, availability or TCO.  Those application characteristics are enabled through the runtime application server and the dynamic provisioning and management framework around the application server.  This is how IBM’s Cloud solution is designed.  I’ll wager that Oracle and Red Hat’s offering will push value up the stack, beyond the hypervisor layer itself.

VMware bought SpringSource because of the great people at SpringSource:
Yes.  There is solid talent at SpringSource.  VMware has set aside $60 million in retention funding for the approximately 150 SpringSource employees over the next four years.  This $60 million was discussed on the VMware investor call and is in addition to the acquisition price.  This will clearly help VMware retain SpringSource talent.  SpringSource employees will also want to stick around to bring their vision of world domination to fruition ;-)

Summary:
There is much opportunity and risk for VMware with this acquisition.  If VMware can execute well, they’ll have saved the company from peril at the hands of Microsoft and Hyper-V and application server vendors who are minimizing the value of a hypervisor to the level of the underlying operating system itself.

This acquisition raises the competitive bar for vendors with application server and/or hypervisor offerings.  That’s something customers should be happy about. Fun times ahead!

Follow me on twitter at: SavioRodrigues

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

 

Whatever happened to support directly from developers?

Monty’s explanation of why he founded the Open Database Alliance focused on the Alliance being able to target customers that need more personalized services than Sun/Oracle could provide.  This jogged my memory about one of the early benefits marketed around purchasing open source support.  Namely, that customers could speak directly with the developers of the product.  In this brave new world, of 3 years ago, customers wouldn’t have to explain their issue to one or two levels of support professionals before reaching the actual developer of the code.  This was even while most questions related to configuration, settings, or other issues that a level 1 or level 2 support professional could handle easily.  But, when it was a tough problem, and/or the customer was down, going directly to the developer definitely had its appeal.

The ability to “speak directly with the developer” could not scale with the growth of an open source software business.  Vendors want their developers writing the next feature for the next release, or out doing professional support, not manning the phones to answer configuration questions.   I remember struggling with this issue  when we were crafting IBM’s Apache Geronimo and WAS Community Edition support offerings back in 2005.

I know some closed and open source companies rotate their developers into the support organization so developers can get customer exposure and better understand how their work and the product is used in the field.  However, this staffing procedure is seldom marketed to customers.

I checked the JBoss and MySQL subscriptions to confirm whether they market the ability to speak directly with the developer. As best as I could tell, they do not.

Customers don’t prefer a support triage system.  But maybe they’re not willing to pay a premium for it?  Or maybe larger open source vendors have acknowledged that this feature does not scale, and hence, aren’t offering it?  Maybe it’s a little from column A and a little from column B?

Follow me on twitter at: SavioRodrigues

 

Comparing the JBoss and MySQL acquisitions

Just saw this story on Slashdot which made me think of this post from Marc Fleury.

The Slashdot story questions what/where is the official MySQL tree:

“…With Monty Widenius having left Sun and forked off MySQL for MariaDB, and Brian Aker running the Drizzle fork inside of Sun, where is the official MySQL tree? …. Smugmug’s Don MacAskhill, who is the keynote at the upcoming MySQL Conference, has commented that he is now using the Percona version of MySQL, and is no longer relying on Sun’s.”

In researching a future post I came across this quote from Sun’s Jonathan Schwartz via Marc Fleury’s blog:

“A: First, the personalities involved. Let’s just say that integrating Marten Mickos into a company might be easier than assimilating a few of the JBoss personalities. Marten is a joy to work with and will make this integration work.”

Thinking about JBoss and MySQL today, I can’t help buy chuckle at the quote.  Both JBoss and MySQL have seen their executives leave the acquiring company.  However, for all the “JBoss personalities” out there, not one of them has forked the JBoss code in an attempt to compete against Red Hat.  Not yet at least (you never know what Roy will do ;-).

I truly wonder why.

Maybe JBoss developers are contractually prevented from doing so or have financial incentives not to fork JBoss?  But if so, why wasn’t the MySQL team put under similar legal restrictions and/or incentive plans?

Maybe Red Hat’s history with open source provided for an easier transition than Sun did?  I don’t buy this considering the initial challenges at Red Hat.  Every acquisition has its road bumps, Sun’s challenges with MySQL are no different.

Maybe there were plenty of open source application server choices (Tomcat, Geronimo, Jetty, GlassFish) out there, so the likelihood of a fork gaining traction is too minimal to bother with the effort?  I’m not convinced by this argument; EnterpriseDB/PostgreSQL, Ingres and JavaDB provide enough choice, as do Cloud databases that seem to pop up weekly.

Maybe, as Schwartz foretold, it all came down to the people and the “personalities”, on both sides of the deal

What do you think?

 

Red Hat facing JBoss Hibernate related patent suit

I’ve previously argued that IP indemnification should be as much a part of the software selling process as companies guaranteeing that babies were not harmed in producing their products.  I was later informed that US law can hold both vendors and users of infringing products liable.

I suspect that folks would be surprised to learn which large software vendors do not offer IP indemnification.  The idea being that these large vendors have deeper pockets than their customers, and hence will be sued directly.  This is often not the case with most open source vendors whose customers often have much deeper pockets than the vendor itself.  Only Red Hat, Novell and Sun would fall into the handful of open source vendors that have the financial resources for an IP-related legal battle.  That’s why I’m interested to see what will come of the recently filed case against Red Hat/JBoss.  The claim also names Dell, HP and Genuitec as defendants because the sell or distribute the infringing products.

Software Tree LLC is claiming that JBoss infringes on its patent for “exchanging data and commands between an object oriented system and a relational system”.  I should stress that Software Tree LLC does not appear to be a patent troll; they sell object-relational mapping software for Java.

Software Tree’s patent relates to capability that is included in the popular JBoss Hibernate product.  According to Sourceforge.net, over 4.6 million downolads of Hibernate (and its various packages) have occurred since November 2001.

I’m certain that more than a handful of very large customers have a copy or two of Hibernate running in their enterprise without support contracts with Red Hat/JBoss.  Will this claim be an impetus for buying a support contract, and hence receiving Red Hat’s indemnification?

[UPDATE: 2009-03-05 9.30a ET] I’m told that Oracle is also a defendant, although this filing is from April 2008.

 

JBoss Enterprise SOA Platform

Two days ago I read Paul’s Infoworld coverage of JBoss Enterprise SOA Platform 4.3.

The Platform includes open source projects such as JBoss ESB, JBoss JBPM and JBoss Rules.  I knew something (good) was up when I saw a link to a “Free 30-Day Evaluation Subscription (unsupported)” on the JBoss Enterprise SOA Platform website.  So I emailed the following to JBoss’ Sacha Labourey:

Is the platform more than just downloading the piece parts (in open source format)? Or is there some pre-integration / performance improvements etc in the soa platform? I hope it’s the latter, since it would drive customers to purchase vs. just using the oss piece parts.  Frequent readers will know that I’m a proponent of selling products, not support.

Sacha replied (with slight edits):

At the core, it could be argued that a platform is just a set of project aggregated together. But that would be a very naive view on the quality engineering and release engineering processes we are going through. We take extensive care to make sure these components are compatible together, that they can leverage the same backend integration (databases, JVM, etc.). Obviously, we go through platform-specific testing which cover more than just one feature (or project) but which cover the full spectrum of features (ESB, Drools integration, jBPM integration, Smooks transformation, etc.) We want to make sure that we will be able to support those bits for the next 5 years at the minimum, while providing backward compatible cumulative patches.

Also, this release of the SOA Platform will be the first one integrating with our JBoss ON management product – that’s also something we don’t do for individual components. Also, remember that the SOA Platform can either run standalone or on top of the EAP (Enterprise Application Platform). For the latter, we also need to make sure that the components we pick up for the SOA Platform do not conflict with the ones from the EAP.

Bottom line: it is the latter :)

This is very cool.  JBoss isn’t selling support.  They’re selling valuable products (whether they would state it as black and white as I do ;-).  Selling valuable products, which can’t be acquired without paying for them, is the best way for OSS vendors to grow revenue with category B users.  Actually, in my view, it’s the best way to grow, period.

 

Source code and vendor lock-in continued

Sacha & Bill (of JBoss/Red Hat) made some great points on my previous post on source code and control.

Sacha wrote:

“Savio,

aren’t you mixing “cost of switching to a different software” with the ability to move to a different support provider? … However, migrating to a different subscription vendor is definitively possible. Just look at CentOS and ORCL with RHEL.”

Great point.  But, moving to a different support provider is not usually a good enough answer.  Customers purchase support around product XYZ not just to get support.  They want to ensure that XYZ continues to be developed and enhanced.  Getting support around a project that isn’t being actively developed is really just a temporary situation.  Most companies will want to migrate the application to an environment that is being actively developed asap.  Additionally, simply providing support isn’t a strong value proposition against a competitor offering support and future development of the product.

As for using Oracle’s Unbreakable Linux as proof of being able to change support vendors, I think the jury is out (at best).  If a vendor with the brand, size and resources of Oracle can’t put a large dent in RHEL usage, what is the likelihood that Savio’s Super Support Center is a viable option for customers of say, JBoss AS?

Next up, Bill makes a very good point about standards:

“Unlike vendors like SpringSource, we have been very good about bringing our core technological innovations to standards bodies like the JCP. Specifically Hibernate (JPA) and Seam (Web Beans). We hope to do the same with the innovations we created within our AS 5 microkernel and OSGi.

So, IMO, the combination of standards and open source, gives customers *a lot* of fluidity and is a nice buffer for vendor lock-in.”

I completely agree that standards help to guard against vendor lock-in.  (I also want to give JBoss kudos for working with standards bodies vs. simply playing the “it’s open source, so don’t worry” card.)  However, very few segments of the software market have an open standard that multiple vendors have congregated around.  Subsequently, we’re back to square one regarding open source as a defense against lock in.

But, as Sacha put it:

“…between Black and White, FOSS is a gray, somewhere in-between. Proprietary software is definitively a strong black with not an ounce of gray :) “

I can’t argue with that.

 

JBoss plays the choice card

News from Sacha (and covered by InfoWorld) that JBoss Application Server 5.0 is close to GA kicked off a debate at TSS.  Some commented that they were “Suspicious of anything that takes three years to develop”, while others questioned if there was anything new in JBoss AS5 that SpringSource and GlassFish (or for that matter Apache Geronimo) hadn’t already delivered.  Others congratulated JBoss on closing in on JEE5 certification and refactoring their runtime to be more flexible.

What caught my attention is the way that Sacha (JBoss CTO) responded to two comments from Douglas Dooley.

When Douglas suggested that JBoss shouldn’t talk about the new microkernel in JBoss AS5 when the real value is in Java EE5 delivered in JBoss AS5, Sacha replied:

“Again, read my blog: we are perfectly aware that many of our customers are using very different APIs to leverage our AS services. Most of them rely on EE, some of them on Spring, etc. And that’s fine. I don’t really mind which “wrapper API” they are using: we are here to support them in their preferred scenarios. What matters is how flexible our underlying foundation is so we are able support these multiple scenarios.”

When Douglas commented that JBoss should ditch their work on other OSes and focus on Linux, Sacha replied:

“No worries, we are doing more than fine. But we are certainly NOT going to ditch support for other OSes: we have a significant portion of our users going in production on Solaris, Windows, etc. and again, that is a matter of choice – we won’t dictate that.”

Why did these responses catch my attention?  Well, it’s not because of the technology decisions that JBoss appears to have made.  The move towards a flexible app server has been going on for years and it’s where the industry is headed.  For example, we’ve been down the flexible foundation path since WebSphere Application Server 6.1 two years ago (with more to come in the next release of WAS due out later this year).  The reason is because Sacha focused on customer choice. Even though we compete, I have a lot of respect for Sacha. He’s way to smart to let dogma get in the way of meeting customer needs. The internal decisions that led to JBoss AS5 and the messaging around the product appear to be a direct result of Sacha (and team) understanding what customers truly seek and where they want to head (i.e. JEE isn’t the answer for every problem).

I’ve long written about how WebSphere has been able to grow significantly faster than the market because of our focus on customer choice.  At times this focus stretches us a little too far as we try to reach the largest set of customers with whatever makes sense for that customer. This decision is not easy on the internal organization, but it really resonates with customers (as our revenue can attest to).

As a proponent of OSS, I’m very happy to see JBoss moving in this direction.  As an IBMer who competes with JBoss AS, I say bring it on ;-)