Wine in Humble Indie Bundle

[James Eder]

On Sun, Jun 3, 2012 at 6:16 PM, Jerome Leclanche <adys.wh at gmail.com> wrote:
> This comes up in one form or the other very often, though, doesn't it?
> Company x releases software y with a Wine wrapper advertising "native linux
> support" and users get upset. Personally, I'm glad they're thinking about
> Linux and I think Wine fills a great role as a "transitional" step between
> Windows and Linux, but I don't think it's any good to encourage using Wine
> over making the game more portable. Besides, doesn't HIB have some rule
> about requiring all games to support Linux natively?
>
> J. Leclanche

More often than not it's the case that no amount of encouragement will
lead to a native port.  If it were a simple matter of encouragement, I
doubt there'd be a point in Wine.  Often it's the case that a company
produces software with the intent to do very little after release day.
 By very little I mean that it *might* get one or two patches after
release and then it's done.  The patches address usually a handful of
bugs.  It isn't continuation of development really.  Porting software
is generally a lot more involved than fixing a few bugs.  Porting is
more like a continuation of development that often involves nontrivial
effort.

For companies that take a "fire and forget" approach to software
development, Wine provides an option where there wouldn't be one
otherwise.  Of course everyone would love to see real maintenance and
continuation of development but a realist will point out that is not
what's happening.  Nor would it in many cases even if Wine didn't
exist.

Those that object to Wine being used to port software should ask the
real question:  Would the software be ported otherwise?  It is not
even clear that it still would have been ported.  For some, you might
only get a port if it's a trivial thing to do.

I'd like to point out that despite the increasing quality of Wine,
it's becoming increasingly likely that software is designed to be
portable and made available cross platform.  It's also becoming more
likely that a user can find high quality alternatives to platform
locked applications. If Wine's existence is in fact discouraging
native ports in a significant way then you would expect the trend to
be in the other direction.

The mere existence of edge cases where Wine may have discouraged a
native port does not negate the larger trend.  It seems a bit silly to
fuss over a small skirmish when the war is being won on a much larger,
more significant, turf.  The availability of high quality cross
platform development tools has done more to win the battle than Wine's
absence ever could hope to do.

Further the push for native ports is something that happens _after_
the application was developed using MS APIs and _after_ it was ported
via Wine. (Ironically, there'd be much less fuss if the developers
just kept it as a Windows only program.)  If the original developer
cared about being portable they would have used portable libraries
from the start.  As far as I can tell, there's no indication that Wine
was a part of the original development decision to use non portable
APIs.  There's only the fears of some that it might have or will
someday.

http://en.wikipedia.org/wiki/Make_a_mountain_out_of_a_molehill

-- 
Jim