My travel has mostly focused on meeting with customers and partners to understand their needs, share our strategy, and discuss ways we might be able to help them.
In these discussions, I typically cover our strategic roadmap and development model for the JBoss Enterprise Application Platform and other JBoss Enterprise Middleware products.
Since the Red Hat / JBoss business model is built on selling subscriptions, the discussion leads to the definition of a Subscription.
Put simply, a Subscription is comprised of:
- Software bits
- Patches and updates to the bits
- Support in the use of the bits
- Legal assurance
While there's much more to say about each bullet point, that's basically the definition in a nutshell.
Since our products are open source, some people associate subscriptions with just support. In my Open Source Business Models: Definition of Support posting, I make the case that our customers need more than just support...which is why we are in the business of selling Subscriptions.
4 comments:
One question concerning the EAP version: This is distributed under the LGPL as well (for the application server), right?
That means that any customer has the right to redistribute it to others. That's fair.
So you mean the improvement I get with a subscription is that if I am on EAP 4.0 and I need a patch I don't need to upgrade to EAP 4.1 to get the patch but get a patched EAP 4.0 from JBoss/RedHat?
Re: Patches: We provide regular cumulative patch releases for specific versions so customers are not forced to upgrade versions to get fixes. Ex. Customers on EAP 4.2.0 get access to regular patches in EAP 4.2.0CP01, EAP 4.2.0CP02, etc. and are not forced to upgrade to a completely new version.
Re: License: The end user license agreement (EULA) for JBoss Enterprise Middleware products can be found at:
http://www.redhat.com/licenses/jboss_eula.html
You are correct that the LGPL is the dominant source code license for JBoss products. The EULA provides additional terms around the distribution that the LGPL license does not directly address, such as terms around trademark, warranty, and export control.
As JBoss and it's infrastructure does not hold critical data that may be lost of corrupted (like file systems and databases), what would in that case be the benefit of a subscription for someone that got high quality consulting services from an independent consulting company that provides its services on the community edition of JBoss ?
As mentioned in my blog, one element of a subscription is providing patches and updates to the bits.
If fixes are handled externally, you've effectively forked the code and it is now up to you to manage the source code changes.
So one question arise: are you in the business of understanding, maintaining, and patching middleware or creating solutions that run on middleware? With the subscription, you get fixes from the engineers who actually create and work on the software on a daily basis.
Look at Continental Airlines as an example:
http://www.jboss.com/customers/continental_airlines
Is this system running on JBoss considered business critical to them? I'd think they would say yes. And if their application ran into an issue that requires a fix to our software, they want it fixed on their particular version and not be forced to upgrade to a completely new version to get it.
The cool thing about the open source model is that if the community version is good enough for your needs and you don't think you need support or patches for your deployment, then you are free to use the community version.
If your application is mission critical and you require specific SLAs, then a subscription is likely better for you.
The cool thing is that the choice is yours...which is a good thing.
Post a Comment