WAS Community Edition

Matt and Dave D. are good guys that I respect, but they are also wrong. There, I said it. We Canadians aren’t known for being so blunt, but this needed to be said. I may get a few eggs directed at me, but so be it. You can argue with me, but you’ll have to use your data to argue with my data.

Matt says:

Neanderthal proprietary past. It’s not that this model is bad in some religious sense. But it is bad in how it treats the customer (as a would-be criminal who will steal value if she can). And it is bad in its inefficiency (expensive sales and marketing costs, higher than necessary development costs because it reserves all development – even tertiary development like language backs and “last-mile” configuration/customization, etc.).

Dave D. says:

For how much longer will we continue to pay the taxes, both overt and covert, imposed by the closed-source vendors and their inefficient methods?

Can you accept that all OSS vendors dream of growing to be the “Red Hat” of their respective market?

If so, let’s spend a second using Red Hat to test the truths that Matt & Dave D. tell you to expect. And here’s the thing, it’s not just Matt or Dave D., it’s the whole OSS movement that tells you “this be true”.

I believed these “obvious truths” at one time. Then I had the fortunate experience of working on the Gluecode acquisition, and being the product manager for WebSphere Application Server Community Edition (WAS CE). I had the good fortune of managing WAS CE in the same team that manages the rest of the WebSphere Application Server family of (Traditional software) products. I/we learned a few things. I am still a believer in OSS, but I’ve resisted the second helping of that Kool-Aid (however thirst quenching it may appear).

Do OSS vendors spend less on selling their products than a Traditional vendor would? Yes and no. Yes, when the OSS vendor is working on building its customer base and trying to become a vendor with “tens of millions of dollar” in revenue. No, when the OSS vendor is trying to scale their business to “hundreds of millions” or greater.

The problem with most OSS “obvious truths” is that they are true at a point in time. But when you generalize to the time that the OSS vendor matters in a marketplace to the degree that Red Hat does, the truths don’t hold any longer.

Think I’m a brainwashed IBM lackey (or insert appropriate description)? Okay, then please explain why Red Hat spends more of their total revenue on Sales, General & Administrative (sales, marketing, advertising, etc), 54% than IBM’s 23%, Microsoft’s 31% or Oracle’s 26%. Next, Red Hat spends 3.1x more on SG&A than they do on R&D. This compares to 3.6x for IBM and 2.1x and 2.0x for Microsoft & Oracle respectively. Oh, and counter to conventional wisdom of OSS not requiring advertising, Red Hat spends nearly 5% of their revenues on advertising, while Oracle spends 0.7% and Microsoft spends 2.8% of their respective revenues. And best of all, since OSS benefits from all this “free work from the community”, it may come as a surprise that Red Hat spends 18% of its revenue on R&D. This compares to 15% for Microsoft and 11% for Oracle.

So there you have it, my data. Bring yours to the table and let’s chat. Or if you want to tell stories of strawberry fields, bliss and OSS “obvious truths”, then let me know so I can pick up a book of childhood fairy tales. We’ll have great fun!

Another tidbit that David Skok (JBoss VC) gave at OSBC was that the JBoss support renewal rate was 85% (likely at the time that JBoss was sold to Red Hat).

It seems strange that a customer would buy support in year 1 and then decide not to renew the support agreement in year 2. Remember, 15% isn’t chump change. An 85% renewal rate means that you have to “grow” 15% just to stay flat with your previous year’s # of customers, or potentially, revenue. In most software markets, 15% is about 1.5x or more of the market growth rate.

Why didn’t the 15% renew?

1] The OSS product is no longer being used, in favour of a different (OSS?) product
2] The application running on the OSS product is no longer required
3] The level of support that a paid subscription/license provides didn’t meet the customer need (either because of under utilization of support or under-delivery of the support experience)
4] Something else?

You can’t do much about #1 or #2, although you’d hope that growing use of OSS, and in particular, your OSS product, would ensure a near 100% renewal rate with customers you already had.

But #3 appears to be a much larger concern. What happens when 15% of your current paying customers decide they can use your OSS product without paying you a dollar. Worse still, these are users you convinced to buy support/license from the mass of non-paying users. Customers surely realize that their support/license payments enable the OSS vendor to continue developing the product in question. Sure, you get some free development from the community, but 95%+ is still done by the vendor’s employees. What happens when more and more customers pass the “pay for continued development” buck and simply become users???

Traditional software renewals rates aren’t 100%. But you’d expect higher than 85% from OSS, since conventional wisdom tells us OSS tracks closer to customer needs and does away with the ‘pitfalls’ of the traditional software business model.

Finally catching up on some reading…I came across this post at ZDNet that discusses an upgrade of Red Hat’s stock by Credit Suisse.

The analyst (Jason Maynard) seems to be on the same point that David Skok (of JBoss VC fame) made at OSBC. How can JBoss/Red Hat monetize a larger percentage of their user base? Currently only 3% of JBoss customers (or downloads? How would JBoss have a count of non-paying customers) actually pay for support.

I quickly thought about Marten‘s customer groupings that he summarized at OSBC.

[1] Those willing to spend time to save money
[2] Those willing to spend money to save time

I knew that I liked his two groups for a reason. I totally forgot that I had come up with 3 groups of OSS users a little while back. My groupings were, more or less, based on willingness to accept risk.

{1} Cost Contentious: Unlikely to ever pay
{2} Scope Contentious: Pay based on app criticality & perceived need for support
{3} Risk Contentious: Likely to always pay (i.e. CYA)

Both views make sense, but willingness to trade off Time & Money doesn’t happen in a vacuum. That’s why I believe willingness to accept (varying levels of) risk is important when trying to categorize OSS users.

On the surface, there is little change to the Time vs. Money equation as a result of JBoss adopting the Fedora model. A customer that wants to spend time to save money can continue to use JBoss “Community Edition”. As a result, one could refute Mr. Maynard’s claims that JBoss adopting the Fedora model will drive more revenue.

This is where risk comes into play. Keep in mind that the JBoss “Community Edition” will include the latest features, some of which won’t make it to the JBoss “RHEL” version or may be dropped from future JBoss “Community Edition” versions. JBoss is clear that backwards compatibility isn’t guaranteed with JBoss “Community Edition”.

If you’re a customer that wants to spend time to save money, and you’re somewhat risk averse, than you don’t like using a product with features that may disappear in the future. You have the option of buying JBoss “RHEL” and getting backwards compatibility. You can also look elsewhere for an application server solution.

Taking Risk into consideration is likely the #1 reason that an OSS user will turn into an OSS paying customer.

 <Updated 2007-05-30> “Risk aversion” shouldn’t be considered a dirty secret of OSS.  I can’t think of an analogy in the traditional software market. But you don’t get to choose whether to pay for traditional software or not :-) </updated>

Before I get started, Red Hat/JBoss have the right & duty to their investors to grow revenue & profits as they see fit. I am certain that a good deal of thinking went into making this decision, especially to consider the customer impact.

Here’s a table that summarizes the likely announcement from RH/JBoss (where JBoss “retro” represents their business model as of 2007-04-23):

Product Source
Fedora Free Open Free
RHEL Free Closed Paid
JBoss “Retro” Free Open Free or Paid
JBoss “Fedora” Free Open Free
JBoss “RHEL” Free Open Paid

The major change is that non-paying JBoss customers will have to build JBoss from source or use the JBoss “community edition” version (whatever they decide to name it) binary. (See below for why each may not be an optimal choice).

If I had to group OSS customers by their likelihood of paying for support/services, I’d suggest these three (other classifications are likely valid also):

1. Cost Contentious: Unlikely to ever pay
2. Scope Contentious: Pay based on app criticality & perceived need for support
3. Risk Contentious: Likely to always pay (i.e. CYA)

Let’s use these 3 categories to analyze the customer impact of using the Fedora/RHEL model for JBoss.

Cost Contentious:
1A] Build JBoss from source: Not sure how many customers will do this. For example, how many customers build RHEL from source (although it’s a different ball of wax with an OS vs. an app server). Sometimes it’s not as easy as it sounds as builds don’t always complete on the first try. I haven’t built JBoss from source (so please leave a comment if you have), but at the very least, it’s one more hoop to jump through. Maybe there will be a market need for something like CentOS around JBoss products?
1B] Use JBoss “Community edition” (or whatever it is called): May not be appealing for production use, since “backwards compatibility” is not guaranteed and you may (inadvertently) use a feature that doesn’t make it to the next release.
1C] Consider an alternative: Customers will choose based on their needs and their comfort with one open source app server community over another.

Scope Contentious:
2A] If the application isn’t business critical: and the impact of a few minutes/hours/days down time does not justify any spending, then see [1A], [1B] and [1C] from above. (Note: customers can define “business critical” differently).
2B] If the application is business critical: and you’ve been using JBoss without support, this move should help you decide to go get support.

Risk Contentious:
3A] Already paying for support/services: Not a whole lot new for you

This move is definitely intended to drive more revenue to RH/JBoss from customers already using JBoss products without paying for support. There is a risk that some portion of these customers will view the move as a reason to consider alternative products. It appears that RH/JBoss feels that there’s more revenue to be had from [2B] than the risk of losing customers from [1C] and some folks in [2A]. And if these non-paying customers leave, did it really cost RH/JBoss something? (Methinks yes, but from a revenue standpoint, no, at least not now).

Interesting times … and definitely worth looking at alternatives (my biased opinion is that you start with Apache Geronimo or WAS Community Edition).

Okay, I do not speak for IBM in any way (read full disclaimer here). But after reading the following from Matt Asay’s post today, I couldn’t resist.

“IBM uses Apache/BSD to burn boats…everyone else’s. :-) The company builds its software business on proprietary software and its services and hardware businesses on open source software (as well as its proprietary software.) This is classic Martin Fink-type thinking, i.e., open source your complements which also happen to be your competitors’ core competencies. The problem is, they’ll likely do the same. Or, more pertinently, an open source competitor will come along that doesn’t have the same need to keep sacred any proprietary software. How do you compete with someone that can drive all software value to $0.00?”

Let’s dig into Matt’s statement:

MA: “IBM uses Apache/BSD to burn boats…everyone else’s. :-)”
How many open source projects does IBM contribute developers, hardware and/or fund to? Let’s take the example of Apache HTTP Server. Long ago, (the royal) we decided that web serving was a commodity and it didn’t make sense to build our own web server to use inside of WebSphere Application Server. Fancy thing was that BEA and Oracle made the same decision. Does IBM get more than it gives to the Apache HTTP project? Yep, that’s what you’d expect from an open community project. But we have a team that is works on the Apache HTTP project day in and day out. What about Apache Geronimo? Yep, it’s the base for WAS Community Edition and yes we have a sizable number of IBMers who work on Geronimo as their day jobs. What about Linux (let’s throw in a GPL project), again, yes, IBMers work inside the Linux community as their day job. Eclipse, check. OSGi, check. OASIS, check. I could go on….

MA: “The company builds its software business on proprietary software and its services and hardware businesses on open source software (as well as its proprietary software.)”
Umm, so yes, IGS will work with OSS based on client needs. But heck, they’ll work with IBM products, Microsoft product, Oracle products or any software the client seeks. Next, does Linux help drive hardware sales? Sure, but remember we spend resources inside the Linux community, so we’re not taking without giving. While IBM may drive $1B (or whatever it was in 2006) from Linux-based software, hardware and services, it is a small portion of our total $90+ billion in revenue. I’d suggest you want to rephrase the statement to read “(as well as open source software)” in brackets.

MA: “Or, more pertinently, an open source competitor will come along that doesn’t have the same need to keep sacred any proprietary software. How do you compete with someone that can drive all software value to $0.00?”
Umm, we’re competing and winning quite well. Thanks for asking :-)

Anywho, aside from this paragraph on IBM that I take exception with, Matt’s post is well worth the read. He hits the nail on the head when he summarizes with:

“Net net: burning the boats is the right thing to do, but which boats to burn…?”

Indeed…Which boats, when and how does lighting the fire help customers? That customer angle is very important and likely the reason that we’ll see OSS and traditional software (happily) coexisting. (Much more on this in a later post)

Since this will be the third one of these posts, I’ve decided to track the demise ;-) of the traditional software market on a quarterly basis (using IBM’s WebSphere branded revenue as the basis – for no other reason than that’s the part of IBM that I sit in. One day I may look at a broader set of companies, but that day is not today).

IBM announced 1Q07 results last night.

A few points:

  1. IBM Software grew at 9% (or 5% at constant currency: i.e. if currency exchange rates were fixed to equal their 1Q06 rates)
  2. WebSphere branded middleware grew at 14% (or 10% at constant currency)

A few more points from this time last year:

  1. IBM Software had grown at 2% (or 6% at constant currency – note how currency fluctuations can impact a worldwide business)
  2. WebSphere branded middleware grew 26% (or 30% at constant currency)

First, our overall Software business is growing faster now than it was in 2006. Good to see healthy growth of 7%, 14%, 15%, 18% and 20% for Lotus, WebSphere, Rational, Tivoli and Information Management respectively.

Second, we saw very healthy, but slower, growth in the WebSphere branded middleware segment in 1Q07 vs. last year. I stress very healthy because 14% growth is pretty awesome when you’re growing from such a large revenue number, which unfortunately, IBM does not make public. But, if you have access to Gartner or IDC data, you can easily get to a ballpark number of total WebSphere branded revenue.

WebSphere Branded Middleware Quarterly Revenue Growth:

Quarter Y/Y Qtr Growth From:
1Q04 24% Source
2Q04 N/A Source
3Q04 14% Source
4Q04 18% Source
1Q05 11% Source
2Q05 18% Source
3Q05 14% Source
4Q05 4% Source
1Q06 26% Source
2Q06 17% Source
3Q06 30% Source
4Q06 22% Source
1Q07 14% Source

Web Application Server Market:
Some of you may say, “come on Savio, you expect me to believe that in the face of open source competition, the application server business is growing at all? Maybe WebSphere Branded Middleware is growing, but the underlying application servers surely aren’t, right?”

Well, I’m glad you asked. I’m even more glad that IBM is making these figures available. If you go to our 2006 Annual Report and then find your way to page 34 you’ll read:

“Revenue from the WebSphere family of products increased 23.3 percent (22 percent adjusted for currency) and was led by doubledigit growth in WebSphere Application Servers (25.3 percent) and WebSphere Business Integration (22.7 percent) software versus 2005″

Translation: The WebSphere Application Server family revenue growth outpaced the figures that you’ll find in the table above. This is because the table above relates to the 23.3% growth and you’ll notice that the WebSphere Application Server family grew at 25.3%.

So, yes, even in the face of open source competition, the WebSphere Application Server business is growing at 2-3x the market. How? We’re helping our customers address their business needs to achieve success. In some customer situations, we help customers achieve success through the use of WAS Community Edition (WAS CE). In other situation we help customers achieve success through the use of the traditional WebSphere Application Server family.

In the face of open source competition, we got involved in the community, and gave our customers more choice, more flexibility and protected their investments. The results are pretty clear.

“One size fits all” is a great motto for a sock company, not so much for a software company.

Roberto writes that Sourceforge (SF) is adding the ability for OSS projects hosted on Sourceforge.net to sell support & services, and for users to buy these services. SF plans to launch Marketplace in late spring/early summer.

Kudos to Roberto for not only blogging about the Marketplace announcement, but also for finding the Senior Market Management position for SF Marketplace and linking to VA Software’s (SF’s parent company) latest 10Q. It’s amazing that they made $13M in e-commerce revenue in the most recent quarter from selling consumer goods through ThinkGeek. Also interesting is that VA made $3.8M from online media, mostly advertising. I would have guessed sites like Sourceforge.net and Slashdot.org would drive more than ~$4M in Ad revenue per quarter. But maybe geeks don’t click banner ads because they use Firefox with Adblock Plus ;-)

Anywho, so now it gets interesting between SF Marketplace & Red Hat Exchange, although they appear to be going after different projects & customers.

Red Hat is definitely going after the enterprise customer who has (by in large) made the decision to run the given product on RHEL. So, the testing and certification of a product with RHEL is critical to being included in the Red Hat Exchange.

But a majority of customers don’t run OSS on RHEL. A lot of folks run on Windows. Even JBoss use on Windows was 50% or so, which is somewhat lower than similar figures we saw from our WAS CE downloads about a year ago – things may have changed since though.

Today, SF is a leading destination for finding & downloading OSS products. The SF Marketplace appears to be the next logical step.

For the large projects on SF who already have support & services business attached, I doubt that this announcement changes much at all. Customers interested in, for example, Hibernate support, will find their way to hibernate.org and then to jboss.com. So I’m not sure why RH/JBoss would want to give up a percentage of their revenue to VA/SF just to get included in the SF Marketplace.

For emerging projects or for projects with a small development team/community, a majority of the 144,548 projects on SF (i.e. Longtail projects), getting included in the Marketplace would make a lot of sense. Why spend time and resources building & managing the support infrastructure and marketing your support & services if SF can provide that to you for a (small?) cut of your revenue.

Experience tells me that customers are cautious when it comes to spending money. When they do, they want to spend with vendors that have a strong future. So, for longtail projects on SF, I’m not sure that the SF Marketplace will change much of this customer behaviour. Remember, downloads are a badge of credibility, something that longtail projects lack as you move further down the tail. So, if the SF Marketplace won’t drive a lot of revenue for longtail projects and the large projects on SF already have a Support & Service offering through the vendor site, what’s left for SF Marketplace?

I could be proven wrong, and maybe users of longtail SF projects will decide to fund future development through support purchases.

I wonder if SF Marketplace will allow me to see who is offering support & services for, say, Hibernate in one place (i.e. JBoss, Virtuas, Neward & Associates, etc.). But maybe the project owner would have a say in who can offer support for said project? :-)

It will definitely be interesting to see how customers adopt SF Marketplace & Red Hat Exchange.

I purposely didn’t write about the Exadel partnership when it was announced as I wanted to get some more details on it. A week has passed and little has been written that furthers my understanding. And I must apologize for not emailing someone at JBoss to get some clarification (it’s been busy here). As such, I ask you to read the comments before finishing this post, in case one of my JBoss readers writes in to correct my take on the deal.

Here is the quote from the TSS discussion on this deal:

Sacha Labourey: “The Red Hat and Exadel partnership is twofold. First, Exadel will open source its commercial products — Exadel Studio Pro and RichFaces — at JBoss.org as Red Hat Studio Developer and JBoss RichFaces, respectively. Exadel is also moving its popular Ajax4jsf project, currently hosted on java.net, to JBoss.org, where it will become JBoss Ajax4jsf. Second, Red Hat and Exadel will continue developing the three projects going forward, including integration with existing JBoss platform technologies such as JBoss Seam. This ongoing development will be done under JBoss’s leadership.”

Then, JBoss/RH’s Gavin King comments:

“….. Seems like their (i.e. Exadel – added for clarity by Savio) business has actually worked out pretty damn well, given that we just paid them a whole bundle of money to get this deal done. ;-) This is not a typical case of a commercial vendor deciding to give away a product they couldn’t sell, in a last-ditch attempt to get users. Rather, this is an acquisition of successful technology, for money. It follows the model of JBoss Transactions, which was acquired from Arjuna, and JBoss ESB, which was acquired from Aviva. …..”

Am I off in left field when I think that this is little more than JBoss/RH acquiring technology from Exadel for a price? That the “….decided to open source the products at jboss.org” parts of the announcement are more about the cash that changed hands and less about validation of any community site? Reading Gavin’s comments leads me to think as much.

Don’t get me wrong, there is absolutely nothing wrong with that, acquisitions are a way of life in the software industry.

What doesn’t sit well with me is that the TSS Q&A with Sacha and the JBoss/RH Q&A about the deal don’t really clarify if:

  • (A) Exadel decided to open source their products and choose the JBoss/RH community because of its strategic fit with Exadel goals or for whatever reason that Exadel would feel that one ‘community’ is better than another ‘community’
  • (B) Exadel was paid to transfer their copyrights to JBoss/RH, and the open sourcing of Exadel products at JBoss/RH was part of the deal

I’m not the expert, but I don’t think that the Apache Software Foundation or Eclipse ever paid a 3rd party to decide to open source a product into the Apache or Eclipse community. When IBM acquired Gluecode, (which was building products on top of Apache Geronimo), we positioned the deal as what it was, an acquisition. Nice and clear.

Can anyone at JBoss/RH shed some light on who owns the copyrights to the code going forward? Because that should be a simple way of knowing if this was a 3rd party endorsing the JBoss/RH community or a 3rd party selling their IP to JBoss/RH.

Either way, it’s a business decision. But I don’t think it’s cool to paint an acquisition of technology as a partnership that endorses a community/external development site.

Roberto writes that Sun has agreed to include an Italian dictionary and thesaurus (from the Italian Native-Lang Project team) in the official OpenOffice.org distro. Congrats to Roberto & team!

In explaining why the decision from OpenOffice.org took longer than Roberto & team expected, Sun’s Simon Phipps (Chief Open Source Officer) explained:

“…by using the GPL rather than the LGPL for your contribution, it was necessary for Sun’s legal team to conduct an extensive discussion about the implications of distributing it with OpenOffice.org (which as you know is licensed under LGPL)….”

Simon’s quote got me thinking about my WAS Community Edition (WAS CE) days. Mixing different licenses in a project isn’t always so clear cut. Even when working with similar licenses, when a large commercial vendor (i.e. a large litigation target) is involved, they tend to be cautious, and want to protect their IP, investment and guard against litigation.

IBM has a rigorous process before we use, and hence distribute, open source software (OSS) code of any license inside an IBM product. Even with WAS CE, which is built with Apache Geronimo, an ASF licensed product, we had to validate that the code was appropriately licensed and that copyrights were being respected. On more than one occasion the WAS CE development team found code that was iffy from a copyright standpoint. The team rewrote the code and contributed it to the Geronimo project.

At the time, I’d suggested we talk about IBM’s OSS usage approval process as a customer value point. What good is indemnity if your OSS vendor doesn’t have procedures which enable them to give IP assurances with confidence? Saying “we own all the IP, so don’t worry” isn’t always the full answer. This is especially true for IP that was contributed by a 3rd party.

For example, let’s say I get some piece of code from the Linux kernel and use it in a personal application for so long that I forget that it’s not actually my IP, but something I copied. Then, I submit some of “my” code, including the IP that I don’t really own, into, for e.g., OpenOffice.org and grant openOffice.org joint copyrights to “my” code. Now what? Regardless of what license I attached to “my” code that I contributed, there is a potential risk to the openOffice.org project, and Sun (as it distributes the commercial StarOffice distro). What if I contributed someone else’s copyrighted code knowingly? What happens when a larger OSS project is actually built with sub-projects from different communities that aren’t under the stewardship of the larger OSS project? [Note I’m only using Sun/OpenOffice as an example, you can substitute IBM/Apache Geronimo if you like.]

Yes, the code scanning & checking of IP ownership is in place to protect the vendor, and fortuitously, the OSS project. But shouldn’t customers know the level of “background checks” in place before accepting “indemnity protection”? Why don’t we hear about these “background checks” more often from OSS vendors? Is it because OSS vendors providing indemnity don’t do the checks, or because the only way for a vendor to 100% guard against IP indemnity claims is to go buy an insurance policy. [Note: We didn’t include “IP background checks” in our WAS CE customer marketing because the legal team didn’t want us to give customers a false sense of security as checks can always miss something. Yeah, the legal team is more cautious as a result of SCO, which is to be expected. But as the example of SCO shows, IP violation claims will almost always hit the largest wallet in the project-vendor-customer chain, so customers are often in the clear regardless of indemnity clauses.]

It would be interesting to hear whether Sun does any checking on 3rd party IP contributed to OpenOffice (and their other OSS projects). What about OSS vendors like Red Hat or OpenLogic?

BTW, please read my disclaimer here.

[The pic is from Flickr user alfonso015. Customers want to know that their vendor has their back; but more importantly, that the vendor has a strong hand to play from.] 

Matt Aslett writes that Oracle may be considering Unbreakable Support for MySQL and that MySQL Co. is likely to IPO later this year.

When MySQL files for IPO, we’ll get to view their financials. We’ll get to compare their performance metrics against Red Hat (which, until now, has been the only pure-play OSS player with public financials) and traditional vendors. I’m willing to bet that their metrics will be (surprisingly) close to metrics from traditional software vendors.

BTW, in case we’re keeping score, yes, Oracle is already distributing MySQL with their Linux distro. But, Oracle isn’t providing support for the copy of MySQL that you get with Oracle’s Linux distro. Here’s my take on the Oracle support rumor (which could just have been a passing threat in an Oracle/MySQL meeting).

Unbreakable Support for MySQL is likely the first step towards an acquisition:
There’s really little long-term benefit from Oracle providing support to a competitor’s database. In doing so, you’re validating the competitor, and not really doing anything to “bury the competition”. With the Oracle Unbreakable Support for Linux, they’re going after a related market, and failure doesn’t have any direct competitive consequence. Sure failure means that Red Hat gets bigger, but that’s not a big deal (until/unless Red Hat acquires a leading open source database support provider). But failure with the MySQL support would result in a much stronger direct competitor (MySQL Co.).

The more likely option here is for Oracle to buy MySQL. After the acquisition, if Oracle tried to move the user base onto Oracle DB products, add restrictive support conditions, raise prices, etc. then an alternative support provider would have room to grow. Otherwise, MySQL customers would likely continue to get support for MySQL through Oracle. Oracle would need to consider the impact of the MySQL product set on the Oracle DB portfolio. Issues like, customer confusion, pricing, customer negotiation tactics, etc. However, I think Oracle could deal with these issues.

Worried about cannibalization? It’s going to happen to a certain degree, but the alternative is losing business to a competitor without a fight. Oracle can respond by giving customers choice. Cannibalization that occurs will be much, much, smaller than the potential revenue that Oracle can drive using a mixture of open source & traditional software. IBM took this approach with the WebSphere Application Server business (with great success) and Oracle could do the same with their database business.

The result would be two database platforms (MySQL & Oracle DB), which get closer over time, but likely don’t merge (at least for the next 5 years). Customers can choose (remember, choice is good) to use the light-weight MySQL product for a good portion of their needs, and the high-end Oracle DB products for other projects. Let’s not forget that the majority of Oracle DB customers will stick with Oracle DB for products that are already running today (i.e. “if it ain’t broke, don’t fix it”). And when these customers want to use something more light-weight, simpler to use, Oracle has an offering for them. Leave no customer behind!

After the acquisition, Oracle cold shift some of their development efforts away from Oracle DB (except in the high end product category) and put those resources into the Oracle Applications business which is where they want to grow revenue. MySQL products would deliver support stream revenue; very much in keeping with Oracle’s huge maintenance revenue.

Less focus on selling new Oracle DB licenses, and more on selling Oracle DB & MySQL (after acquisition) support would be a big win with Wall Street which looks for steady and continuous revenue. Forget the upfront license cost, and just pay for support & maintenance. Move some development resources to the higher-value offerings. Neutralize a competitor by providing customer choice (with something that a customer wants; not just a crappy offering under the guise of choice). It all sounds interesting. Let’s see how this plays out!

[The image is from flickr user net_efekt – it made me laugh and seemed to be a good way to represent the worry of cannibalization in the face of a serious competitor.]

Next Page »