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
Code
CVS
Access
Binary
Access
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.

Next Page »