On Setting Goals

Everyone knows that I’m an IBMer in the software division that competes with JBoss. I have a lot of respect for the folks leading JBoss, and hope that has come through in my public interactions with guys like Bill, Sacha & Shaun.

I’ve said it before, and I’ll say it again. JBoss is good for the middleware market. They (and other OSS middleware vendors) keep all the big vendors at the top of our game.

But as I read story after story about JBoss targeting a 50% share of enterprise middleware workloads by 2015, I was left scratching my head. First off, most stories just seemed to accept the “target” without questioning the likelihood. About the only story that separated aspiration from likelihood was by Dan Farber at BTL. Kudos Dan!

Red Hat’s “Enterprise Acceleration” initiative, which underpins this 50% goal, consists of:

1] Comprehensive Enterprise Middleware Portfolio
2] Enterprise Products - From Community Development to JBoss Enterprise
3] Enterprise Acceleration Center

JBoss has been executing on #1 & #2 on this list for some time. The only “new news” would be #3. Come on Sacha, I wanted to hear something new out of JBoss World! ;-) What’s the Enterprise Acceleration Center really about? According to Red Hat, key elements currently planned include:

• Performance Tuning Lab - performance benchmarking, testing, best practice guides Interoperability Lab - interoperability testing with other environments and products
• Live Certification Center - ISV and customers can test their applications on JBoss Enterprise Middleware and proactively adapt to new releases
• Migration Lab - processes, partners, services and best practices to transition from other software to JBoss Enterprise Middleware

Will the combination of #1, #2 & #3 drive the conversion from users to customers?

Anywho, I wish the folks at JBoss the best of luck towards this 50% goal, just don’t expect to get there without a fight ;-)

 

Fleury & Rodrigues - Separated at Birth?

Come on, you have to admit, the resemblance is uncanny. I’m obviously kidding. I’m much better looking. His sizable bank account and ability to keep a beat probably balances the score though ;-)

Marc gave me a heads up on his recent post, in which he comments on Matt’s post. If you don’t already subscribe to Marc’s blog, I’d suggest you read his post today. Here are some key points that reinforce my OSS views of late.

Matt said:

“…It may mean that Benchmark knows something that the rest of the industry seems determined to ignore: services-based businesses may well be the future of the software industry. “

Marc responded:

“FALSE: the future of the software industry (as a whole) is services. I always enjoy it when in debate people mention the case of VMWare to evangelical OSS zealots. Here is a company that is creating vasts amount of technological innovation and money with a classic licensing model of software. When asked why they didn’t go OSS, the CEO responded “why would I do that?” …. What? my ideology is not perfect? the good old model is still kicking arse? by orders of magnitude in terms of technology and, it goes without saying, financial value creation?…”

“The proprietary model is alive and kicking. The existence of OSS models DO NOT negate the proprietary models. GET OVER IT, both models will co-exist and thrive sometimes at the expense of each other, sometimes independently of each other. It is not a zero-sum gain, there is value being created in both.”

“In fact, witness the RUSH of OSS companies to emulate the proprietary licensing models to monetize their bases. The VC’s may have invested in service based companies but they are all becoming product license companies…The proprietary licensing model is still top dog and the OSS guys are falling all over themselves to emulate it. BTW, on this topic, I find that Savio Rodrigues, the “community blogger” from IBM is a more enlightened read. Maybe because he is from IBM and they literally wrote the book over the past 50 years?”

I respect Marc’s willingness to speak/write with his unique sense of candor about OSS business. Whether you agree or disagree with Marc, be happy that his ($300M of) OSS credibility forces us to rethink the OSS business model, if only for a few seconds. Marc’s willingness to evolve his thinking around OSS and, gasp, learn a thing or two from the commercial vendors is refreshing. It’s a good thing for us commercial vendors that he’s retired… ;-)

All truths are challenged over time. It may well be time to challenge the belief that OSS growth will come at the expense of commercial software. As Marc so eloquently put it, there is value being created in both the OSS and proprietary markets. One plus one could actually equal two and a half. Take that Ramy (my accounting prof)!

 

JBoss Developer Studio - A Product or Subscription?

By now you’ve likely read my views on OSS 1 & 2.

Here’s something you may find interesting. Red Hat released JBoss Developer Studio in early December 2007.

InfoWorld reported:

“While JBoss Developer Studio is available for a $99 subscription, support for the platform costs extra. Support agreements start at $3,500 a year. But users get access to all Red Hat and JBoss software through these agreements, Che (Red Hat product marketing manager) said.”

Huh?! So, if support for JBoss Developer Studio is extra, what exactly is in the $99 SUBSCRIPTION? For that answer, let’s head to a blog by JBoss developer Max Andersen:

A reader (Andres Testi) asks Max:

“Where is the free edition?”

Max replies:

“There is no free edition, but there is the JBoss Tools which are the JBoss.rg developed plugins and I’ll be back later this week with details about JBoss Tools 2 GA.”

Another reader (Eriks) asks:

“What are differences between free and 99$ version?”

Max replies:

“The free version does not provide:
* An installer
* Eclipse and Web Tools preconfigured
* JBoss EAP preconfigured
* JBoss AS and JBoss Seam preconfigured
* 3rd party plugins bundled and configured
* Access to RHEL and Red Hat Network
* Access to the supported software”

Lastly, a reader (Sakuraba) asks:

“If all of that stuff is not-preconfigured in the free version, is the free version usable at all?

What features wont work out of the box because of the free version not being configured correctly?

(I appreciate you effort and the fact thatRed Hat wants to earn money with this hard work, but I am interested nevertheless.)”

Max replies:

“Sakuraba - I don’t know how to explain it otherwise than what I did above. There are no functional limitations in the open source version; its just a matter about what is prebundled and preconfigured which you can do yourself for free or get from JBDS which additionally provides you access to the software that JBoss/Red Hat supports commercially.”

Okay, so we finally have an answer to what the $99 SUBSCRIPTION provides.

Since support isn’t included in the $99, you simply get a working product and you get updates to this working product as piece parts are updated. Sound like anything you’ve heard of before? If you said “a regular software product with the support removed” you’re bang on. The fact that Red Hat calls this a subscription is a shame. They are selling a product… bits and bytes. Calling this a subscription continues the “OSS obvious truth” that selling proprietary/gated access OSS products is for less pure OSS vendors.

BTW, if you try to purchase JBoss Developer Studio, you may notice the “(development use only)” text under the product name. Interesting that Red Hat, the beacon for openness and user freedom would (gasp!) limit user freedom by limiting the production use of the offering. I am not calling this out to throw eggs at Red Hat. I am calling this out for the OSS purists who hold Red Hat on a pedestal. If I were a Red Hat shareholder I would be perfectly okay with this move.

Anywho, maybe Red Hat is trying something with JBoss Developer Studio that they’ll implement in other products? When news gets out about Red Hat selling gated/proprietary OSS/OSS-based products, it may become more acceptable to do so. I believe this will be good for the OSS vendor ecosystem.

I guess time will tell.

 

Red Hat, JBoss and Corporate Culture

By now, some of you have read that several analysts downgraded Red Hat due to Red Hat’s execution of the JBoss acquisition. I chose not to blog the story because, well, it’s about the performance of a competitor (JBoss) to IBM WebSphere Application Server.

Matt blogged the downgrade and his belief that JBoss is doing fine. Then things got interesting with comments CNet readers. I’ve clipped a few because they highlighted key points that enterprise vendors should consider before an OSS vendor acquisition. As Roy points out, an OSS acquisition is truly about the people, not the technology, being acquired. In Red Hat’s defense, it was unlikely that JBossians would find the culture at any larger vendor, including RH, to be close to the freedom of the JBoss culture.

Roy:

“They’re looking at the amount of money RHT spent on the JBoss acquisition and the poor revenue return on it. That sorta tends to happen when you destroy the sales and marketing machine JBoss had built.”

Matt:

“I’m not looking for any blame. I’ve yet to see any reason to believe that Red Hat isn’t getting JBoss moving. I know there are plenty of JBossers who have left the company who are happy to dig at Red Hat not loving them enough, but I’m not overly bothered by their outside perspective on what’s going on inside the company.”

Roy:

“Remember… what was RHT buying? They weren’t buying code (OSS). So they were buying… yep… people! As luck would have it, once the “special” people started leaving, the investment’s downward spiral began. Today it seems the surprise is on RHT.”

Then, a rather long comment from a (likely ex or current) JBossian:

“RH is more concerned with creating policies and initiatives that ran contrary to the spirit which Fleury and his team created - one of openness, caring for their work, and the motto have fun which was present every day till the day RH took over. RH was more concerned with making sure no one on @core used profanity, or communicated anything with anyone about any of the projects we were working on. It became the Borg Collective, and that hardly inspires creative and talented people to keep on doing what they do best.

….

Did JBoss’ers think they were special, sure we did, and we were. We were the trailblazers, doing something innovative, and different. We fought the likes of IBM, BEA who tried to drown and kill us at every turn, and we survived, and even managed to come out on top in many ways. So yes, we are a special bunch, and proud of it. It’s to bad RH management tried to take that feeling away. They are paying the consequences for it now, and there will be more to come.”

Let’s hope that comment didn’t come from Marc speaking in the third person ;-)

 

The Tale of Two Cities: Red Hat & JBoss

Red Hat reported great numbers today. The stock was down in after hours trading, and I suspect it will be down tomorrow. The stock movement will likely be based on comments about the JBoss division by Red Hat’s CEO. Forbes reports:

“Sales came in slightly higher than expected, with Red Hat reporting revenues of $127.3 compared to revenues of $99.7 million during the year-ago period. Analysts had expected sales of $125.7 million.

…

Over the past year, Red Hat’s shares have fallen more than 25% as the company has toiled to transform from a Linux vendor into a peddler of a broader array of software.

One big reason: Sales of the so-called application server software Red Hat acquired with its purchase of JBoss last year have disappointed. “The rate of JBoss bookings and revenue growth has not met my expectations,” said Szulik in a conference call with investors. “We know we can do much better.” “

Red Hat Linux is definitely firing on all cylinders. JBoss, in the words of Red Hat’s CEO “could do much better”.

Further comments via CNet:

“However, not all believe the JBoss deal is going swimmingly. Credit Suisse analyst Jason Maynard downgraded Red Hat from “outperform” to “neutral” Monday. “We believe our thesis of improved field execution and meaningful JBoss acceleration won’t materialize and deliver the anticipated upside to our forecast,” he said. “Our checks indicate that the organization continues to be in a state of flux as the company struggles through its transition to a multi-product company.”"

Here’s something I found funny via Reuters:

” Chowdhry of Global Equities Research said the prospects for JBoss were dim because its software was designed to work with the Java programming language. He said Java was losing market share as businesses embrace Ruby, a programming language that is easier to use and works with an open-source rival to JBoss known as Ruby on Rails.”

LOL. RoR is going to kill JBoss…Seriously?!?! If RoR is such a threat, why are other Java app server vendors “doing okay“? Is there something more here? (Hint: yes - I’ll get into it tomorrow).

 

Why Microsoft Should buy Red Hat

Some background:

1. Matt asked “Why doesn’t Oracle just buy Red Hat?”
2. I explained why Oracle would not buy Red Hat
3. Luis Villa replied to Matt’s question: “Because Red Hat employees would leave en masse.”
4. Microsoft announced fiscal 4Q07 growth of 13% on Thursday (or 16% if you only count their true software revenue - which falls into the “Client”, “Server & Tools” and “Microsoft Business Division” reporting categories). Microsoft crossed the $50 billion total year revenue mark with the close of fiscal 2007.
5. I compared Red Hat’s stock performance over the past year vs. some Traditional software vendors (see below)

If you’re still with me….

Red Hat is growing and executing well. Financial analysts expect Red Hat to hit $517M this year (fiscal 2008, ending Feb. 2008), and $631M in fiscal 2009. At this pace, Red Hat should cross the $1 billion revenue mark in fiscal 2011. Red Hat may well be the gorilla in the Open Source marketplace. But after everything is said and done, that marketplace is tiny in comparison to the total software market. If you believe in the stock market’s ability to predict a company’s future value, one could argue that Red Hat investors are in a “sit tight” mode right now. At a P/E of 72 and PEG of 1.44 (vs. Google’s PE of 45 and PEG of 0.99), Red Hat’s stock has likely priced in as much growth and “great news” that we could think of. Few doubt Red Hat’s position in the overall OSS market, but some may be waking up and asking whether being #1 in 1.8% of the software market is enough to drive the multiples that Red Hat shares enjoy today.

While both vendors have strong operating system franchises, Red Hat isn’t really eating into Microsoft’s revenues. IDC predicts that the Linux & Windows markets are growing 26% and 9%, with Unix revenues declining by 3% from 2006-2011. Red Hat’s Jboss division adds a JEE portfolio that does compete with .NET as the infrastructure for enterprise applications. But here again, it’s very unlikely that Microsoft faces off against JBoss in (m)any customer deals. It’s more likely that Microsoft competes against IBM WebSphere, BEA WebLogic or Oracle AS, and JBoss only comes into the picture when the customer has already selected JEE. While there is some overlap, Red Hat is much more complimentary to Microsoft’s offerings than we’d like to think.

Just imagine a Microsoft that could offer customers a choice of Windows/.NET, Linux/JEE or, and here’s the magic, BOTH. The fact is most customers have heterogeneous environments, and those that don’t today, will likely in the future.

In the face of OSS competition, one of the best moves we made in the IBM WebSphere division was purchasing Gluecode. As I’ve mentioned (over and over), having a free application server, based on the open source Apache Geronimo project has done nothing but spur the growth of our overall WebSphere Application Server family. In some cases, the customer chooses WAS CE, in other cases, they choose Traditional WAS products. We help customers be successful with their choice and, equally important, ensure that their previous investments in WebSphere infrastructure are protected. This is exactly the scenario that Microsoft could create for themselves. Microsoft would be able to offer Windows, Linux, .NET or JEE in various combinations to solve customer problems. As a competitor, this would be a scary combination.

What’s more, Red Hat could help Microsoft gain OSS street cred almost instantly. To me, this would easily become Red Hat’s most important contribution to the software industry. Forget being #1 in 1.8% of the software market. How about helping a $50B software company evolve its thinking around OSS in order to become a $75B software company while increasing customer choice and satisfying customer needs? Goosebumps.

I doubt this acquisition will ever take place for three reasons. First, because of vendors such as IBM, HP, Intel and Oracle who have investments in/with Red Hat. Second, because Microsoft wouldn’t want to take the risk. I’d argue that there is much less risk than appears on the surface. Sure, there would be some internal friction during product positioning discussions if the deal went through. But internal friction is healthy and shouldn’t get in the way of helping customers succeed with your offerings. Lastly, as Luis’ comment highlights, Red Hat’s culture would also pose a barrier to this deal. But I’d argue that the only thing that these comments do is put a damper on the deal price, which, at the end of the day, is bad for Red Hat investors. One could argue that JBoss employees felt the same way about Red Hat prior to the acquisition. And yes, some left Red Hat, but some stayed. It would be up to Red Hat management to convince employees about the historic importance of their efforts inside of Microsoft, which would be a pretty compelling reason to stay.

A Red Hat marketing slogan states: “truth happens”, what about “change happens”? And why not help Microsoft change?

PS: I truly doubt this deal will ever happen, but it’s interesting to think about the possibilities.

 

Bill Burke is Angry Bill

Just a heads up that Red Hat’s Bill Burke (of JBoss fame previously) is blogging here. Bill does write about techie stuff at the JBoss Matrix, but this blog seems to go beyond the bits and bytes and get into things like:

Should you start an OSS project at Apache?
Should Interface21 join the standards process?

I’ve had mild disagreements with Bill in the past, but he’s always made me think….and his post on “Apache Business Model failure” is no exception.

I had never thought about “who owns the brand for an Apache project”. Now that Bill points it out, the answer is obvious.

It’s clear that established software vendors prefer neutral communities such as Apache or Eclipse. These vendors seek to jointly develop some widget/product/project and then use it within a commercial offering under their respective brand. As a result, “who owns the brand for an Apache project” is not a very salient question.

I’ve argued in the past that users benefit from projects developed at Apache (or Eclipse) as multiple (competing) vendors and parties have a stake in the direction of the project.

Maybe we’re going to see Apache become the home for OSS projects that are sponsored, in one fashion or another, by Traditional vendors. Additionally, Apache could remain the home for implementations of core technology by individual developers who have a vested interest, but aren’t doing so as their primary source of income.

Note however, I don’t think Bill’s comments have any impact on the importance of the Apache Software License.

Thoughts?

 

The Impact of an 85% OSS Renewal Rate

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.

 

Adding Risk into the OSS Customer Equation

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>

 

Analysis: JBoss to follow Fedora-RHEL model

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