Wine Project Frustration and Forking

Elektroschock writes "Wine attempts to implement the Windows API layer on Linux. There are some limitations and an important one is the missing DIB engine, bug 421. Chris Howe comprehends the dissatisfaction of core developers with the arbitrary project governance: 'Sorry to sound like a stuck record but the Wine website still lists "write a DIB engine" as a requirement, and every time someone does, the patches disappear down a hole because they're "not right." Someone document what "would be right," or take "write a DIB engine" off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions.' The latest attempt of Massimo Del Fedel satisfied all requirements set previously for the long standing bug 421, and his optional engine seems to work fine by all Wine quality standards. He seems to be extraordinary stubborn and insusceptible to mobbing. Usually it is extremely frustrating for developers when the goalpost is constantly moved. When is the right time for project members to fork when their chief maintainer does not respond anymore or pursues an adverse commercial agenda?"

Comments

Re:The secret is to not care

[DrXym]

Wrong. The loss is just as much yours and the users'. If I was an evil M$ overlord, I would definitely attempt to mess up projects like wine, and the easiest way to do this is to find that key people on whom everything relies and try to influence those in the wrong direction. Seen from this viewpoint, it is easy to see the loss is not "theirs" at all. And even if this is not the case, the point is the same.

Actually the easiest way is what Microsoft is already doing. Make the Win32 API a rats nest of undocumented functions and behaviour. Then throw in some huge dependencies on binary components such as Internet Explorer to guarantee incompatibility. Then start deprecating APIs and reinventing the functionality again, preferably again with undocumented behaviour and binary dependency on some undocumented DLL. Rinse and repeat. WINE will always be playing catchup.

Microsoft did it to WINE and now they're doing it to Mono. Mono has found itself in the same boat and it will never, ever catch up with .NET.

Re:Look deeper

[Zombywuf]

1 & 2) I'm not seeing anything on bug reports or the mailing list about specific issues.
3. That's not an explanation, that's an excuse for not having an explanation. Any design is a mix of architectures, would you reject a patch for the sole reason that it used events /and/ polling?
4. RTFA: "DIB Engine : Passing all tests"
5. The code it's replacing doesn't render anything in many places. WINE would prefer a stub to a mostly working implementation? Anyway, where is this report, I see Steven Edwards has posted a single image to the bug and called it a "comparison".

Having a Prima Donna at the helm of a project is not the same as "high standards". WINE has achieved some marvelous things, but the pace of development is very slow. Making people who have contributed their time to help play guess-what-the-project-leader-wants looks like a major cause of this. How much code has gone to waste because the devs couldn't guess what was required of them?