Analyzing tricks competitors play – Comparing products to JBoss community projects

This is my fifth and final article in a series that analyzes marketing and sales tricks I believe Red Hat JBoss Middleware competitors use. (see previous articles 1, 2, 3, 4) In this article I want to discuss the practice of comparing JBoss community projects with competitors products. Wait a minute!!! Don’t all Red Hat JBoss Middleware subscription products have roots in community projects? Yes. Absolutely. You betcha! But Red Hat does not simply lift code from community projects, slap on a product name, and then charge annually for a support subscription. Oh no… there is so much more to preparing a Red Hat JBoss Middleware product for market.

The product journey starts with JBoss community projects that are a rich source of rapid innovation and advancement of technology. While those projects are well suited for advanced prototyping and development projects, they are not the best choice for use in production. For production deployments, I feel it is far better to use Red Hat JBoss Middleware products. Such products draw code from multiple open source projects, are put through rigorously testing, and are certified against multiple technologies such as operating systems, Java Virtual Machines, and databases. Then documentation, training, multi-year maintenance policies, guaranteed patches, updates, hot fixes, legal assurance, and award-winning support are added and made available as part of a subscription. All in all, a lot goes into preparing Red Hat JBoss Middleware products for the market and production use.

So with this in mind, why would a competitor compare JBoss community products against their own? Perhaps mixing analysis of JBoss community and Red Hat JBoss Middleware subscription products within a single comparison. Or worse, evaluating a JBoss community project and then portraying the analysis as one-to-one applicable to a Red Hat JBoss Middleware subscription product! I am not smart enough, or privy to inside information that allows me to speak in definitives, but I have some ideas as to why this behavior takes place.

Perhaps the simplest explanation is that some competitors just don’t understand how the Red Hat JBoss Middleware open source model works. Red Hat competitors may not be aware of content on that discusses the differences between Red Hat JBoss community and enterprise products.1 If reading websites is not desirable, competitors could attend webinars or presentations where the open source model is explained. Pretty basic, yet informative options.

In other cases, perhaps competitors get Red Hat JBoss Middleware product, and JBoss community project names confused. Prior to the renaming of the JBoss AS project to WildFly, I saw competitors regularly mix and match evaluation of JBoss AS with Red Hat JBoss Enterprise Application Platform (JBoss EAP). Such analysis misses the differences between the two. Google, or another search engine, is your friend for finding evidence of this type of behavior. I recommend searching for reports that Oracle commissioned Crimson Consulting to create, and reports IBM commissioned from the Summa Group. In any reports you discover, count how many times the word “JBoss” is used without further qualification.

Short on time right now to dig into the internet and prefer that I provide a specific example? No problem. Here is what I feel is an example of mixing analysis of JBoss community projects and Red Hat JBoss Middleware product in a single comparison. In early 2014, IBM commissioned a paper from the Edison Group that compares IBM WebSphere MQ 7.5 to Apache ActiveMQ 5.9.2 This paper contained an evaluation of Apache ActiveMQ and not Red Hat JBoss A-MQ. In fact, in appendix 2 of the Edison Group paper, the very last point on page 30 in a section that discusses “items not covered in this paper” states “Comparison of WebSphere MQ with vendor branded distributions of ActiveMQ, for example Red Hat JBoss A-MQ”. That is an appropriate disclaimer since Red Hat JBoss A-MQ is a product made up of more components than just Apache ActiveMQ.3 But I am not sure that the Edison Group appreciates that since it did classify Red Hat JBoss A-MQ as a “vendor branded distributions of ActiveMQ”. For that reason and others that I may discuss in a future blog entry (still undecided), I recommend a skeptical eye when reviewing the Edison Group / IBM paper.

Perhaps the Edison Group would have drawn different conclusions if they evaluated Red Hat JBoss A-MQ instead of Apache ActiveMQ. For example, a conclusion made in the Edison Group paper is that any changes in the Apache ActiveMQ configuration model requires a broker restart. True for Apache ActiveMQ, but not for Red Hat JBoss A-MQ. Instead, Red Hat JBoss A-MQ, capitalizes on the OSGi Admin service that is part of the Karaf container to avoid the Apache ActiveMQ behavior Edison Group points out. With this added capability, the Red Hat JBoss A-MQ container combines both the Apache ActiveMQ XML configuration and OSGi persistent identifier(PID) properties to manage a broker instances runtime configuration and can eliminate the need for restarts. This is just one of many differences between Apache ActiveMQ and Red Hat JBoss A-MQ.

Let me recap a few items from the Edison Group / IBM example and then ask a question. Clearly Red Hat JBoss A-MQ is much more than just a packaged up Apache ActiveMQ distribution. The Edison group was clear that they evaluated Apache ActiveMQ and not Red Hat JBoss A-MQ. There does not appear to be a one-to-one relationship between the two. So is it appropriate to use the Edison Group paper as a basis for publishing competitive content against Red Hat JBoss A-MQ? I don’t think it is, and thats why I dislike a blog entry on WhyWebSphere.com4 that appears to me to do just that. In that blog, an IBM employee (at the time of this article5), flips back and forth between referencing Apache ActiveMQ and JBoss A-MQ. Further, there is extensive use of an unqualified “A-MQ” used throughout the article. Is “A-MQ” an abbreviation for Apache ActiveMQ or Red Hat JBoss A-MQ? It is important to know this since unverified performance tests for “A-MQ” are referenced and used in the WebSphere MQ vs. Red Hat JBoss A-MQ cost calculations. Since the goal of the IBMers blog is a cost comparison, I am inclined to believe that the use of “A-MQ” is shorthand for Red Hat JBoss A-MQ and therefore misleading. But you are free to draw your own conclusions.

I hope you enjoyed reading this article and welcome your feedback. If you are aware of other examples where competitors compare products to JBoss community projects please let me know! –

1“Red Hat JBoss Community or Enterprise.” JBoss Developer Projects vs. Red Hat JBoss Middleware. Red Hat. Web. 17 Nov. 2014. <>.

2“IBM WebSphere MQ 7.5 versus Apache ActiveMQ 5.9: Failover, Transactional Integrity and Administration.” Edison Group. Edison Group, Inc. with IBM Assistance and Funding. Web. 17 Nov. 2014. <>.

3“Red Hat JBoss A-MQ – Component Details.” Red Hat Customer Portal. Red Hat. Web. 18 Nov. 2014. <>.

4Kharkovski, Roman. “WebSphere MQ vs. Red Hat JBoss A-MQ Cost Calculator.” WhyWebSpherecom Blog. 30 July 2014. Web. 17 Nov. 2014. <>.

5Search for “Roman Kharkovski” – “Search Results.” Employee Directory. IBM. Web. 17 Nov. 2014. <>.

Leave a Reply

Your email address will not be published. Required fields are marked *