Re: WineX and the AFPL

On Wed, 5 Jun 2002, Francois Gouget wrote:

> Any developper that stops working on a domain in disgust or because he
> feels his work is useless since it will soon be obsoleted will not
> compensate by working on another area. Thus it is a total loss for the
> project.

True, if the demotivation effect slows their overall efforts, that's a 
loss.  However, it's probably a temporary loss, not a permanent one.

> If you think other areas are more important then I would encourage you
> to advocate them on wine-devel. Explain why they are important, what
> Wine has to gain from them, and generally try to convince others (while
> staying within reasonable limits of course). When you do this, then you
> will either convince developpers to switch to work on this area, or wou
> will convince new volunteers to start working on Wine which is even
> better.

Yeah, or it could just as easily annoy developers to hear non-contributors 
"directing" them in what areas they should work on.  No thanks.  I may not 
agree with their choice of direction, but if I'm not going to contribute to 
the project, I'd rather stay out of the peanut gallery.

Okay, I'm in the peanut gallery in THIS list, but it's segregated from the 
developer's list where the real work is done.  If the developers choose to 
hang out here, they know to expect comments from the peanut gallery...

> And yet, Windows was available, Wine did not support DirectDraw or
> OpenGL and still gamers cam and contributed to Wine.

Hey, it was just a hypothesis.  Don't take it too seriously.

> Ah, now you are positive :-)
> Next question, which applications to focus on?

Obviously "productivity" applications like Office and Quicken would be high 
on the list.  But the focus should not be on specific applications so much 
as broad, comprehensive application support and compatibility.  No matter 
what random application I throw at it, it should usually work without any 
special effort whatsoever.  Today, it's sometimes yes, sometimes no.

> Wine is not a matter of taking the documentation and implementing APIs
> one by one in sequential order.

Why not?  That's the obvious place to start.  Sure, you might prioritize 
the most commonly used ones first, but ANY missing API is a problem, even 
if it doesn't seem to be commonly used.

> The problem is that many applications rely on undocumented quirks of 
> these APIs. And trailing '\' in a path there, a specific error code in a 
> corner case there, etc. The only way to make Wine '100% compatible' is to 
> test it with 100% of the applications out there to root out all these 
> quirks. And of course, noone can buy all these applications.

This is phase two -- fix anything that doesn't match the documentation.  
Yes, you'll learn it by trial and error.  But don't START here.  That's a 
good way to end up implementing something that seems to work, but later 
fails -- and then it's discovered that it failed because you didn't follow 
the documented standard.

This happens with Internet RFC's all the time.  Implementations do things a 
certain way because it seems to work, even though they're clearly violating 
the standard.  For example, many commercial websites store email addresses 
in all capital letters.  Why?  In testing, it seemed to work.  However, it 
is a clear violation of very explicit statements in the RFC standards which 
state that the local-part of an email address is case-sensitive and must be 
preserved by other systems.  (Yes, the domain part is case-insensitive.)  
In practice, most mail systems today choose to treat the local-part as 
case-insensitive, but they're NOT required to.

I had occasion to implement the TELNET protocol from scratch for a "chat" 
server I wrote.  I started by reading the RFC carefully, and implementing 
the protocol exactly to the standard.  I very quickly discovered that no 
real-world telnet client seems to handle the "Go Ahead" sequences correctly 
so I modified my implementation to interoperate.  I found that some telnet 
clients handle option negotiation sequences incorrectly, in a way which 
caused problems for my server, so I had to adapt to that as well.  These 
changes were technically due to violations of the RFC standards, but I was 
able to adapt my originally-compliant implementation to interoperate.

This is exactly the approach I would have taken with Wine.  Start with all 
the API documentation in hand, and implement it to the letter.  Then, watch 
for discrepancies and discover where practice differs from theory, and make 
the minimum changes necessary to accomodate the violations.  The longer you 
continue at this, the harder it becomes to find a case that fails.  (It has 
been many years since I found a noncompliant telnet program that my server 
couldn't interoperate with successfully -- and all the problems I did find 
were fixed within several months after the original implementation was done 
according to the specification.)

> This is why the breadth offered by occasional contributors is so 
> important to Wine, much more important than to other projects like
> emacs, apache or even gcc.

A wide range of testing is indeed important, but if the API hasn't been 
completely implemented, and people don't jump to fix any failure, it's not 
necessarily useful for a third party to report a problem...

> In fact it is more similar to the importance of having people test te
> Linux kernel with their weird sound card which is supposed to be 100%
> soundblaster compatible (pick any other peripheral you like) but turns
> out not to be. There is no way the kernel developper can test his driver
> with all the sound cards out there and it is only through the feedback
> of occasional contributors that his driver can finally work on a large
> enough portion of the soundcards out there.

They're often stuck with complete reverse engineering, which makes their 
job even harder than Wine's.  At least there is documentation for the 
Windows API, even if it's not complete or always obeyed...

> > The new APIs hardly matter as long as the applications are designed to
> > downgrade to Windows 95/98 and still run correctly.  And make no mistake
> > about it, Windows 95/98 are on the way out, just like Windows 3.1 was in
> > 1996 or so.
> 
> I don't think so. Microsoft has not come up with a compelling new API
> which is as radically different as Win32 was from Win16. NT/2000/XP are
> in that respect >90% identical to Win9x. The only 'threats' I see are
> Win64 and .Net but I don't see these having an effect in the near term.

It doesn't matter how much is identical.  What matters is the installed 
base of users.  Once Windows 95/98 users are a small minority (as 3.1 users 
are now), nobody will care about backward compatibility anymore.  At that 
point, you'll have even more APIs you'll have to deal with to keep current 
applications compatible with Wine.  Even if there's 90% overlap, it's still 
making the job harder.

> I would argue the opposite. You can only define the 'optimal route' if
> you know where you want to go. And even that is higly debatable. But you
> will not find two people who will agree where Wine should go. One person
> will only care about games because that the only Windows applications
> they use. Another will absolutely want Quicken because that's all they
> miss. Another will only care about Microsoft Word while another will
> argue that it is irrelevant since there is Open Office.

Sure, everyone has different opinions on priorities.  However, few would 
argue against the goal of "run everything 100% as well as Windows 95 does".
If I can take Windows 95a, install IE, DirectX and other upgrades from 
Microsoft, and run just about any application, it should be possible to do 
exactly the same thing with Wine.  If you don't need to use the upgrades 
from Microsoft, all the better, but that can be dealt with after basic 
compatibility issues.

> Thus any 'result' is relevant only to a specific individual. And thus
> the route will not be optimal from his perspective.

I'll agree with that, more or less.

> But if you look from a more global perspective, it is optimal because it
> goes exactly where people who care enough to contribute take it. In a
> standard development model you have people who decide where the
> development goes, developpers, and users, and these three sets are
> pretty much disjoint with just a few people from on group deciding where
> to go for the others. In the open-source model, hence in Wine, there is
> a bigger overlap between all three groups and thus in a sense, in the
> aggregate the path taken by the project is more optimal, eventhough no
> individual will see it that way.

I'm not sure that's true.  The path will be determined by the developers; 
as volunteers, they don't answer to anyone.  In proprietary companies, the 
marketing people often drive the efforts, and that doesn't all that well 
either.  Ultimately the users are important, but frequently ignored by both 
developers and marketers.  Of course, let the users have their way, and it 
could be chaos too, as featuritis takes over.  All the models suck, each in 
its own unique way.  Offhand, I'm not sure WHO could navigate these waters 
and truly chart an optimal route.

> > I very much agree.  Every little bit helps.  But it's true that they don't
> > get the prestige, status or recognition as core contributors.  Since that
> > is really the only "payment" anyone gets, aren't they, in practice, really
> > second-class contributors, regardless of the value they truly provide?
> 
> Only if *you* and everyone else as an individual don't value their
> contributions.

Saying they're "second-class" isn't the same as saying they're not valued.  
It's just that the "first-class" people (i.e. the core developers) are 
valued more, because they contribute more.  I can't really even say that 
it's wrong.  Maybe that's just life.

> It's sort of true but he who sends a good bug report does contribute to
> the project. And if you check wine-patches you will see that there are
> many names that just pop up seemingly out of nowhere.

Good bug reports are valuable, but only if acted upon.  I don't know how 
well or poorly the Wine community acts on bug reports, but I know that it's 
common for developers in any project to be preoccupied with something else 
and not tend to jump on fixing any bug reports that come in.  It's not at 
all uncommon for them to be forgotten (or left on the back burner) for an 
indefinite period of time.

And of course, THAT more than anything makes a good bug hunter feel like 
they're not valued.  If you file a good bug report, and never get any 
credit or acknowledgement for it, but the bug gets fixed, you'll still feel 
like you made a difference and be motivated to report more bugs.  If your 
reports get ignored or rejected, you'll quickly reach a state where you 
won't bother to report most bugs because it doesn't seem worth your time.

I'm not saying this applies to Wine (maybe it does, maybe it doesn't), but 
most free software projects could do a better job of making bug reporters 
feel more valued by jumping to fix bugs as quickly as possible, especially 
trivial bugs that could clearly be fixed in minutes.  People understand if 
large, complex bugs take time to fix, but when trivial bugs are ignored, 
it's truly discouraging to the bug reporter.

And as you say, widespread bughunting is indispensible.  Why demotivate it?

> No, they have just reached the 'result' you are speaking of. In their
> view 'games' support in Wine is all that matters and while you may
> disagree it is not entirely wrong. And since their games now work in
> WineX and Transgaming has said that they would release all their code to
> Wine what else is left to do? Just wait until Transgaming reaches their
> subscription threshold.

Maybe the gamers should spend some effort trying to recruite subscribers?

> I see how effort can dwindle but I don't believe it can shift around in
> the way you describe, certainly not because of an external entity like
> Transgaming. Most developpers scratch their itch, and maybe once they
> are done witht he first one they will discover another and scratch it
> too. But they will not go scratch someone else's just because it has
> been made unenjoyable to scratch the first one.

I should think they'd be more likely to move down their list to something 
else that interests them, which they had been too busy to work on before.

> Not a proof, certainly something without any scientific basis, but I
> will refer you to page 11 of Alexandre's WineConf 2002 presentation. In
> 2000, there was almost 200.000 lines of patches. In 2001, only slightly
> above 100.000.
> 
> http://www.codeweavers.com/about/news/talks/wineconf2002/wine-sandiego-mar2002.pdf

That graph appears to reflect the dot-com boom/bust, Corel's bailing on the 
Linux experiment, etc.  Unless you've got a graph of strictly volunteer 
contributions, this doesn't even suggest a falloff in volunteer support, 
much less prove one.

Deven