How about new, minimalistic trading platform... Open source of course

Discussion in 'Automated Trading' started by Chronos.Phenomena, Mar 16, 2011.

  1. For number of years I was financing development of IB based trading platform. Various programmers contributed from all over the world... and it worked fine.... BUT... If you ask me if I would do that again, the answer is NO for various reasons but main one being... limited user/tester base and expensive development...

    Now, I would go with open source platform and pay only one guy to manage/promote and work full time on it. Obvious problem with that is to start from scratch! It hurts!

    I decided to take that pain and draft bare bones platform and open it in couple of weeks.

    The platform will be:

    1. Java based
    2. Console only
    3. Simple and minimalistic and FAST
    4. Oriented toward 100% automatic traders
    5. IB to start with... But having on mind multi-broker support
    6. no backtesting! Only live testing

    Is there someone in the same/similar boat willing to collaborate? Or make a case against such project?


    .... Anyone?
     
  2. I think it's a good idea. If you manage to make it usable enough so that people will rather start using it with their projects instead of writing their own, then the user base will grow. They will start contributing their improvements to the code, so the project will grow.
    A few words of advice: make sure that the code is simple, clear and generic (as much as possible). In many cases the first impression makes or breaks it.
    Also, look at what's already there. There are a few open source projects but none of them seems to be good enough so that the decision to use it instead of own code is a no-brainer (only my opinion).
     
  3. Why do you want to start from scratch? Why not build on existing open source software that works?

    There are already two open source Java automated trading platforms for IB:
    JSystemTrader http://code.google.com/p/jsystemtrader/ and JBookTrader http://code.google.com/p/jbooktrader/ .

    Both have backtesting already built in.

    Note that JSystemTrader seems to have disappeared from Goggle Code, but it can be brought back.
     
  4. I am not sure about the size of the market for that given NT, TS, MT and myriads of others.

    However, my problem is that I sense - and this is true for me also - that more and more people with serious accounts are getting into longer-term trading for known reasons and the faster time frames are populated with small accounts (< 1K) as brokerage statistics show and HFT of course to milk them. Those customers do not last long and cannot afford a platform. In my case, if I move fully to longer-term trading I will need some EOD data and a cheap charting/backtesting program with exploration capabilities. Depending on my systems, I may not even need that, Yahoo! finance may be enough to get my signals.

    My 1/2 cent
     
  5. While ago I tried both... They are nice, but inherently GUI applications. System trader was more for TA traders and book trader is looking at book data ONLY...

    In my opinion both are over complex and too much effort went into GUI, optimisations and back-testing... That makes code to be bigger and harder to maintain... And again "I don't want that". I build my models using R or matlab.

    What I want is very simple fast and by all means minimal framework to RUN my algos.

    I searched web inside out to find such project ... But no good!


     
  6. JBookTrader consists of about 120 Java classes. I consider it a small codebase. In terms of speed, the optimization is about 30 million ticks per second on my quad-core machine. Backtesting is very fast, too. If you don't need the backtesting and optimization capabilities, then what needs to be "fast"? In live trading, very little of CPU is used by JBookTrader.

    The other comment that I have is that you mentioned that the platform will be Java based, and the algos would be R and Matlab based. That seems to contradict your apparent goal of making your system "simple and minimalistic".
     
  7. Well said... but... I need

    1. Fast order book + other data structures
    2. Ability to monitor/trade many instruments on tick by tick resolution
    3. Limit orders (can be complicated implementation... given intrinsic asynchronous nature of the problem)
    4. Risk management layer

    The suite of models is developed in R/Matlab it only needs to be deployed/ran in Java... so no r/matlab stuff calling from Java.

    What I want to achieve is something like GUI free cyborg trader... but open and simpler ;)

     
  8. I have had only minor dealings with the open-source community, but I think that there are several factors I see which separate successful (actually made something useful) from unsuccessful (little return on investment) open source projects.

    1. Business Plan. An open source project needs a business plan just like anything else into which one wants to put time and money. Not wanting to pay programmers is not a business plan. Saying that you are going to build a rudimentary e-commerce engine, and the contributors will be consultants who make their money making websites by customizing the engine. The product would then grow by these consultants checking-in the things that their customers are paying for.

    2. Target Functionality. Everyone trades differently. Even clients whose requirements are nearly identical at the outset become rapidly incompatible. Software can either be very expensive or very inexpensive depending upon whether there is a common problem which can be simultaneously solved. The Financial Software arena is thick with products. Why will people really want your version?

    3. All encompassing. By wanting a complete package rather than a few reusable pieces, you are limited your developer appeal to those that want very much the same package. Simultaneously your massively increase the effort and the coordination. For example, could you get want you need by having an R/Matlab connector for TradeLink/OpenQuant? Many developers would want to include that in their diverse project, and efforts to enhance the R interface can be only loosely tied to efforts to enhance Matlab interface. It could for the nucleus of a group.

    4. Fragmentation. On SourceForge.net alone, there are 690 projects based on the keyword "Trading". Of these only 16 have had 100 downloads in the last week. Of those half, have nothing to do with the Financial Markets. That means that only 2% of the open source project has user interest at that threshold. As far as developer interest:
    Code:
        Dev Status
        * Inactive          12 = abandoned
        * Mature             7 = successful
        * Production/Stable 66 = active
        * Beta              89 = trying
        * Alpha             75 = nothing
        * Pre-Alpha        119 = really nothing
        * Planning         167 = no one cared
    
    5. Culture. Look at the way TradeLink is. It has a bunch of modules closely based off of broker APIs. This is the core value proposition. How much work? There there is TA-Lib, which is an adopted open-source project which slimmed-down. Most open-source things that I have seen with some pull have been extensions/splinters of some successful open-source project. The programmers need to be motivated. Usually because, they think the technology and idea are intrinsically really cool. Not because some users want it for free.

    If you really want to start-over, you could look for someone else's commercial venture. Buy the defunct assets, turn it open-source, and at least there would be a core competence upon which to grow an online community.

    Best of Luck.
     
  9. Chronos,

    I think you're right about eliminating backtesting. Traders put to much emphasis on backtesting. Forward testing is the only way to test.

    As such, emphasis needs to be place on building systems that allow you to design and execute sophisticated meta strategies.

    Runningbear
     
  10. Yeah...


    Backtesting/data recording/playback/optimization/GUI can easily be between 50% of the code base...

    I want to get rid of that and focus on what's important

    speed and robustness



     
    #10     Mar 17, 2011