New subject: Installshield 6 (inter-proc) patches

12 Dec 2001


      ...
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.

RE: Installshield 6 (inter-proc) patches