Installshield 6 (inter-proc) patches

[Gavriel State]

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

-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav at transgaming.com