By the way, after getting through the first hurdle of settting this up and releasing the code, I plan to implement continuous integration so we get notified if a build fails or Unit tests don't pass, etc. At least, I hope there's a way to do that with C#. I know how to do it in Java. Wayne
very interesting.. need a site dedicated to this.. dont want to lose track of this project keep it going!!
Wayne, you're going to have a tough time getting good people to expend their time and effort towards the project if you force them to surrender their ownership of their contributions to the project. The worst thing that can happen is that they could fork your project so that they retain ownership of their modifications. That would completely lock you out from being able to incorporate their changes into something you wish to release commercially.
GreaterReturn: how does TickZoom handle those large amounts of data during simulation/optimization? One limitation i faced with Neoticker was, that all of the data had to be loaded in memory to perform tick-replays - which is not possible for a long tick-history on multiple instruments.
GR, 1. The performance numbers you posted are impressive. It's faster than what I have. 2. Stick with your original plan. And keep all the ownership. Look at this thread with all the people trying to have a say in YOUR project. You should now realize that there is a high demand for this type of stuff. Everyone needs a fast testing engine. If people want to use it, they contribute or pay. Don't worry about finding people. If your core engine is good, you'll find plenty of people wanting to use and join the bandwagon.
You're right, there is a lot of interest for good tools and it sounds like Wayne's got a good core from what he's described so far. And, I'd definately like to sink my teeth into a project that isn't going to have the rug pulled out from under us later on, which often happens in this industry. IMHO, there's no way someone's going to contribute an equally good component, say a genetic optimizer, neural net or similar item if they have to forfeit ownership of their work.
Pippi, 2 things. One, I highly optimized the amount of memory needed for ticks so you can fit more in memory at the same time. Second, I planned for this requirement from the beginning so it will be simple to add rolling of the ticks from disk through memory as a test progresses. In other words, it's already implemented with the infrastructure for this. I just never used or tested it since I never bothered using that much data yet. However, if we can bump up the priority on that. I'm pretty sure the software I'm setting up has the ability to vote on features. I'll tend to work on the highest ones first unless there's something I personally need. Sincerely, Wayne
Great idea. Additional modules needed: - an Open real time tick server. There used to be OpenTick but it closed down. Data vendors unjustifiably raise prices for tick data, while prices for hardware and bandwidth fall all the time, even in relation to exchange volumes. This can be cooperative effort - if 1000 people subscribe and pay $10/month, that would be enough to rent servers, pay to the exchanges and hire one or two Ukrainian programmers to do the work. - an Open Broker. Wouldn't it be nice to pay commisssions on bare cost basis? - an Open Exchange. Well, that's the direction.
jprad, Thanks for bringing this up. That's why I wanted to discuss the licenses. I understand completely how you feel. That's because I felt the exact same way. But I found a lot of industry research on successful open source projects (have you?) that completely changed my point of view. Here's the several reasons that concept we both had is flawed: 1. You are completely right about the "rug" issue. The industry has clearly demonstrated that projects must commit to NEVER pull the rug out. Specifically, it will be legally committed in writing on the tickzoom.org website that the source code will always remain open and free to those who contributed to it and others who join later to contribute. That's a CRITICAL element. You should print it out to keep a copy so you can enforce if necessary and I will do the same because that might not be me. For example Sun bought MySQL and Versant just bought db40. So we have to think towards the future. Software seems to last a long time (when it's good.) In other words, when committers give up copyrights the TickZOOM project gives in return the legal guarantee and commitment that the code remains open and free to them. 2. Did you know? MySQL followed the model of committers surrendering rights, Eclipse and all the others like db40 do the exact same thing. That's the only way they can legally do dual license. This isn't something I came up with. 3. What about forking? When MySQL switched to a dual license a company formed to fork the MySQL project in response. However, that project and the company eventually failed. Why? It's because they could only legally fork the GPL version. So they had no possibility of selling any commerical license. They went bankrupt. Meanwhile MySQL was busy hiring full time programmers and making MySQL a killer great database. They actually closed the functional gap with commercial databases. That's all because MySQL had the legal option of dual license which the fork could not legally do. 3. Another mistake we made is that many programmers like me would be HAPPY, no make that THRILLED if NinjaTrader or NeoTicker would accept some enhancements into their product that we make for them divulging their source code. And we would be happy to surrender the rights just to avoid building our own system from scratch. This is too much work, frankly. I wish I had all my evenings and weekends back. 4. Now in #3 above a person might naively assume that developers with open source might just keep their fixes and not submit them. But nobody with any sense would ever do that. Do you know why? It's because when the next version comes out they would have to keep separate patches and merges the code every time. I tried that before and it's a huge pain and very risky. Any experience programmer will share you the woes of merging code branches. Plus it could even be risky. That person now has code mods that aren't getting tested by the entire community. 5. Finally, did you read this whole thread? Several people have suggested recommended the possibility of an open source version and a commercial flavor for paying customers. So, many are familiar with that business model and have seen it succeed to the benefit of the whole community. Eclipse, MySQL, db40 was discussed. That's exactly how all those projects work. Maybe you and others weren't aware. I certainly wasn't until yesterday that the fine print on all those dual license projects surrenders your copyright. But it has to work that work they for everyone's benefit. The difference here is I'm telling up front instead of burying that in fine print. Personally, I have faith in people that they, especially programmers (am I biased? *smile) ,are smart enough to educate themselves and see that this is a win/win scenario. What is really bad is when companies form dual code bases. [Unless paying customers want features the OS community rejects--that's different.] That's because the companies have a moral responsibility to contribute back to the open source version. More about forking: Realize also, that the GPLv3 license requires that IF anyone does fork the project, which they are legally allowed to do, then that are ALSO legally required to release all improvements as open source and freely available which means the TickZOOM project can review all the improvements (simply by doing a diff) and add those back into the main code if useful. So people who fork only shoot themselves in the foot in every way unless there's a valid reason that the whole community agrees with them and abandons the original project. So you see, a fork doesn't really hurt anybody or help anybody if the original project is acting responsibly. NOTE: TickZOOM will, of course, allow for "plugins" and add-ons, those don't have to be committed to the TickZOOM project. In fact, they might clutter the project. Instead we could have a separate totally GPLv3 site for such plugins and addons if people care about this issue that much. I'd be willing to sponsor it and submit stuff there also. Still others may make commercial addon's. There's many commercial indicators that get ported to different trading platforms. That's all fine without hurting anyone. You must not forge, I beg you, the blood sweat and tears that I put into this platform and will continue to do so to document and support it-- all with out pay--out of generosity to the community and hope of a collective benefit to everyone including myself. I deeply believe in synergy or the whole is equal to more than the sum of the parts. So I won't hesitate to take whatever legal means necessary to protect the project as it goes forward. And GPLv3 has some pretty serious teeth for those who don't follow it. In the end, I believe well informed programmers will see that commercial and open source is a symbiotic relationship that benefits everyone. Sincerely, Wayne
Great, I hope you can come to terms with the community needs as far as O.S./ commercial licenses. Correct. And I'm happy with the other suggestion to make it optional to have any storage you like. In fact, someone can add the ability to load bars too. The architecture supports bars except, obviously time frames smaller than the bar period won't function. Yes. Sorry, I'm somewhat of a perfectionist when it comes to software development. I require a truly professional development environment. Source forge just seems cheesy to me. This project will have it's on website wiki at tickzoom.org. It will have some graphic design. It will have code examples with Chart images,etc. TickZOOM will have a logo. Probably temporary one in the beginning. Later we can have a competition or vote on logos or something. I hope it will be a very cool site. In fact, as a wiki, I hope others contribute to make it even more cool. Sincerely, Wayne