[zeromq-dev] Preliminary results of voting

Ritesh Bansal rbansal at gmail.com
Wed Sep 3 09:03:13 CEST 2008

pieter -

the answer to your question is an unqualified "yes". the question is
sufficiently important to flesh out and add some color.

the challenge facing the zeromq community - fastmq, imatix and the user
community - is to foster uptake. i cannot sell zeromq as a viable solution
yet in my organization - and we are fairly geeky and edgy when it comes to
technology. two reasons - it has very little usage in our community and lack
of interfaces. once there is uptake - it sparks a virtuous cycle. think
mysql - which is perhaps today the most successful OSS story - other than
Linux itself. mysql did almost everything right and very little wrong. the
negative example to this is spread - whose development and uptake has both
stalled since it came out over 5 years ago due to various strategic mistakes
spread concepts made.

so what kind of interfaces/features can be built and who should build them?
one taxonomy:

core functionality: topic based routing, multicasting, lower latencies....
os ports: linux, solaris, freebsd, windows...
languages: perl, java, python, javascript
protocols: xmpp-whatever
tools: excel, mysql, apache
bridges: exchange adapters...

one might say that this poses a chicken-egg problem. evangelize first or go
heads down and add as many of the above as you can?

i think a middle ground approach can work. add core features - those lower
down the stack - core functionality - portability and rely on the community
to add the higher level features.

evangelism in the open source community should be right up there. getting
zeromq included in the various linux distros should be right up there.
showing zeromq off at the various open source dog-and-pony shows should be
right up there.

the example of unix is quite instructive. att was forced to give away the
source code and not charge for it by a justice department decree. this made
unix quite the favorite of operating systems professors as they could get
their hands on real os source code for their classes. a whole lot of
students in universities grew up playing with unix source code. the rest is
history. you need to get the oss community hooked on this - imho the
financial community is too reactionary and closed to be the early adopters.
i might be wrong and in this case i hope i am.

to answer your direct question - about building bridges to existing feeds at
the edges of the financial data distribution - i think you have to
evangelize it to firms who are natural partners - the ones who write feed
handlers and do not have their own cutting edge messaging platforms. wombat
got swallowed by nyse and they do have their own messaging platform but i
think they could be natural partners. infodyne - i think they got acquired
too. and so on.....same goes for market data creators - the exchanges
including the otc ones.

i do not see any competitor to zeromq but i do know a few closed source
messaging vendors. these vendors are now stuck with a hard to sell product
and an uncertain economic future - remember talarian? however, once zeromq
gets some traction, they will see the light. open sourcing to build critical
mass will be a natural strategy for them. user base = high valuation and
probably high revenue.

the window of opportunity for zeromq will start tightening once they realize
this.  then again blindness and (economic) stupidity might still rule the

ps: we hacked rtd onto tibco in a few weeks and fairly junior level
developer did it. granted, we only exposed a subset of the tibco
funcationity - but a trader can hit enter in a cell and send a tibco message
to a trade process and receive streaming data/analytics in their

On Tue, Sep 2, 2008 at 5:20 AM, Pieter Hintjens <ph at imatix.com> wrote:

>  Are you suggesting that making 0MQ work well on the desktop will encourage
> firms to use it for distribution of data to the edges of the network?
> So then there would need to be bridges from existing messaging
> products to 0MQ as well?
> -Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20080903/ec2496e5/attachment.htm>

More information about the zeromq-dev mailing list