FIX, FIX Engines and RHCP

What's this about? Surely a typo - should be DHCP and assorted networking geekery?
No, this is about RHCP.  Specifically (yes, slightly tenuous link but we do our best to brighten up your day) "Give it away"...

At a recent conference I found myself engaged in a conversation with a CTO of a hedge fund. They are doing some interesting things in the connectivity space and we got to the topic of the FIX engine they use. They started off with a well known open source FIX engine but realised that they did not want to contribute back to the open-source repository as they believed that they had "secret-sauce". Fast forward a short number of months and they have such a bastardised version of the open-source it's a case of "Trigger's Broom"
Now they are looking to remove some of this complexity by implementing a commercial, closed-source engine.  While talking, I asked them "why pick an open-source FIX engine?" . The answer was simply that it's free. Understandable, but perhaps the closed-source community is missing a trick...

"Give it away" - why not allow anyone who provides a commercial email address (not, and so on) to download a fully functional commercial quality package of your software? Time limit the license to say one month at a time and feature limit to say five connections. So allow a prospective client to use the tooling, get a feel for strengths and weaknesses and not get stuck on a road where the cost of change is high as and when there's a move to closed source?

The world of FIX engines is small and has been covered many times before on this blog. The main current participants such as (alphabetical order)
FIX Flyer
Rapid Addition

could all implement this with some website magic or even a mechanical turk. No damage to current revenue stream but potential for upside in future. Retain relevance in an increasingly commoditised market, get some clients who transition from open-source.

Why wouldn't you?


  1. I've got a different idea. Why not fix FIX so you don't need a FIX Engine at all? Adoption of, say, gRPC instead of the FIX session layer would remove the need for costly (in terms of money and latency) FIX engines. Simpler, faster, cheaper - what's not to like?

  2. So you suggest using protobuf as the message ser/des layer over gRPC. Ok, that's a maybe. But what's the cost benefit for this?

    My answer to the problems of FIX is to abstract it away using FIX Orchestra.

    How do you propose to take your idea to implementation? Would be interested to discuss with you. Since I don't know who you are, please feel free to get in touch with reference to this and I'll buy you a coffee.


Post a Comment