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.
Yes, but that is because it hasn't been needed for anything but obscure application until now.
It's not at all clear that our work there has discouraged anyone else from working in that area.
Granted.
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.
That is absolutly true and would make any decision not to release it under a free license even more strange. Note however that I'm not accusing you of not releasing it. Not yet, but I reserve the right to do so in the future. Anyway, see below.
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.
I think that you look a things the wrong way. Think of the expense as an extra cost you pay for being early to the market. Sure it won't make your accountant much happier but thats life. :-)
What I mean by that is that the DCOM code aiming to get InstallShield to work is not really something that has very much to do with the product you that your customers want to buy.
Installation is done only once and can be made in the real Windows if you dual boat and beside it is really something that Wine should have supported already.
In short, it was something you had to do because Wine was not mature, because you wanted to be early to market and holding it as proprietary code are unlikely to give you any advantage for very long. If you won't release it somebody else will implement it before long.
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.
Yes, I fully understand that, I'm grateful for all you have done and I'm not making any accusations right now.
However I reserve the right to do so in the future.
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.
I don't think Alexandre is questioning your ethics. I think he is question what relation the Wine project should have with you based on praticial issues and not on ethical issues at all.
In short: Should the Wine project wait until you release or should it not?
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.
:-)
I fully understand that you wish to take every opportunity to get some extra income but I think your analysis is partly wrong.
Sure it is possible you might get some sort of one time payment from somebody if you are a little clever, but realize the following.
A significant part of your potential customers consists of, I guess, people who would very much like to not to dual boot any longer and their first priority is that their normal productivity applications installs and works. Games are their second priority and so as long InstallShield doesn't work in normal Wine you risk losing them since they will continue to dual boot and presumably continue to play their games in Windows.
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.
For any discussion concerning milking some money out of CodeWeavers or their clients, absolutely. Not my problem. :-)
However one important problem that really can't be discussed off-line, is what your relation you wish to have to the Wine project. In fact, it can't be discussed at all, only your actions can determine it.
I will be blunt: Do you see yourselves as a complement to Wine or a competitor to Wine?
Because not releasing important core code like code needed to install important applications especially non-games might be interpreted as really wish to compete with Wine instead of being a completement.
Note again (the third(?) time) that I'm not accusing you of anything, at least not yet, but I wish to point out that it might hurt your public image if people see as a competitor instead of a complement to Wine.
Being vague and saying: "There are several factors to that equation, and I'm afraid we don't have a firm ETA yet." will not help your image.