ZeroMQ Forked by its Creators

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.