The sad state of opensource ATS solutions

Discussion in 'Automated Trading' started by Butterfly, Oct 28, 2013.

  1. Butterfly

    Butterfly

    between poor documentation by developers and the proprietary non-sense of brokers API, I find it difficult to put together a robust ATS solution that can be easily understood by everyone.

    IB APIs are a complete mess, despite good documentation, they are "closed" and need constant updating.

    Marketetc is a complete joke. Built on a cascade of Java framework, it was probably designed for clueless Indians coders. The architect behind METC should be shot for putting all "fashionable" Java framework into METC so it could be more "marketable" to the Java developer community. Completely useless in practical terms.

    Python API for IB are in a poor state of documentation despite good programming effort by the developers. What a waste.

    Matlab API IB seems very promising, very well documented by some professor, but who really use Matlab for ATS on a headless server ?

    not many solutions out there it seems,
     
  2. Very true.

    Also QuickFIX, the documentation and support forum is non-existent, huge and buggy code base requires a full time job to install, use, and maintain it.
     

  3. not surprising at all. this is because a lot of these tools are made by people who have little or no trading or algorithmic business experience. while they may be great coders they just don't understand the needs and come of with poor or confusing implementation. and the best guys are employed at hedge funds but even some of those need business managers to guide them.

    IB api isn't the best, but given their cheap commission they draw lot of interest and if you get used to using it, it works. I think they have some very old and shitty java developers there who somehow kept their jobs - this is why on the tech side it hasn't improved much. also it regularly gets disconnected. I think they put much of their effort on the data farms, execution and tws - don't think the api is a major concern to them. if it was you'd have a industry leading line of APIs one for each programming language. but what you have is a old c++ doc, a java garbage and if u use anything else then figure it out yourself!
     
  4. murrica

    murrica

    TD Ameritrade's API looks fairly nice IMO. http based, for both request/response and streaming. Hoping they add futures, though. Haven't used it yet, but read through sample code and the documentation and it is very straightforward.

    When time allows, hoping to cut my teeth with it and Erlang, which would be a funny mix indeed, Erlang client against TD Ameritrade API :) Go go gadget gen server!
     
  5. I feel your pain.

    Having worked in the software engineering industry for years I was absolutely appalled when I first looked into retail trading software back in 2008. Compared to every other sector I'd worked in the software offerings were almost entirely hopeless.

    For connectivity I currently use with the Rithmic API which, whilst confusing and illogical in many places, does actually get the job done once properly implemented. Everything else I ended up building from scratch.
     
  6. Occam

    Occam

    I've never seen a bug in QuickFIX, despite having used it quite extensively, and in my experience it's far from a "full time job" to operate it. In fact, its robust features (e.g., re-sending any messages that took place during a disconnect) make it far easier for me to run than "simpler" API's that lack such features.

    That said (and this isn't directed specifically to you), I can see that using a source-level FIX solution would be challenging unless one is at least somewhat acquainted with multi-threaded programming on whatever platform it is you're using. But multi-threading is a hard issue to avoid in automated trading. If an ATS (or whatever platform it uses) is not dealing with multithreading at some level, the issues are still there, and possibly even the source of a potential blowup.
     
    cjbuckley4 likes this.
  7. Butterfly

    Butterfly

    one of the biggest confusion of all those systems is to confuse trading execution with trading logic

    for some reasons, developers are building platforms for trading logic with interfaces to trading executions, a big mistake

    why can't they focus on developing a nice API system to place orders and separate the code for trading logic

    since they are developers, they confuse the two and think there is no trading execution without trading logic.
     
  8. 2rosy

    2rosy

    the python api is just the java api run through a convertor
     
  9. No one in their right mind is going to build a proper OMS/EMS and release it open source.

    It sounds like you're using IB, given what's offered (IB Java API/FIX) you should be able to piece something together yourself.
     
  10. Butterfly

    Butterfly

    indeed, and since IB API in Java is "poorly" implemented, the Python implementation seems to be a copy/paste of that poor implementation
     
    #10     Oct 29, 2013