TIBCO has a page on their web site that is titled “The alternative to an open source ESB”.1 Emblazoned across the top of the page is an image of what appears to be a boy battling a stubborn mule. There seems to be plenty of innuendo that TIBCO is targeting MuleSoft with the pages content. And in that regard, I consider several of the points made valid as applied to evaluating MuleSoft.
However, I would suggest that TIBCO rename the page to “Why TIBCO is better than MuleSoft” and drop the innuendo. If TIBCO doesn’t want to call out MuleSoft directly, then “The alternative to an open core ESB” in my opinion would be a better title. Why suggest a title that differentiates between open core and not open source? Well, let dig into that from a Red Hat perspective. THE leader in open source.
First lets look at what TIBCO views as open source myths. The first myth being that open source has a high TCO associated with it. This is a common tactic used by expensive proprietary software vendors like TIBCO and IBM. Such companies would have you believe that up front license costs are trivial in the long term. While license costs certainly are only part of an overall TCO calculation, they are generally not “trivial”. If you use proprietary software from TIBCO, IBM, or others, dig up some invoices with line item licenses fees. I think it is a fair bet you could initiate some non-trivial business activities at your company with the license fees listed. Not to mention the annual maintenance fees that typically run 20-25% of license fees.
But I am down for countering the TIBCO TCO challenge. For my evidence, I encourage you to take a look at the ROI results contained in a recent IDC study of six organizations using Red Hat JBoss Fuse.2 Within that Red Hat commissioned paper, you will find that IDC uncovered an average payback period of 8.2 months and total return rate of 488% over three years. The drivers for these results: more applications integrated per year, fewer full-time employees per integration project, less downtime, improved performance, and lower cost than preexisting integration middleware. I suspect even TIBCO and IBM would be forced to agree that is pretty good if forced to be intellectually honest.
Lets move on to the question, is TIBCO wrong when they state “You’ll pay for services, support—and as your business grows—for costly value-added features that will become necessary to meet SLA requirements”? Partially. With TIBCO, MuleSoft, Red Hat, and other software companies, you will pay for services and support. That is just common. However, paying extra for “value-added features that will become necessary to meet SLA requirements” is something you won’t encounter with Red Hat. JBoss Fuse contains all the functionality bundled with that product in one subscription. There are no extra fees with JBoss Fuse for items like connectors that you can run into when using TIBCO and MuleSoft products. There are no extra fees with JBoss Fuse for a messaging platform like you will find with TIBCO and MuleSoft products. So while TIBCO is pointing out the prospect of extra fees with MuleSoft, without intentionally doing so, they open themselves up to the same critique. However, such extra fees are not something you will experience with a Red Hat JBoss Fuse subscription.
The second item TIBCO believes is an open source myth is that “Open Source ESB Communities Innovate Faster”. The proof TIBCO offers around this has to do with community size and specifically stating that “Many open source projects have large user communities, but the source is generally controlled by a small number of contributors”. TIBCO didn’t offer any examples with hard numbers to back up this claim, but I get the idea of what they are trying to convey all the same.
It is true that the community size associated with open source will vary by project. Much like a proprietary startup that starts with small number of employees, a new innovative open source community is often started by a few visionaries. As the project grows in popularity, so does the community size. With more contributors, it stands to reason that more project innovation can take place and at a faster pace than when it started.
What about the Red Hat JBoss Fuse community? Well, actually, JBoss Fuse like all Red Hat JBoss Middleware products is actually assembled using a collection of code from multiple open source communities. In the case of JBoss Fuse, the majority of code comes from the Apache ActiveMQ, Apache Camel, Apache CXF, Apache Karaf, and Fuse Fabric projects. Each project has a sizable community who represent a variety of companies working on the open source code:
- Fuse Fabric by way of the Fabric8.io project has over 200 team members.
- The Apache ActiveMQ project has nearly 50 code committers and roughly 75 contributors.
- The Apache Camel project has around 40 code committers and roughly 90 contributors.
- The Apache CXF project has around 30 code committers.
- The Apache Karaf project has around 22 code committers.
The size of the overall community contributing to projects associated with Red Hat JBoss Fuse is substantial. In fact, it adds up to a sizable development staff some proprietary companies would be hard pressed to match. But measuring community size—including Red Hat associates—alone fails to account for the worldwide population of Red Hat associates associated with the success of Red Hat JBoss Fuse product via support, services, and more. But lets stay on topic and not drift away from the size of the open source community TIBCO raises.
Perhaps a source of confusion for TIBCO came from trying to measure the size of the MuleSoft open source community. A logical first step to do this would be to find the repository for the MuleSoft core source code. Notice I mention core source and not open source code? I did that intentionally and in consideration that MuleSoft offers proprietary code available only via a subscription for Mule ESB. That proprietary code provides important functionality and runs on top of an open source core. Features like high availability, transaction support, monitoring, security, role based access control, and more is not available using the open source version of Mule ESB.3 At best I feel MuleSoft earns an open core moniker, but not open source.
But back to finding the MuleSoft open core repository. Where is it? Oddly enough, the MuleSoft Mule ESB page contains no links to it. Perhaps odder, the MuleSoft developer community web page has no links to it that I could find.4 In fact, I failed to find any links to the MuleSoft source code repository on the entire MuleSoft site despite my best efforts. Shouldn’t an open source community and associated source code be easy to find?
Ultimately, Google search proved to be my friend and I tracked down the MuleSoft repository on GitHub.5 Within the Mule community edition code page, I found 51 contributors listed. Unfortunately deriving the companies that the contributors work for is not clear on Github, so the diversity of the community can’t be determined. Several MuleSoft employees like Ross Mason were east to spot. However, for many contributors, no company affiliation is revealed. The counts as I have presented them don’t lie, and it is clear that the community working on Red Hat JBoss Fuse related projects far exceeds the numbers working on the MuleSoft Mule community edition project.
How many developers are there working on TIBCO open source ESB projects? Well, none as far as I can tell. There is no indication TIBCO offers any open source ESB product. Instead, it appears that TIBCO only has a proprietary closed source ESB solution. TIBCO states on its web page that “if the open source business model being leveraged is proposing added value on top of the community version, then the source is controlled by the vendor just like any other commercial offering.” I think this point rings clear with both MuleSoft and TIBCO. MuleSoft confirms on its product web page, that significant amounts of Mule ESB functionality in the enterprise edition is not available in the community edition.6 However, TIBCO completely misses the mark on this topic with regards to Red Hat JBoss Fuse and the related open source community projects. JBoss Fuse functionality is truly based on open source community code. That said, there are significant advantages to using a Red Hat JBoss Fuse subscription in production rather than simply lifting and using the open source code. The Red Hat advantages in this regard that are presented in detail within the Subscription Guide for Red Hat JBoss Middleware.7 I encourage you to download and review the document.
This leads to the next item TIBCO believes is an open source myth, “Access to Source Allows Reviewing Code and Deploying Safely”. Specifically, TIBCO asks the questions, “How do you know there aren’t IP issues in the code, like in the Novell/SCO UNIX case? Will your vendor indemnify you against lawsuits?” Good question, and one that Red Hat answers with the Open Source Assurance program. The Open Source Assurance program provides certain assurances to customers in the event there is an intellectual property issue with Red Hat Enterprise Linux, JBoss Enterprise Middleware Suite or any other Red Hat branded subscription product. These assurances include (i) replacing the infringing portion of the software, (ii) modifying the software so that its use becomes non-infringing, or (iii) obtaining the rights necessary for a customer to continue its use of the software without interruption. As an additional protection, Red Hat also provides indemnification in its Open Source Assurance program. All customers with valid Red Hat subscriptions are eligible for the Open Source Assurance program.
With the Red Hat Open Source Assurance program, the TIBCO myth point is well negated. However, TIBCO also raises the points that “IP issues aside, source reviews don’t help you assess security, scalability, interoperability, or other important architectural features. By its very nature, open source is also less controlled in deployment and patch management.” Now it may seem odd to hear me agree with TIBCO on this. But yes, I agree that open source in its raw form can indeed have risks associated with it. That is why Red Hat invests significant time and effort addressing these and other issues when creating enterprise ready version of open source projects that are available via a subscription. As mentioned earlier, what Red Hat does in this process is extensive and well documented in the Subscription Guide for Red Hat JBoss Middleware.8
The final item TIBCO believes is an open source myth is “Open Source and SaaS Work Well Together”. The proof point TIBCO offers basically comes down to you don’t know what you don’t know. Specifically, “cloud-based open-source ESBs work just like other SaaS applications: you typically don’t have access to the code. How well will it connect your on-premise applications with other SaaS services? You can’t know.”
I would say that the point TIBCO is trying to make here is flawed. Primarily, TIBCO overlooks the fact that it is in the best interest of SaaS companies to make products that are easy to integrate with. Product versions for products like Siebel CRM and Oracle E-Business Suite which for so long only offered connectivity via proprietary interfaces are relics. Today, open standards for connectivity such as RESTful and web service endpoints are the expected norm. Companies like Salesforce.com and Workday rely on open standards for integration. Why does it appear TIBCO expects something different? Does TIBCO feel that customers should be looking for proprietary companies colluding to create expensive connectors that exploit closed integration endpoints? I find that hard to believe. Honestly, if I could advise TIBCO on its web site content, I would certainly encourage them to withdraw what I feel is clearly not a well thought out proposed open source myth.
Overall it does not surprise me that TIBCO is concerned about the success of open source technology in todays technical landscape. Red Hat provides enterprise-strength, mission critical, software and services in today’s most important IT areas: Operating Systems, Storage, Middleware, Virtualization, and Cloud Computing. All while embracing an open source model that supplies enterprise computing solutions that reduce costs, improve performance, reliability and security. The Red Hat 2015 annual report showed that in that fiscal year, the company had:
- $1.79 billion in total revenue, an increase of 17% over fiscal 2014
- $180 million in net income, or $0.95 per diluted share
- $1.48 billion in deferred revenue at the end of fiscal 2015, an increase of 15% over fiscal 2014
- $623 million in operating cash flow, an increase of 15% over fiscal 2014
- $1.81 billion in cash and investments at the end of fiscal 2015
One can argue that Red Hat has done very well in the market place. How TIBCO is performing is harder to determine now that they have reverted to a privately held company. On the surface, the private equity purchase may seem like good news for TIBCO customers since the company has not been split up and sold in parts. But could such action still occur? Could there be other potential causes of concern? I think it is reasonable for TIBCO customers and prospects to be wary of the following potential actions:
- Reduced or minimized investment in product development and support
- Workforce consolidation and reduction (Engineering, Sales, Marketing, Support teams)
- Product roadmap changes, slow-downs, or retirements
- Deferred investment in crucial areas like Mobile and Cloud
- Potential spin-off of products into independent companies
- Merger with another Vista Equity company
Even future sale of all or part of TIBCO is not out of the question.
- BigMachines, which Vista Equity acquired in 2001 was sold to Oracle in 2013 for an estimated $400M.
- Vista Equity acquired MicroEdge in 2009 for $30M and sold it to Blackbaud for $160M in October 2014.
- In February 2014, Vista Equity merged two of their companies, Lanyon and ACTIVE Network Business Solutions Group.
- Vista Equity announced that they were seeking buyers and considering an IPO for Misys, a company acquired in June 2012 and merged with Turaz, another Vista Equity company.
Will it be possible for the public to measure workforce reductions or reductions in R&D spending? That could be difficult. By taking TIBCO private, there is no longer a requirement to share financial information like publicly traded companies are. For customers and prospects, this means little or no visibility into how TIBCO will be investing its capital. Likewise, there will not be an easy way to determine how TIBCO is doing compared to industry peers by comparing financials against other publicly traded high-tech companies.
TIBCO lashed out at MuleSoft on its web site that titled “The alternative to an open source ESB”.9 However, as presented in this article, I feel TIBCO missed the mark on open source in general, and Red Hat specifically. If you are looking for TIBCO alternatives, I encourage you to take a look at what Red Hat, THE leader in open source, has to offer for integration products.
1“The Alternative to an Open Source ESB.” Open Source ESB Alternative. TIBCO, n.d. Web. 16 July 2015. <http://www.tibco.com/integration/open-source-ESB-alternative>.
2Maureen Fleeing. “The Business Value of Red Hat Integration Products.” IDC (2014): n. pag. Dec. 2014. Web. 16 July 2015. <https://www.redhat.com/en/files/resources/en-rhjb-idc-business-value-253233.pdf>.
3“Mule ESB Enterprise.” MuleSoft. N.p., 14 Jan. 2015. Web. 16 July 2015. <https://www.mulesoft.com/platform/soa/mule-esb-enterprise>.
7“Resources.” Subscription Guide for Red Hat JBoss Middleware. Red Hat, n.d. Web. 16 July 2015. <http://www.redhat.com/en/resources/subscription-guide-red-hat-jboss-middleware>.
8“Resources.” Subscription Guide for Red Hat JBoss Middleware. Red Hat, n.d. Web. 16 July 2015. <http://www.redhat.com/en/resources/subscription-guide-red-hat-jboss-middleware>.