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