[Quickfix-developers] State of the Engine Address

[<or...@qu...>]

Well, I thought it was about time we had a State of the Engine Address,
and no, I'm not referring to sequence numbers or IP addresses (well,
maybe a little).

So QuickFIX is well in it's 3rd year now.  QuickFIX first went live into
several production environments two months after it's initial 1.0
release.  Since several of these systems are still active, this means
are longest running full time production deployments have been going
strong for 3 years. (One of these is now a major online brokerage).

Last year I had mentioned the major shift in attitude towards open
source software in corporate settings.  We saw a huge burst in
downloads and usage of QuickFIX.  I'm happy to say that the trend has
continued.  We do very little traditional promotion of QuickFIX, so it
can only be attributed to word of mouth.  Quite incredible how often
you guys talk to each other, but then that is what FIX is supposed to
accomplish.

I can't even begin to cover all of the new deployments.  Some notable
ones include the CME's very successful rollout, and Deutche Boerse's
Xentric FIX Gateway.  As many of you may know, my position concerning
QuickFIX is that it complements as often as it competes with commercial
offerings.  The Xetra/Eurex solution is a perfect example of a product
rolled out with a combination of both CameronFIX and QuickFIX offerings
to provide a complete FIX solution.

* FUTURE RELEASES *

Much work has been done in preparation for the next release.  1.9.4 has
been quite successful.  At this point, we have enough stuff to
constitute a major release.  Some of these are bug fixes, new features,
better error reporting and such.  Not everything on our plate right now
is going to make the cut for this release.  We are currently targeting
a release date some time this month.  After that, we will probably
follow up with a another release in a relatively short period of time
that has everything we want.

We are also working on adding support for more databases.  Caleb Epstein
has contributed support for Sleepycat Berkely DB, and we are also
looking at Postgres and MSSQL.  These will probably show up a couple
releases down the road.

* ADOPTION *

Our goal for the next year will be to make it easier for people to adopt
QuickFIX.  Early on, we focused our efforts on getting software
developers and technologist familiar with QuickFIX.  All along I have
credited software developers with being the driving force for
introducing new technology into company infrastructures.  Well the
executives have noticed, and they have a lot of good questions of their
own.  Why?  They generally have a board of directors to report to, and
QuickFIX is becoming a topic in a lot of board rooms.

There are three fronts in which I'd like to address this issue:
Technology, Information, and Responsibility.  

Through technology, we need to make QuickFIX as easy to evaluate as
possible.  Last year we introduced pre-built windows binary
distributions that have proven very popular and lowered one barrier to
entry ( Visual Studio license ).  We must continue to focus on making
the technology even easer to get started with.  Not only that, we must
provide tools in which companies can easily perform benchmarks on their
own hardware.  Anything that will make it possible for a company to
easily evaluate if QuickFIX meets their needs.

Information covers many things. It covers the documentation of the
product itself, which should see improvements in organization and
content.  But it means so much more than that.  So many people look at
QuickFIX and they just don't know what exactly is going on.  Often
there is the impression that QuickFIX is a fringe player that is used
by only small firms.  They don't know that it is in heavy use by many
of the largest financial institutions in the world.  That makes a big
difference to the board of directors.  It is important for us to gather
the information executives need so we are ready to answer the questions
that come up over and over again.  I've talked to many of them, believe
me, they are always the same questions. (That just means they all have a
common problem that needs a solution).

Responsibility has always been the albatross of open source.  Last year
Connamara Systems and Macdonald Associates began offering QuickFIX
support contracts.  They essentially said that they will take the
responsibility for support that is comparable to those offered by
commercial software providers.  Just the fact that these support
contracts exist has made a big difference in adoption.  I hope that
this experiment proves successful for them as it will be a great
benefit to the project.  We must continue to find other ways to
demonstrate the commitment to the future of QuickFIX.  I'll be
discussing more on this at a future date.

* FPL *

We plan on applying for FPL membership in the near future (they have
expressed interest in our joining).  This will give us greater
influence on the future direction of the protocol.  With
quickfixengine.org as an FPL member, we will be able to represent the
interests of QuickFIX users.  There are some interesting things going
on with the FPL, and I feel it is important that we voice our desire
for the protocol to remain open and free.  As influential as we have
been in promoting FIX, within the FPL it is members that have the
strongest voices.

* PURE JAVA PORT *

Some of you may have seen postings from Steve Bate about a pure Java
port of QuickFIX he started.  Steve sent us the work he has done so
far, and it looks very promising.  Steve and I talked a few days ago
and we decided that we would put his work into our CVS repository. 
Yes, it's real, and this will possibly become an official java version
of the QuickFIX engine.  Steve's current design goal is to emulate the
current engine as closely as possible.  This means remaining compatible
with the configuration files, data dictionaries, message stores, and
current java API.  Basically, you should be able to swap out the JNI
version of QuickFIX with this port.  After this design goal is reached,
we may look into how we can take fuller advantage of the Java platform
once the library is no longer being held back by its C++ core.

* SIMC CONFERENCE *

Are you a major firm with an interesting story regarding the adoption of
QuickFIX?  If so, please get in touch with us.  Last year the SIMC held
a conference on open source software in the securities industry.  At
that conference, Reuters shared their experience in adopting QuickFIX. 
They have invited us back to get an update on our current status and
want to hear other adoption stories.  This is a well attended event
that primarily consists of executive level IT professionals.  You could
participate either in person at the New York location, or you can attend
remotely via telephone.  Please email us at as...@qu... if
you are interested.

* SOUTH AMERICA *

What is this about?  Well, that's where I'm going to be for the next 10
days.  I'll largely be unreachable, so instead of sending me emails
directly, send them to as...@qu..., and someone will get
back to you.

* FIN *

Thanks for the enormous contributions we have received from so many
people.  We will continue to explore ways in which the community can
stay informed, and contribute to our progress.