Slashdot Mirror
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?"
To be honest, Forking is only really possible once enough of the right people get mad enough with the project, and, by that time, it's probably about time to fork anyway.
Take Amarok, for example. That situation practically begs for a fork, but it hasn't happened yet (AFAIK) because people aren't motivated or organized enough to bother with maintaining a new version, so the project remains unforked.
If you can get enough people organized enough to start and maintain a separate version, especially of something as large and difficult as WINE, that's probably reason enough to go forward.
Even then, maintaining momentum is of critical importance. When X.org forked from the XFree86 tree, a great deal happened very quickly. However, in the latter half of 2007, development stagnated, something that was mentioned on at least one mailing list (I can't find it now for some reason). IIRC, part of the reason was simply that not enough development time was being spent on it, because people had other things on their plates.
It made for some frustrating times for Fedora 9 users, as nVidia refused for a while to release a driver for beta version of X, and F9 was released in May 2008 without a proper release version of X.org, that project still being stuck at 1.4.99, with the 1.5.0 release not happening until September, by which time the Fedora 10 beta had already been released. F9's development plan had been built in part around the expected timing of the X.org 1.5 release expected in the very early months of 2008, and I'm sure that the failure to make that timing made for some interesting discussions inside of the Fedora camp.
I understand that the 1.5 release was an enormous undertaking as part of the attempt to get rid of cruft left over from so many years of legacy support, but it still illustrates the perils of dealing with a large, complex codebase, even with an enthusiastic community backing the fork, and even if it is the reference implementation.
(I should mention that I don't come from a coding background, but I've worked with enough programmers to understand the issues of code maintenance and enhancement. Even in a corporate environment with lots of money and people behind a project, schedules don't always stay put.)
You can never go home again... but I guess you can shop there.
The real advantage will be after feature parity with 1.4. Amarok 2.x is far superior 'under the hood'.
Do you know what I liked most in Amarok? The UI. A playlist, a file browser to drag stuff from, and a play button. That's it. I don't need a more complicated UI. I don't want one. Now there's a button for Wikipedia?
Do I have to go back to XMMS just because everyone's so fucking Web 2.0 now? In fact, the whole KDE4 thing looks like they want to deliberately lose every user who wants a simple, clean, responsive, effective UI. They overhyped the API changes so much, they forgot about the users. Why do you force me to use Fluxbox? I've already given up on Azureus, they did the same thing with Vuze.
Fun fact: even Vista still has the classic UI.
And then a numbnut promptly crawls out of the woodwork to respond with "errr, but didn't you hear that DGA is obsolete because it allows apps to write directly to the framebuffer".
And mods happily mod it up to 5 Insightful, rather than 5 Funny (or -1 Reading Comprehension).
Well, I was thinking to not to enter inside this discussion, but... just to be precise :
1) I asked *many*, but really *many* times to Alexandre, on mailing lists, on IRC and to many other people about what would be the "right" design for an engine, but *never* got an answer.
Well, to pe precise, I just got *one* people answering me kindly, and it was Dan Kegel, whom I thank very much for its support. I tried also to ask Huw both in irc AND by mail, but no answer at all, even not a simple "sorry, no time for that".
So, please, don't tell me that I didn't ask or I didn't want to follow the right way, that's plain wrong, and you'll see it if you loose some time reading *all* posts on wine-devel about.
2) My design started with Jesse's one, right, then tried to merge Huw's one, because somebody told me that Huw's was the "right accepptable" design.
After loosing some time on it, and "without any feedback" from Huw nor Alexandre, besides one laconic "I don't think a multi-author stuff is accepptable", and after loosing most of time to keep my ongoing driver in sync with wine, I had to give up with that solution and think about a new one.
The *only* people involved with former designs that spoke to me was Jesse Allen, and I appreciated that really. After the laconic comment above, I lost about one week splitting the engine by author's commits. That was a large work, because I rewrote most of the code, but, as that was the *only* comment got so far, I was hoping that doing so I could rise the hope to see the engine inside wine.
Keep in mind that also in previous works I DID KEEP the original copyrights inside code, even when there was just a code line from original author.
3) At the end, tired of having to loose 80% time to rebase the engine and 20% time to improve it, and after getting to the conclusion that Huw's approach wasn't the best one (also well explained in mailing lists), I decided to start over with a brand new design.
So, again, please don't tell me that I ignored the long, hard part of the job.
It I should say that all, your "long, hard part of the job" contained almost as many bugs as code lines.
So, please again, *before* look at code, *then* comment.
The only part I kept from original Huw's design is the line drawing functions, and also those hardly patched and corrected.
4) If you'd be honest, you'd have reported ALL the content of my "too much work" comments. Those were referred to "too much work in hopeless tasks", which was the true stuff.
I don't code for job, nor I want to do it. I code for fun, because I like Linux and I like wine.
I've made small contributions since many years. That said, I, and I guess I'm not alone, don't like to loose my time, even if it's for fun. If I make a patch which is rejected with a *good* reason, I can try to improve it and to repost it; if the patch gets rejected because "it's not right", "it's a pain to review", "it's too commented" (yep, I got also that one.....), I simply keep it on my tree and go on.
5) The DIB engine was an effort for a stuff I needed, and taken further because it seemed to me that many people were interested about. It's not a "wonder patch" (never said that, but, again, you should just read mailing lists...), it's not perfect, it's not complete.
But, it works. On most apps, and is passing all (well, all -1 because lack of time lately) tests of wine suite.
It makes some apps simply usable, point. It's not a code masterpiece, nor it wants to be.
it's fixing a long standing bug to some extent, and it will do it 100% given enough time.
It's an *unpaid* work of 1 people for some monthes. If I should value it's time on my current's job time, you'd be surprised by the amount.
6) I don't know much about Codeweavers, just that they offer good compatibility for many important apps, and I appreciate it... And I find it right that thay earn money on it. Opensource doesn't mean "for free", of course.
I don't even know if a DIB engine is embedded in crossover products, nor it's important to me.
NOR I hope about a fork of wine project. We've got enough forks on Linux/unix, sometimes that's good, most times it's a bad stuff, too many resources are lost on it.
Ciao Max