Wine Project Frustration and Forking 470
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?"
Re:Sounds a like a storm in a teacup (Score:1, Interesting)
I too wonder who is calling for a fork. I've followed the mailing list but haven't seen anyone do that.
The problem here however is that Massimo Del Fedele's DIB engine most likely won't get accepted into wine, as he have also said himself in an earlier post.
Wine mouse bug kept unfixed (Score:5, Interesting)
The developers in charge insists that it could only be fixed by making changes in the code all the way down to X.org layers and perhaps even in the kernel mouse handling. However, this is demonstrably false, because: A) there is no such issue in Wine's fork Cedega; and B) some "outside" developers pointed out that there is a way to deal with this problem without asking for personal favors from X.org and the Linux kernel, namely, to use the DGA subsystem [winehq.org] to achieve the required mouse behavior. But that's not going to be accepted either, because someone somewhere decided that DGA was "deprecated" and never mind that the deprecation was ONLY concerning its graphic component.
The bug was reported almost three years ago, and it's almost like it's kept "in" on purpose, so that Wine never works properly with many games, and so that users will always have a need for the proprietary Crossover Games product.
Re:The secret is to not care (Score:5, Interesting)
After that, if they don't want your code, it's their loss.
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.
Re:When? (Score:2, Interesting)
Take Amarok, for example. That situation practically begs for a fork
What's the situation with Amarok?
Re:When? (Score:3, Interesting)
I've only been hearing positive stuff coming from the Amarok devs.
Is the parent mixing up dev's actually getting fed up or just people being unhappy with the new interface? Is the parent also aware that in Amarok 2.2 and 2.3 the interface will become largely like Amarok 1.4 (with at least the possibility to fully customise the interface)?
MS Office support (Score:4, Interesting)
In the blog post the project lead is talking about working on better MS Office support. I would love that. Especially MS Office 2007 SP2.
Add a little Samba gui integration into Ubuntu (share folders and drives point and click) and I am ready to roll out Linux in my companies. Seriously. Myself I have been a Debian desktop user since Slink.
Comment removed (Score:5, Interesting)
Re:When? (Score:2, Interesting)
I agree that Amarok 2.0 and 2.1's features aren't on par with 1.4.
But, I cannot wait till 2.2 and 2.3 where full support for pluggable media (iPods, CDs, etc), fully customisable interface and better playlist usability will be major advances.
The real advantage will be after feature parity with 1.4. Amarok 2.x is far superior 'under the hood'.
Re:What is more frustrating... (Score:5, Interesting)
That's easy to say, but computers are a tool to be used as a means to an end, and that's how most people use them. If I'm a graphic professional, I'm not going to boycott Adobe just because Photoshop isn't available on Linux. There are some great OSS solutions out there, and there are thousands of programmers that bust their ass every day to write and improve them, but the fact of the matter is that all that effort doesn't matter when someone has a need, and there's not a Linux solution that meets that need but there is one for Windows. It doesn't help when the OSS community refuses to listen to them and attempts to tell them otherwise (i.e. "GIMP is just as good as Photoshop!"). Given that, really the best you can hope for is that the person will run their Windows software under WINE instead of just discarding Linux altogether and using Windows itself. Most people don't care about what operating system they use - they just want to get their work done.
Learn from the unions, buy software made for Linux native if you want more of it.
As long as the general viewpoint of the Linux community diametrically opposes that of the majority of commercial software vendors, you're not going to see any appreciable amount of native software for general sale. Most commercial software houses of any size are extremely loathe to release source for their products, and I'd bet that the majority of Linux users aren't going to be interested in purchasing a product that doesn't abide by their political views by including source code or otherwise abiding by the GPL. Not to mention the support headaches the software houses would have owing to the huge number of widely disparate distros out there ("is that config file in
Don't get me wrong - I have several Linux boxes here at home, one hosted in a data center several states away, and I work exclusively on Linux machines at my job. It's not that I don't like Linux. It's just that there's going to have to be a lot more that happens in the Linux world for it to get traction on the desktop, and thus to become more attractive for vendors regarding native implementations. Hopefully the recent licensing changes in Qt will grease the rails a bit.
Re:The secret is to not care (Score:5, Interesting)
The problem is that Alexandre Juliard, the project's dictator, often rejects patches with reasons that contain no useful feedback except the patronizing statement "you can do better", or "it's not right".
I've had a patch I wrote for moving the wineserver code to epoll rejects because "it was not pretty". Michael Mccormak then made two more attempts at a rewrite that were rejected for precisely the same reason. In the end (several months later), Alexandre wrote his own version. At the time people explained this behavior to me as "wineserver is something he is very sensitive about".
Several years later I wrote a patch to something to do with the Window reordering being ignored (with no error message) in some cases. It is a pretty unbelievable piece of Windows mislogic, so I wrote a test case to prove this is, indeed, the behavior on Windows. The test case was rejected because it was not pretty enough. When I asked for more specific feedback, Alexandre responded with "If I can think of better ways to do it, so can you".
A project with as many contributers as Wine should have room for more than one programming styles than one. I thought it was only me for a while, but if it made it to slashdot, obviously it's not.
Shachar
Re:When? (Score:1, Interesting)
A fork might also get a whole range of new developers on board, which have seen their patches rejected or ignored without any appropriate explanation or attempt at correction.
Re:When? (Score:4, Interesting)
Its been coming for a long time though, that's why its no longer the official kde media player. The Amarok developers don't bother with KDE ui conventions like (ctrl+m, or mac os x style menubars)! Unfortunately nobody in KDE wanted to compete with amarok so kde4 users are stuck with dragon or reverting to amarok1.4
Re:Look deeper (Score:2, Interesting)
> 1 & 2) I'm not seeing anything on bug reports or the mailing list about specific issues.
What do you mean by "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?
I am not Alexandre. That said, Massimo's DIB engine is a combination of Jesse's attempt and Huw's attempt.
This is not a matter of using events and polling. It's about creating something that is maintainable.
> 4. RTFA: "DIB Engine : Passing all tests"
I did. I also read Austin's note that not all tests were passing (and Massimo's subsequent comment that a fix will be available in a future - possibly already available release). So it almost, not quite passes the tests.
In addition to this, Massimo's engine causes some of the todo's in the bitmap tests to pass (a good thing). Those todo's would need to be removed once the DIB engine lands (and if it is optional, there would need to be support for getting the non-DIB engine version not triggering the todo blocks).
> 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".
From what I understand, the code it is replacing does (mostly) work, just painfully slowly because it round trips to the X server to do the rendering. The code it is replacing is not a stub.
> 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?
If you want to know what Alexandre thinks about a patch or design, go to the #winehackers IRC and *ask* him. He *is* approachable.
And if you want to go through the hundreds of patches that Wine gets per day, while replying to each one that does not get accepted giving a detailed explanation why, and trying to maintain a level of quality be my guest. Just accept being called a Prima Donna and have people complain about you because their patches are not accepted and they don't know why.
Re:About forking (Score:4, Interesting)
People might not like you taking their code and you risk alienating valuable assets if you proceed rashly.
So it is not socially acceptable to just fork the code?
I can understand the aspect of upsetting people and alienating the community, but the whole concept of "people might not like taking their code" confuses me here. I have always assumed that when something has been released under open source license, that act in itself is some kind of agreement that the code can be forked at some stage.
Personally I have never forked anything, but I have released few pieces of code to public and I have always assumed that if someone likes my work and wants to take it and improve it or take it to some new direction, then by all means, just take the code and start a new project. Granted, I don't have a thriving community behind me, so there isn't this social aspect to consider.
It's interesting to see that there can be this whole social protocol around the open source software development world. For me this is interesting, because I have always assumed that programmers in general seem to swear on following the OS licence literally regardless on social impact.
Comment removed (Score:3, Interesting)
Re:What is more frustrating... (Score:3, Interesting)
If that is the case, why then are they then so eagerly giving out a license to legally decompile their program?
That is a disingenuous or ignorant statement. Reverse engineering is not restricted to decompiling.
Re:"disgruntled core developer"? (Score:1, Interesting)
I have also been following that list for a while now. And it is probably one of the strangest and most uninhabitable I have ever encountered.
Many on this list have this fantastic way of completely discouraging people by treating them like they are idiots.
Below is an actual example, I find it quite hard to believe that the involved developers actually thought that writing a DIB engine was a "fill-in-the-blanks exercise", this is quite typical:
Jan de Mooij writes:
> On Sun, May 24, 2009 at 12:04 PM, Chris Howe wrote:
>> 2009/5/24 Massimo Del Fedele
>>
>> 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 dissapear 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.
>>
> Agreed. I would be willing to invest some time this summer in a DIB
> engine but it's impossible because of this. A wiki page describing the
> "right design" and what is needed in which component would be a great
> start. Maybe a goal for next WineConf?
Writing a DIB engine is not a fill-in-the-blanks exercise. A large part
of the task is precisely to come up with a good design, validate it with
a prototype, and then convince people (especially Huw and myself) that
your design is good, that you know what you are doing, that you have
anticipated the common objections and have good answers for them, that
you are willing to make requested changes, that you have good test
cases, etc. Showing that it more or less works on a couple of apps, or
that it passes the (very few) existing gdi32 tests, is of course
necessary, but by no means enough. If you want to tackle this, it will
also help to have a good track record in getting simpler patches in
first.
Once all of this is done and the proper design is in place in the tree,
then there might be a number of fill-in-the-blanks tasks to implement
the less common graphics calls that would probably be stubbed out in the
first version. But we are nowhere near that point yet.
--
Alexandre Julliard
julliard@winehq.org
Re:The secret is to not care (Score:3, Interesting)
I have had quite a bit of code go into Wine. The entire BiDi support was done by me, as well as some other parts (I did a rewrite of wineboot, for example). It is very hard to claim I don't know how Wine works, or how to submit patches. I even used to appear in Wine's "who's who" page, and have an interview with me [winehq.org] for WWN.
Not only that, but Alexandre knows me. The last time we met (wineconf in Germany, a few years ago) we had a (good humor) conversation that went something along those lines. I mentioned I don't have much time to work on Wine any more, and that maybe it doesn't matter because my patches get rejected anyways. He said that it's too bad, becuase he likes rejecting my patches. I'm saying this because I want to stress that having your patches rejected is all a part of working on FOSS, and is not what I was referring to at my grand parent post.
But the rejections I'm talking about are not explanations received on the list, where communication is short. The actual patches were flat out ignored. The explanations were received on IRC, where communication was bidirectional, and there was no misunderstanding that resulted from lack of time.
And yet, the above reasons were all that I received.
Shachar
Why does that sound familiar? (Score:3, Interesting)
This is honestly not intended as flamebait. Simply swap some of the variables as I did above, and we see some of the same dynamics, and similar upset, as we saw with Vista.
It seems the Amarok folks haven't taken the time to learn from Microsoft's expensive lessons, which is a genuine shame. Love them or hate them, Microsoft *does* give us all a lot, in terms of vicarious experiences and case studies for how, or how not, to undertake software development.
Let them spend the billions, fine. The punchline is that we too can learn from what they do.
Cheers,
Gross misrepresentation (Score:1, Interesting)
As one of the people involved in this particular discussion about the DIB engine (see Elektroschock's link "comprehends the dissatisfaction"; I'm the guy Massimo is quoting), I'd like to say that the comment "core developers with the arbitrary project governance" is grossly out of proportion. None of the people mentioned in this wine-devel post are "core developers", nor are we complaining about Alexandre Julliard's project leadership.
What is main the issue with Massimo's DIB engine is that AJ doesn't like the architecture. Chris was merely stating that there is no documented way for the architecture of the DIB engine to be developed.
In addition, Massimo does not maintain his patches in a git tree, which would make it easy for cherry-picking and testing. Instead, he chooses to update the patches on the bug #421 page.
As for forking the project, any *successful* fork would either have to have the level of dedication and manpower that AJ and the other core developers show (it can be argued that Cedega and ReactOS do not have this) or it would have to remain so close to Wine's source that it would just be "Wine with this patch I like" and end up leaching off the work of the Wine developers.
Of course, if someone wants to do that, there's nothing stopping you! Wine is opensource after all.
Re:Wow. What a load of crap. (Score:3, Interesting)
Hey Max,
I am totally a fan of your DIB engine work. It's been
wonderful watching you attack this difficult job.
I do hope you're able to see it through to the end!
- Dan
Re:When? (Score:2, Interesting)
You've either misread or misunderstood my comment. I actually stated that 2.2 and 2.3 will be focusing on the playlist and user interface. As in, it will have the capability of looking and behaving like 1.4. When I said 'far superior under-the-hood', I wasn't just referring to the nice Wikipedia plugin - I was actually thinking about things like the faster storage database. You know, being able to search your songs a lot quicker, or being able to have far larger databases of music which Amarok can effectively handle. That's better.
I think you've just gone ahead and said something that is completely subjective. You think that they forgot about the users. Probably what you don't know is that since the inception of KDE 4.0, the KDE community has never been more greatly focused on the users. There has never been a time in KDE's history where they have ever worked more closely with GUI designers, artists and users. For blinky's sake, the whole focus of the entire project is on the users.
Re:The secret is to not care (Score:4, Interesting)
I will not go this far, no. Certainly not for the whole project. Certain areas within the project are more likely to get this type of response, yes.
Also, according to Alexandre himself in one of the wineconf, the patches he's likely to drop without a word are not those that are entirely bad (those get rejected), but those that he cannot make his mind whether they are or are not bad.
The problem is that this gets frustrating. When I was a regular Wine hacker, this wasn't so bad. I would persist long enough and in the end something would go in (not always because I made the patch better, mind you). The epoll case was a turning point, as far as I'm concerned, because of several reasons:
So, in answer to your question, this attitude SOMETIMES holds the project back.
I love working on Wine, and what I'm describing here is by no means the main reason I'm no longer active, but it does take some of the fun out of it. As you know, if you're not working on a free software project for fun, why work on it?
I don't know whether to point it out, as I have no idea whether it is relevant or not, but Mike, today, is also not an active Wine hacker. He wouldn't answer my question regarding what happened, but I got the impression it was something personal (he was a CodeWeavers employee, but he also did lots of pro-bono work on Wine). Let me assure you that losing him is a far greater loss for Wine than losing me.
Just to be clear - I'm not the one calling for a fork. Also, I know Codeweavers (both the company and the people running it) and do not tend to buy into the commercial/free conflict conspiracy theory. Still, I do think that Wines leadership has an attitude problem that affects the project.
Shachar