Installshield 6 (inter-proc) patches

[Patrik Stridvall]

> Alexandre Julliard wrote:
> >
> > Gavriel State <gav at 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.