TickZOOM Decision. Open Source and FREE!

Status
Not open for further replies.
I wish you the maximum success for this project, but therefore it has to be open.
More...

We define success differently.

Here's how I define success.

I have a trading system that I use myself and am completely fine doing so.

I'm willing to share it with some other people and will be happy to support them and make fixes, enhancements myself.

IF they wish to make a fix or enhancement because they can't wait on me then fine. And IF they want to contribute their change so I can regression test and roll it in to the next version, then fine.

If NOBODY wants to do that. Then fine.

At least there sounds like one person interested.

I got another who contacted me through a google search who still wants it.

That makes 2. It doesn't concern me if open/free source religious zealots aren't interested.

Why? It's because there's already tons of open source available for us to add into TickZOOM from projects who encourage commercial use of their software.

A big one is TREE. They use a BSD license because they explicitly want other commercial projects to work on and improve it.

QuantLib is another big one that has a BSD style license so it can be used on TickZOOM.

We can also use QuickFIX for the FIX interface since it has a license that encourages open source.

There's plenty of math libraries out there too.

We can use LGPL by linking to it with TickZOOM. (And it already does for the basis of drawing charts.)

We can use GPL code also by creating a plug in or add on.

So all that's needed is the "engine" to glue all this stuff together. And that's TickZOOM.

I'm going to release the API of the trading models to public domain so anyone can use it, make derivative works, etc. But not the engine itself.

So you see? There isn't this big need for a ton of developers.

TickZOOM in just a few more months of work will knock the socks off any trading system out there.

If someone else wants to help, fine. If not, fine.

Point is. NOONE will be able to contribute as much code and work as I already have. So I'm not impressed with all the talk of major contributions.

Any more suggestions to integrate?

Sincerely,
Wayne
 
By the way, people keep comparing to Linux. What was Linux when it started? Just a partial kernel. Useless by itself. It required tons of development work by many people to build it to the point of being of any use at all.

TickZOOM already is a completely working system being used to trade live right now.

It already makes writing strategies far easier than anything out there.

It already processes ticks several order of magnitude faster than anything out there.

It already handles any combination of bar intervals.

So the comparison is flat.

All it needs are some more broker interfaces and some other nice add on features.

It already has time and bar based charts and most useful plotting styles.

It already supports any combination of time frame.

I'm still not impressed by all the claims of major contribution.

Maybe someone will have to give me some examples.

"Sell" me on these contributions. I can't visualize or conceive of what they might be other than fixes and minor enhancements.

If you're talking about adding on some calculations or more indicators. Those can all be open source. I don't care.

It's only the engine that I'm concerned about.

Sincerely,
Wayne
 
One more thing. I think what has changed my point of view was that last couple weeks of refactoring and thoroughly testing this system.

Before then I didn't feel so hot about it. But now it's very clean and ready to go except for documentation.

That has me more convinced that this is already a solid system that doesn't need the "crutch" of open source contributions to be useful.

Many can use it right now and many more as we add more broker interfaces.

Sincerely,
Wayne
 
I think this project goes in the right direction:

- With an open source code or whatever you want to call it, with the ability for users to contribute, but with a commercial backend.

This will ensure stable evolution, preserve users innovations, while keeping us from anarchy.
 
Hopefully my post didn't come off as me being against you commercializing this. You obviously put a lot of work into it, and there is no reason you should be excluded from making some money from this. That was not the point of my post.

The point was, we need to be able to create derivative works. That is the only way those of us who contribute can guarantee that the project can survive...

We do not need to be able to create "commercial" derivatives however. But we do need to be able to continue to create "free" derivatives..

An example of an "open source" project that became commercialized that would have had problems is Nessus. Those of you familiar with Nessus, it used to be completly open source. Then when version 3.0 came out they commercialized it. The code was locked out, the community was no longer freely able to contribute code enhancements... However, the license for version 2.0 allowed derivative work because it was not yet commercialized and because of that a fork happened and they created OpenVas which is just a continuation of open source Nessus.

OpenVas is not affecting Nessus 3.0 in anyway, its not direct competition.. They are making some serious money from it... but OpenVas provides a way fro the project to survive as open source...

That is all we are asking. We "need" a way so that if you close the source one day for whatever reason, or start to restrict who can contribute etc... that there is a way to spin off in a NON commercial way. I don't see that as affecting your plans to commercialize any. By commercializing you would be able to provide things the open source community can not provide on its own.. namely support. Therefore any non commercial derivative work the community may create will not hinder your efforts.

That is my take on it. In the end its your decision.

EDIT: You may believe that you will never lock the source or start preventing people from freely contributing, but its hard for you to know what will happen when you commercialize. At that point it may be beneficial for you to lock the community out and hire your own developers... there are lots of reasons you may chose to do so. Nessus did it, and i'm sure that was not the original intention.
 
Quote from frostengine:
EDIT: You may believe that you will never lock the source or start preventing people from freely contributing, but its hard for you to know what will happen when you commercialize. At that point it may be beneficial for you to lock the community out and hire your own developers... there are lots of reasons you may chose to do so. Nessus did it, and i'm sure that was not the original intention. [/B]
More...

You concerns are valid.

How about we add a clause in the license that states:

"In the event any future version of the program becomes closed source then you are automatically granted a license under the latest version of the GNU General Public License."

We could define closed source to be more clear:

"Closed source means that the copyright holder fails to release the entire source code to users for any new version of the software."

This recognizes the possibility you raise and allows you to fork exactly like the scenario you describe.

NOTE: I agree with all this because I AM committed to keeping source available to users so this scenario will never happen.

If this seems agreeable, I'll get it legally reviewed.

Sincerely,
Wayne
 
Quote from Koros:

I think this project goes in the right direction:

- With an open source code or whatever you want to call it, with the ability for users to contribute, but with a commercial backend.

This will ensure stable evolution, preserve users innovations, while keeping us from anarchy.
More...

Thanks for the vote of confidence.

Still I want to work out something with the others to hopefully appease their fears. But if not, okay.

Wayne
 
Wayne,

That could work... however the one instance it does not address is if you begin to take the project in a fundamentally different direction than a group of people may want... for instance you may decide that you do not want feature XYZ in there, and lets assume its a feature that is mutually exclusive with a feature already present or planned. But perhaps a very small group of traders want this feature for whatever reason as its necessary to their success... In we were allowed to create derivative works then we could create a new branch that went this way while the main branch still went the way you drive it. That is the only fear I would still have. Gives contributers a sense of safety that if they contribute a lot of time and effort to this, and then find they need to go in a very different direction, for a feature that you do not want to go in, then they can branch off and all there work wasn't for naught...

So I would propose some clause allowing for NON commercial derivative works.

However, it is your project and I appreciate that you are willing to guarantee that if it went closed source we would be free to branch. This will probably be enough to get me to contribute. A clause allowing for NON commercial derivatives would be the icing on the cake to alleviate all the fears with your current license.

Looking forward to TickZoom's impending release.
 
I don't have a problem with that. If i understand this correctly, should TZ really go closed source, i could still continue using and/or developing the last free version for personal use (or decide to become a customer if it seems favorable). I guess most code contributors will still come out ahead, because chances are they will have received alot more than they have given. Although I understand if some people take a different view on that (from an IP standpoint).
 
Quote from frostengine:

Wayne,

That could work... however the one instance it does not address is if you begin to take the project in a fundamentally different direction than a group of people may want... for instance you may decide that you do not want feature XYZ in there, and lets assume its a feature that is mutually exclusive with a feature already present or planned. But perhaps a very small group of traders want this feature for whatever reason as its necessary to their success... In we were allowed to create derivative works then we could create a new branch that went this way while the main branch still went the way you drive it. That is the only fear I would still have. Gives contributers a sense of safety that if they contribute a lot of time and effort to this, and then find they need to go in a very different direction, for a feature that you do not want to go in, then they can branch off and all there work wasn't for naught...

So I would propose some clause allowing for NON commercial derivative works.

However, it is your project and I appreciate that you are willing to guarantee that if it went closed source we would be free to branch. This will probably be enough to get me to contribute. A clause allowing for NON commercial derivatives would be the icing on the cake to alleviate all the fears with your current license.

Looking forward to TickZoom's impending release.
More...

Frostengine, the scenario you describe would already be protected under copyright law and the license.

That is, in your scenario, you are all users who have a legitimate copyright.

So you can always band together to share ideas and code.

Where you would get into trouble is if you tried to distribute the version to other other people without a valid license.

Remember users have an unlimited right to modify the source code for private use. Just not to distribute outside the user community.

Wayne
 
Status
Not open for further replies.
Back
Top