BT

ZeroMQ Forked by its Creators

by Jonathan Allen on Mar 26, 2012 |

Martin Sustrik and Martin Lucina, creators of the original ZeroMQ, have decided to regain control of the project by forking it. The new project, named Crossroads I/O, is being setup to encourage a commercial ecosystem that is better capable of meeting their long term financial needs.

Before we get more into Crossroads I/O, a bit of history is in order. The story starts with John O'Hara’s Advanced Message Queuing Protocol (AMQP) in 2003. Its owners, JPMorgan Chase & Co, contracted with iMatix in 2004 for a “C broker and protocol documentation”. A year later JPMorgan Chase & Co decided to form a working group with other major firms including Cisco Systems and Red Hat to turn the project into a standard.

While AMQP wound its way through various committees it picked up several independent implementations. In addition to the original Apache Qpid, frameworks such as RabbitMQ, JORAM, and StormMQ started appearing.

Meanwhile iMatix’s CEO Pieter Hintjens was growing increasing frustrated with AMQP. In his own words,

While iMatix was the original designer of AMQP and has invested hugely in that protocol, we believe it is fundamentally flawed, and unfixable. It is too complex and the barriers to participation are massive. We do not believe that it's in the best interest of our customers and users to invest further in AMQP. Specifically, iMatix will be stepping out of the AMQP workgroup and will not be supporting AMQP/1.0 when that emerges, if it ever emerges.

Pieter Hintjens wrote this in March of 2010 as part of his announcement for ZeroMQ. iMatix purchased ZeroMQ in September of the previous year from Martin Sustrik and his company, FastMQ. Pieter described ZeroMQ as:

ZeroMQ is significantly simpler and faster, and yet achieves much of the same functionality. It does this by delegating as much as it can to existing parts of the stack. I'd like to congratulate Martin Sustrik, the chief architect and maintainer of the product, for his vision and execution. ZeroMQ will, we believe, succeed in making messaging a 1st class citizen of the Internet, where AMQP has in our view failed.

While ZeroMQ has been getting a lot of positive press lately, it should be noted that AMQP didn’t end with iMatix. The final version of the AMQP 1.0 standard was published in October 2011. The OASIS AMQP technical committee, which was formed the following month, is working on pushing the standard through the international open standards process.

Skipping forward to this month, Martin Sustrik announced that he and another ZeroMQ contributor, Martin Lucina, have forked the project and created Crossroads I/O. The project describes itself as:

Crossroads I/O …

… is lego bricks for building scalable and high performance distributed applications.
… is what BSD sockets might have looked like if designed for today's requirements.
… is message based, and supports many different network protocols.
… works with all programming languages, all operating systems.
… is part of a wider effort to make messaging a standard part of the networking stack.
… is Free Software licensed under the LGPL license.
… is a fork of the ZeroMQ project.

The explanation for the fork was given as a single sentence:

The contribution and trademark policies of the ZeroMQ project were, as of March 2012, incompatible with our long-term goals.

As mentioned in the opening, one of these goals is to create a viable commercial ecosystem around Crossroads I/O. The founders of Crossroads I/O believe that this is only possible if the project is fully vendor neutral and has “a liberal (e.g. Linux-style) trademark policy allowing use of the trademark for third party distributions of the software, as well as for plug-ins and extensions.” By contrast, iMatix’s trademark policy reflects their investment in the product and their desire to retain full control over the ZeroMQ name.

For the short to mid-term, Crossroads I/O seeks to become the de facto user-space implementation of the messaging layer:

When striving for world domination, the first step should have the biggest possible impact. Thus, instead of implementing the messaging layer in a particular OS, we provide a highly portable user-space library. To achieve this goal we use a common implementation programming language (extremely conservative C++) and we try to keep dependencies to a minimum.

Long term they intend for the commercial ecosystem they hope will develop will provide the resources necessary to carry them beyond the user-space library phase.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Good goals, but .. by Cameron Purdy

Looking at Crossroads I/O (and ZeroMQ) is a great reminder me of why I don't want to write C code anymore. And the funny thing is you can get as good performance numbers in a language like Java.

Peace,

Cameron Purdy | Oracle

Re: Good goals, but .. by Thom Nichols

Well, isn't it written in C so that there can be language bindings in all the higher-level languages? Sure if you were targeting Java only you could write everything in Java but then you would have to re-write the whole stack for Python, Ruby, etc.

Re: Good goals, but .. by Cameron Purdy

It's just a binary wire protocol. Come on, you could even write that in VB. ;-)

I guess it's written in C because they needed a C messaging library. One that silently loses messages (on purpose!) according to the documentation. Nice touch.

Peace,

Cameron Purdy | Oracle

Not the first time Pieter has spurned partners... by John O'Hara

Pieter's blog on this is interesting:
www.imatix.com/articles:crossroads-fork

Perhaps now people will understand that the two dozen companies that kept working together on AMQP were the reasonable ones.

If you want MOM for the cloud whether VMware, Microsoft or Red Hat there's only one credible Standard: AMQP 1.0

Re: Good goals, but .. by John O'Hara

Which is actually what you need. Compiling and linking into a scripting environment can be painful and a profound source of crashes and performance issues. You also need a full tool chain and to align the compiler flags.

It's much more pleasant to have a client in the host language, its much easier to get running and to debug if needed.

In the end, you end up with a handful of trusted clients - much like for database clients.

Re: Not the first time Pieter has spurned partners... by John Jefferies

Pieter's blog entry is no longer available, but I assume there was a rant in there.

John, you don't know me and I don't know you. I'm just taking you up on your assertion that you are a reasonable man. Your entry against this blog:
kellabyte.com/2012/10/20/clarifying-amqp/

looks like an unprovoked attack on Pieter to me and uncalled for in the context of the blog. Mind you, Pieter's reply was very witty and entertaining prose and worth reading.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT