Re: WineX and the AFPL

On Wed, 5 Jun 2002, Deven T. Corzine wrote:

> On Tue, 4 Jun 2002, Francois Gouget wrote:
>
> > On Mon, 3 Jun 2002, Deven T. Corzine wrote:
> > [...]
> > > In the grand scheme of things, is DirectX really one of the most important
> > > things to be working on?  If it's more of a moving target than other areas,
> > > won't it take even more effort to keep up?
> >
> > This is irrelevant.
>
> It's relevant to the claim that Wine was damaged because developers chose
> to stop working on DirectX development.

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.


[...]
> I do think some other areas are more important, but that's irrelevant here.

Well, it is relevant to Wine in any case.

One should not advocate against a specific area like DirectX. All that
will achieve is to demotivate people who are working on it, make them
feel that their work is useless and that they are wasting their time by
working on Wine. All this does is drive them away.

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.


> Unfortunately, DirectX opens up an unusual class of users: gamers.  Many
> gamers are hardcore, and will go well out of their way to play their games.
> If they have to maintain a real Windows partition to play their games, if
> Wine doesn't support them well, they'll do it without a second thought.

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


> Most regular users, on the other hand, really don't care about all these
> details.  They just want their applications to WORK, and don't really care
> much beyond that.  Most won't bother with the hassle of dual-booting, so
> getting them to try Linux is very difficult.  The best hope of getting them
> to use Linux is to make their applications "just work".  Wine is perhaps
> the most essential tool to make this possible.  Integration work like
> Lindows can then bridge the gap, and perhaps get people to switch.  That's
> what will be the most beneficial to everyone.

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


[...]
> My point was that the valuable target now would be 100% compatibility with
> Windows 98, because many applications still run under Windows 98.  I'm not
> saying it should be a clone, and refuse to implement more advanced features
> from other Windows versions.  I'm saying that ANY application that works
> under Windows 98 should JUST WORK.  No testing required, no "what if they
> use those rare APIs" questions.  That's what I mean by 100% compatibility.

Wine is not a matter of taking the documentation and implementing APIs
one by one in sequential order. 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 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.

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.


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


> Well, you misunderstood me.  I don't think the developers can be ordered to
> do anything.  One can request, but not demand.  The consequence of this is
> that open-source projects often end up taking a route that isn't optimal,
> because that's where the whims of the developers took it.  That's fine, but
> it can be unfortunate if many people are waiting with bated breath for the
> results promised by the project, as with Wine...

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

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

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


> Unfortunately, with a project as large and complex as Wine, it's hard for
> an occasional contributor to do much more than testing and offering bug
> reports.

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.


> > Thus they deserve your respect and support rather than hints and
> > allegations that they are not 'true' Wine contributors.
>
> They have it.  The only "untrue" contributors would be ones who walked away
> from the Wine project entirely due to Transgaming's involvement, because
> they had no interest in working on anything but game support.


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.


> If you look at the big picture, I don't see how you can call it a "loss" if
> a developer keeps working on Wine, but no longer works specifically on
> DirectX.

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.

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

--
Francois Gouget         [email protected]        http://fgouget.free.fr/
      Any sufficiently advanced bug is indistinguishable from a feature.
                            -- from some indian guy