Sean Middleditch

Bought a Wii on E-Bay.

$350 for what would cost $250 if I could just be patient enough to wait for it to show up in stores. Clearly, patience isn’t a virtue of mine.

http://linux.slashdot.org/linux/07/02/17/0219225.shtml

It looks like the sole bit of code I wrote several years ago that’s been running on desktops all over the world just got replaced by Linus himself. While a little sad on my part, he has reinforced my original point.

Some years ago, Metacity only supported maximizing windows on double-clicking the titlebar. A number of users were complaining about how they wanted it to shade the window on double-click, not maximize. So I did what those losers wouldn’t: I wrote a damn patch that added the feature.

I personally can’t stand window shading. I added the patch mostly just to prove a point, and to shut certain users up.

To this day, we still have so many, many morons who bitch and whine about how GNOME refuses to add new features or options. Which is nonsense. Usually, if GNOME developers refuse to add an option, it’s either because (a) they don’t need it themselves, and they have no reason to write a patch for whiny, insulting, demanding users, or (b) they believe that the option merely switches between two broken behaviors, and it would be better to wait and think about it and figure out a single, non-broken behavior.

Linus is one of the more well known GNOME detractors, who has made those same moronic claims, but now he’s at least shown that he’s better than most users. He wrote a patch. The core GNOME developers may have no need at all to configure middle and right click behavior, and hence they never bothered to add the feature, but given my experience above I’d say it’s quite likely those patches from Linus will go in.

Frankly, I’m happy with how GNOME developers run things, even though I sometimes get bitten by their decisions. GNOME is Free Software. I got it for free. I didn’t have to do a single thing to get a fully functional desktop OS and application suite. If they don’t want to go to extra effort just to satisfy me… fine. It’s their choice. I’m glad they don’t bend over backwards to add in every requested feature because, even if one or two I’d like to have aren’t there, I’m also not stuck dealing with immense bloat. I truly hated the old days of the Linux desktop (still alive today on KDE) where I couldn’t figure out how half the crap on my screen worked. The configuration options were impressive, but finding what I wanted was difficult, and usually the ideal behavior I wanted required some specific combination of 20+ options! Heck, even then it was usually only _close_ to what I wanted.

One of the easiest examples is Metacity’s window resistance behavior. If you need to align windows, window snapping used to be the way to do it. The problem was, snapping was annoying as hell when you weren’t trying to align windows. If you spent enough time tweaking the snap sensitivity, gravity, and so on, you might have been able to get things setup so that you could easily align windows and not get bitten too often when not aligning windows.

Metacity didn’t support snapping. A lot of users demanded it. Aligning windows wasn’t easy. Metacity still didn’t get the feature. Users whined and bitched and called the developers names. But the Metacity developers were right: snapping was a pain in the ass, and it took 5+ configuration options to ever get it working close to sanely, and even then not perfectly. Finally, Elijah added the window resistance Metacity has now. Since then, I’ve not seen a single request for snapping, nor a single request to turn resistance off. Instead of caving in to users’ demand for some particular broken feature and option, Elijah approached the actual problem and worked out a different, better solution.

Frankly, I’m really glad Metacity developers didn’t just blindly give in to the whining and demands, because then we might be stuck with an “almost good enough” solution that cluttered the configuration UI, cluttered the code, and probably would’ve pushed off the desire to work out the ideal solution to far into the future.

The GNOME developers did not dismiss the users’ problems. They dismissed the solution that the users requested. Which is the problem, really. Users request solutions instead of announcing problems. Sometimes the solution the user asks for to fix his problem is the best solution. Often times, it isn’t.

As the phrase goes, the users ask for solutions to the symptoms, not the cause.

Now, maybe the GNOME developers could handle it better. Maybe sometimes they outright deny requests for features when they could simply say, “We acknowledge the problem, but we’d like to take the time to see if there’s a better solution. We’d like a behavior that can be the default that does what you need and does what everyone else needs, too. Please be patient, and let us know if you have any further information or ideas on this problem or alternative solutions. Thank you.”

More often than not, they probably just say, “This feature has such-and-such problems, and while it solves your issue, it creates others. We won’t add more options for broken features. Goodbye.”

The latter response sounds far more like the developers simply don’t care about the users’ problems, or like no solution which requires a new option will ever, ever be considered for implementation. That’s clearly not the case (GNOME has had many options added since the 2.0 release), but people will read into the second response above as implying that it is.