Alexandre Julliard wrote:
Gavriel State gav@transgaming.com writes:
There are several factors to that equation, and I'm afraid we don't have a firm ETA yet.
Well, this worries me. It sounds like you are planning to do the same thing you did with your DirectX stuff: by making the code available on your site, and promising to release it at some hypothetical future date, you remove all incentive for other people to spend time improving the main Wine, thus ensuring that it always lacks some features. I don't like this at all.
If you can't/don't want to release your code, I'd strongly suggest that you reconsider your strategy of making it publicly available. If it was only available to paying customers, there would at least be a reason for other people to work on a free implementation. But if everybody who needs some feature in Wine can simply download WineX instead, no one will spend time re-implementing that feature. This is beginning to seriously hurt the project, and we need to find a way to address this issue.
The DCOM issues had been ignored by other Wine developers for YEARS before we came along. It's not at all clear that our work there has discouraged anyone else from working in that area. To say that our work is preventing anyone from doing a free version of DCOM is completely incorrect. To the contrary: we have already contributed substantial amounts of this code to the public tree - thousands of lines, in fact. That can only help anyone with a sudden and unexpected interest in recreating our work.
Now, it is our firm desire to see *all* of that code end up in the main version of Wine. The fact is, unfortunately, that we simply cannot afford to give everything away as soon as we write it. We only got a minimal implementation of the DCOM code working six weeks ago. We are not a rich company, with millions in VC funding to burn; this means that our DCOM work has to remain under the AFPL until we can find a sponsor willing to defray some of the tens of thousands of dollars it cost us to develop it.
Furthermore, we are committed to writing quality, robust code. We don't think it's in anyone's best interest for the current version of the code, which is effectively limited to the requirements of InstallShield, to be used as the basis of future DCOM related work. We in the midsts of working on a much more flexible architecture which will permit more than just typelib based proxying.
I don't really think this affects individual users at all. They can simply download and use the code from our website, or apply the necessary patch to WineHQ wine. They can even redistribute it all non-commercially should they wish.
Without a doubt, we are committed to the Wine project and have already contributed a great deal of code to support it. However, to maintain the quality and integrity of the project, we stand by our decision of only contributing code when it makes sense to do so (in order to allow us to continue developing quality code) and when it reaches a certain minimal degree of quality.
Publicly questioning our ethics is certainly not the right solution nor is it in the spirit of the project, especially given how much we have supported it to-date. We believe that we ARE doing the Wine user and developer community a service and propelling it further. The only people that our lack of haste in contributing code back really affects are organizations that want to make immediate commercial use of the code. These organizations include the one you work for, and its clients. If you want to see the DCOM code Wine-licensed soon, you need to talk to your boss and your clients, not me.
At this point, I think it would be best if we were to take this discussion off-line so that we can determine a solution that works for everyone.
Take care, -Gav