2016-01-16

Apache Camel and other ESB products (Camel vs Mule) - 5 years later

Yesterday Raul Kripalani (a fellow Camel rider) posted a tweet:
Shoutout to @davsclaus & #Camel riders! Just added a reflection upon the last 5y on this SO question: https://stackoverflow.com/questions/3792519/apache-camel-and-other-esb-products/34818263#34818263 …. Have a look!
The tweet refers to an old question on stackoverflow about the Apache Camel versus other ESB, and this question is in particular about Camel vs Mule.

The question was asked in September 2010, and now fast forward 5+ years Raul took a look at the situation today. I think his detailed answer is worth attention for users of Camel, and others who are doing assessment on integration software.

Rauls answer starts out as shown below. I suggest to go read his post - after you have finished reading this blog ;). And you are welcome to use the upvote ;)


I think Raul has some major points to point out about the difference between Camel and Mule.

The key differentiator I see is, the non technical aspects, Apache Camel is:
  • 100% truly open source
  • Open community
  • Everything is discussed and happening in the open
  • Anyone can participate (and become a committer)
  • No control of a single vendor
  • All branding and marks belongs to ASF
  • ASF is a non-profit foundation where companies cannot control it
  • All code is open source and ASL licensed (no open-core/community vs enterprise model)
  • No vendor lock-in

An maybe overlocked fact is that the branding and marks of Apache Camel belongs to the ASF foundation. So no commercial company can "take the brand" and run with it. Neither Red Hat or Talend etc. can create a product called Red Hat Camel, Talend Camel ESB etc or some variation of the project name. Apache Camel is the authentic project.

Other projects may encounter such a problem. For example docker is very famous brand today, and there is no neutral foundation that owns that brand, the brand is owned by docker.inc (the company). So IMHO there is an interest of conflict with the brand name and docker.com the commercial company.

Another important aspect of Apache Camel (and ASF projects) is that there is no open-core/community vs enterprise model. At Apache Camel we would never deceive the community, for example by learning which Camel components that are the most popular and remove the source code from the community version and put that under a different license in a closed-source enterprise only product.

We from the Apache Camel project do neither spread/post FUD and eschewed marketing stunts on the Apache Camel website, unlike Mulesoft, where they are doing that by posting their controversial Mule vs Camel post on their commercial website. The piece of material smells of corporate bullshit, and no true honest developer would write such a piece of ...  (excuse my english)

And a final note Its also worth referring people to the previous blog, which also spun from a tweet where you can easily compare projects on blackduck, such as Camel vs Mule.



With Apache Camel it is all about the community, for the community, and all work is done in the open. Anyone can participate and we love contributions.

Roll on 2016 its going to be another great year for the Camels.



4 comments:

Mahesh Biradar said...

Very true ....Apache Camel it is all about the community, for the community.

Souciance Eqdam Rashti said...

Thanks for the post. I haved played a bit with Mule for the past 1-2 years on own just to see how it compares to JBoss Fuse and IBM Integration Bus. I would say comparing Apache Camel with IBM Integration Bus or Mule is like comparing apples vs oranges. Ideally it would be nice to compare the actual commercial versions such as Red Hat JBoss Fuse, Talend or others vs Mule vs IBM. That would make more sense.

For obvious reasons as you stated in the blog Camel is an Apache project and open source. Mule is a commercial software out to make money so should be compared to similar commercial projects. Also if I am not misstaken another reason to compare the commercial implementations of Camel such as JBoss or Talend is because they contain the runtime environment for Camel to run inside i.e. the osgi container or similar. IBM has its runtime and Mule its own.

Bruno L. said...

While I think the project and the social/community parts are critical, both you and Raul did not compare Mule and Camel technically, as in ease of use, ease of implementation of the integration cases, debugging, message throughput, etc.

I miss the pragmatic, developer and operations, side of the comparison.

Claus Ibsen said...

Bruno.

We have a list of links to some 3rd party blogs about comparing Camel to X. You can find it at
http://camel.apache.org/articles

Anyone who do integration software assessments should do technical evaluations. But IMHO the most important aspect is all the non technical. Real open community and open source is paramount to ensure the best software and no vendor lock-in.

The gated and open-core module with a dubious license is just another word for "close source big vendor bully" which we had a lot of in the past, where customers are under their mercy and paying to much $$$.