Is Wine a platform for Codeweaver to make money?! Please help me understand.

Tony Lambregts tony.lambregts at gmail.com
Sun Apr 8 01:51:39 CDT 2007


Kai Blin wrote:
> On Saturday 07 April 2007 23:52, Tony Lambregts wrote:
>> Scott Ritchie wrote:
>>> Yes.  Wine's development speed has roughly correlated with its user
>>> base; popularity brings more bug reports, volunteers, and funding for
>>> paid work.
> 
> [...]
> 
>> I whole heartedly agree. If it were not for "dirty little hacks" Crossover
>> Linux would not run some of the very programs that make it so popular.
>> Popularity with users is the driving force for developers. Developers go
>> where the users are and I know there are enough bug reports in bugzilla to
>> keep all the developers we can handle busy. I am not saying that we should
>> put in just any old hack but there are cases where we really miss the boat
>> because we want to get things "right".
> 
> What boat? I'm not selling a product. I don't need to meet any deadline. 
> Unless Google pays me,

We (The Wine project) produce a product and we have a deadline even if you do
not acknowledge it. It occurs every time we cannot run a program when a
potential user really needs it.

> I do my Wine development in my spare time. 

So do I, In fact so do a lot of people. Welcome to the club.

> I've spent 
> my last two years working on a feature that about a handful apps out there 
> will use. There is one bug report in bugzilla for my stuff, and that's 
> actually invalid. If I spent my time waiting for users to get interested in 
> this area, Wine still wouldn't do NTLM.

Your right about NTLM not being used much and that is part of the reason for not
having many bug report against it, Another part of it is that if a program uses
NTLM but it does not install or crashes before requiring any authentication you
will not see a bug report until the previous bug is fixed (or worked around).

I'm really curious as to what DOES motivate you to work on NTLM if you don't
care about users using it.

Regardless of the previous statements there are plenty of other bug reports out
there that you could work on if that do not involve NTLM. Please don't
misunderstand me I'm not saying you that you should. What you do with your free
time is up to you. The point I was making is that there are lots of unresolved
bug reports to keep developers busy on if they are looking for something to do.

> 
> [Some talk about a msvcrt bug]
> 
>> Yes, we would not get that particular bug report but we may have lost many
>> more users because of the same problem. If we want to have the best of both
>> worlds we could have a message box pop up saying that wine found a program
>> supplied DLL and if you use it, you could be covering up a bug in our
>> implementation of that DLL and let the user decide. Some users will try out
>> our built in and make a bug report and that bug report will be easier to
>> deal with that trying to track down which DLL overrides might work.
> 
> Most users will figure out that clicking "use the override" will make less 
> problems than the other button. I'm not sure that'll lead to easier bug 
> reports.
> 
It will be easier because the user can identify what dll he had to put to native
because we tell him. That assumes that he wants to help the wine project, as
opposed to just getting the program to run.

The way it is right now the program may fail, and if the user is like most
users, that would be the end of it. No debugging, just Wine failed to run the
program and a bad user experience.

Now it is possible that this user really wants to get this program to run and he
goes onto the wine users list and asks for some help. So hopefully someone tells
him to try dll overrides and it works and that's great but it does not guarantee
he will make a bug report.

In fact this can lead to the situation where the user gets into the habit of
always copying in as many native DLLs as he can and always overriding to native
which is why we hate WineTools.

The way I see it we really nothing to loose on this.

--

Tony Lambregts



More information about the wine-devel mailing list