|
Recent
Articles |
Carving A Well Qualified Java Tiger Programmer
Sun Microsystems offers many certifications starting from programmer level to architect level. The latest version of the programmer (SCJP) exam is SCJP 5.0 - Sun Certified Programmer for the Java 2 Platform, Standard...
SCEA - Carving A Well Qualified J2EE Architect
Sun Microsystems offers many certifications starting from programmer level to architect level. SCEA (Sun Certified Enterprise Architect) certification is designed for enterprise architects responsible for building high...
Exadel Partnership (A Rose By Any Other Name)
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...
Null Java References In Coldfusion 6 Vs 7
ColdFusion 7 appears to be much better at passing null values to a java object. ColdFusion 6 however likes to block you from doing it, even when you want to. I am tring to work with a java API that requires me to...
Open Up & Say Growth
Matt points to an interesting article about using an open business model. Not sure if the author, Henry Chesbrough mentioned that IBM made significantly more than $100m/yr in revenue as a result of its Linux...
SOA: Assistance With JBI Application Integration
The methodology of Enterprise Integration has advanced to Service Oriented Architecture (SOA) because of its ability to weave disparate applications and services to produce a business structure where data can flow...
Java And Open Source
In November, Sun Microsystems moved to "open source" status for Java, after a decade of maintaining proprietary status for the portable programming language.
Java Not True Test Of Open Source Innovation
My thesis advisor keeps reminding me to frame the question correctly, otherwise the experimental results will be meaningless. After reading this article by Dana...
JBoss CEO: Show Me The Money
Sys-Con is quoting Marc Fleury, JBoss founder & CEO and now SVP & GM of JBoss Division at Red Hat, as having said:
"(while Red Hat) really haven't gotten in the way"…"the R&D really hasn't benefited from a...
|
|
 |
|
04.24.07
JBoss To Follow Fedora-RHEL Model
 By Savio Rodrigues
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).
Comments
About the Author:
I am taking a semi-break from IBM life as I return to finish a PhD in Industrial Engineering. I've held roles in market intelligence, strategy and product management. I'm ex-product manager of IBM WAS Community Edition, and blog about enterprise open source topics.
|
