Re: WineX and the AFPL

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.

> In any open source project you cannot force a contributor to work on a
> specific issue. [...] Sure you can try to advocate a specific issue as 
> important, but as someone said, this is liking 'herding cats'.

Of course.  I've never advocated FORCING contributors to work on anything 
in particular.  I've questioned the wisdom of the focus, perhaps, but that 
isn't the same as advocating coercion.  Volunteers should work on whatever 
they choose.  Company employees should work on what they're paid to.  If 
anyone makes a poor choice, that's life.

> So if you think there are more important aspects than DirectX, then say
> which areas are more important, why, and try to convince others. But you
> should not lament that an open-source project spent too many resources
> on a specific area because their is not 'resource allocation' in the
> first place.

I do think some other areas are more important, but that's irrelevant here.  
My point was that any developer who stopped working on DirectX, but KEPT 
working on Wine, cannot be viewed as a "loss" to the project as a whole, 
because their efforts in other areas wouldn't have occurred if DirectX was 
taking up their time.  And that it might be just as well, because something 
else might turn out to be more valuable to the project, even if it's not 
the developer's preference.  And if they choose to work on it, great!

> Now if DirectX allows a whole class of applications to work in Wine,
> then this opens Wine to many new users. And I hold the view that a
> fraction of these users will then contribute to Wine, either as a
> one-off or more on the long term. And this is benificial to Wine which
> then makes DirectX important. Now whether this is *the most important*
> thing to work on is debatable. Everyone tends to see their pet
> application as *the one* application that Wine needs to become really
> mainstream.

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.

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.

If Wine supports games 100%, the gamers may come, but most of them won't 
balk at dual-booting anyway.  If Wine supports games okay (but too slowly 
for the gamers) but runs all regular applications perfectly, that's when 
you'll get the flood of regular users dumping Windows and moving to Wine 
and Linux.  Once that happens, the new games might be released for Linux 
natively anyhow, and Wine game support could be tacked anyhow.

The problem is that regular users expect 100% compatibility.  90-95% is 
good enough for many of the current Linux users in the world, but to get 
people to discard Windows, you'd need 100%, or very close to that (99.9% is 
probably good enough; 99% may not be.)  Currently, Wine does a good job.  
But regular users expect it to be perfect.  They'll put up with a little 
instability (Microsoft has trained them to), but not application failures 
because of unimplemented APIs.

Now, I don't have a problem with the Wine contributors focusing on games, 
but I wish they wouldn't.  It may be great fun and all, but it would really 
be wonderful if the compatibility could go from 90% to 100% instead.  I'd 
rather have slow execution but perfect compatibility than games that run at 
a high framerate, but meanwhile regular (untested) applications can't be 
presumed to work correctly under Wine.

But like you say, nobody does "resource allocation" on an open-source 
project, so that's life.  Besides, if the goal is to enjoy the journey, 
rather than achieving an end result -- well, maybe games are the way to go.  
But there's a large contingent of people out there hoping for results, and 
just like Transgaming's DirectX code may have discouraged development of 
DirectX code in Wine, the existence of Wine discourages competing Windows 
emulators as well.

Perhaps it's just as well if Rewind draws a separate crown focused entirely 
on results (for the many who want that) and Wine continues as an enjoyable 
journey for its developers.  No reason both approaches can't coexist...

> Yes, full 16-bit application compatibility (not Win 3.1 compatibility,
> see below) has been deprioritized a long time ago. This is why you did
> not see a Wine 1.0 version in 1995 with full support for 16-bit
> applications (and only 16-bit applications).

In 1995, a Wine 1.0 with full 16-bit support WOULD have been valuable.  
Now, in 2002, it's not.  Remember, Windows 95 came out in 1995 and it took 
some time before software vendors stopped supporting Windows 3.1 -- it 
would have been very valuable to have 100% support for 16-bit applications 
as Wine 1.0 in 1995, and Windows 95 could have been saved for development 
towards a 2.0 release...

> No, you are mistaken. Wine has never intended to be a clone of a
> specific Windows version. The only thing we care about is compatibility
> with windows *applications*. This is quite an important distinction.
> This means for instance that eventhough Win95 does not support Unicode
> APIs, Wine does not return failure for Unicode APIs just because you
> specify '--winver win95' (yes, I know, now it's in the config file).

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.

> So, this means it does not matter whether Windows 95 is or is not a
> stationnary target. All that matters is that windows applications work
> in Wine.  *This* is the target. So Microsoft may stop supporting
> Win95/98 all they want. This will have no short term impact on the
> applications out there, and thus on Wine. Similarly, MS can add 10000
> new APIs in the next version of Windows, if no application uses them, it
> does not matter either.

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.  And getting 100% compatibility with Windows XP will be MUCH
more difficult.  The opportunity to fully emulate Windows 98 and convince 
ordinary Windows users to dump Windows and use Linux/Wine is slipping away, 
just like the Windows 3.1 goal has long since slipped away.

This is why the results matter to some people -- they don't want the Wine 
project to be a neverending journey, but a means to an end.  That end is 
discarding Windows in favor of Linux and Wine.  Maybe it could have been 
done by now if Wine developers wanted results more than to have fun.

Here's a question for you -- if Windows 95 can install DirectX, why can't 
Wine run the same DirectX code from Microsoft, if it fully emulates the 
capabilities of Windows 95?  And if it can, why worry about reimplementing 
it just yet?  Let people download and install it as if it didn't come with 
their operating system...

> Well, you at least give the impressions that you consider that
> open-source projects can order contributors to work on specific issues
> which is not the case as I have shown above.

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

> Also you seem to consider that occasional/one-time contributors are some 
> sort of second-class contributors. Sure they may not get the prestige, 
> 'status' or recognition of 'core contributors'. But in the aggregate 
> their contributions are still very important.

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?

> Even more so for a project like Wine where contributors can only test 
> with the applications they do have and where these occasional 
> contributors are critical for getting the necessary breadth of 
> application testing and support.

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.  Now, these are valuable and necessary functions -- but someone 
still needs to do the work on the other end to follow through, and if 
nobody is interested in fixing a bug or finishing the necessary support for 
an application, there's not much that occasional contributor can do.

> 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.  Anyone who 
stops working on, say, DirectX and works on something else instead, must be 
committed to the project -- that's why they're still working on it.

I don't know if ANYONE walked away.  Alexandre described "damage" and 
"loss" to the project when DirectX development fizzled out, which seemed to 
imply that some developers had abandoned the project, from his description.  
Given that suggestion, I wondered what could cause someone to walk away 
entirely -- and it occurred to me that hardcore gamers MIGHT help out with 
game support without actually forming any real commitment to the project.  
It's a possible explanation for what Alexandre seemed to be describing, so 
I offered it for consideration.

Since then, the only examples I've heard about were of developers (like 
Marcus) who abandoned work on DirectX, and started working on another area 
of Wine.  That's a committed developer, no question about it.  Moreover, 
describing such a change in focus as "damage" or a "loss" to the project is 
misleading -- the work on DirectX was equally a loss to those other areas.

Any development work represents an opportunity cost to other areas being 
ignored.  Shifting around the effort may be a "loss" to one area, but it's 
equally a "gain" to another, and overall it's a wash for the project as a 
whole.  Alexandre's description led me to believe some (if not many) of the 
developers were abandoning the Wine project completely as a result of the 
influence of Transgaming.  I've not heard one example of anyone abandoning 
the project, so my hypothesis may be moot.

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.  No matter where the developer focuses his efforts, it's a benefit 
to the project as a whole, even if DirectX support stagnates for now...

Deven