Well, first I'm not sure how you define "Old-time super-die-hard Linux users" vs "More casual Linux users". Like most other FOSS developers I know or have met at various conferences, I consider myself as neither "Old-time super-die-hard" (I even use an IDE rather than vi/emacs), nor merely a "casual user". I spend more than 8 hours a day on a Linux machine and like to have it configured for my needs. The original gnome/kde releases were great for me because I no longer had to edit config files. Now, I don't know what fraction of Linux users are developers like me, but it seems like there are enough for a project like gnome to pay attention. And even if FOSS developers were only 1% of Linux users, making a majority of them unhappy is still IMO not a good idea.
I don't think anyone's really complained about gnome trying to do something that "casual Linux users" like. The problem was the part about removing a large number of features that were previously used by developers or what you might call "Old-time super-die-hard Linux users". I sincerely thought gnome had learned from (what I consider to be) its mistakes in gnome2, but it seems like gnome3 went even further. Regardless of whether you think the new directions are good or bad (and you know my opinion on this), I have so far found very few examples of software projects benefited from "starting from scratch with something new". And of course, gnome is far from being alone in what I think is best described as the CADT model.
On a different topic, I think I'll actually try an experiment with gnome3. My wife has been a "mainstream Linux user" (she mainly uses OO.o and Firefox, and would still be using Windows if it wasn't for me) for about 5 years now and has been using gnome2 all that time. I'll see what her reaction is when I expose her to gnome3 and how long it'll take her to figure out how to get things done. Any guesses based on previous studies?
Posted Aug 16, 2012 22:10 UTC (Thu) by hp (subscriber, #5220)
[Link]
As I said, the categories are oversimplified. My main point is that I think the original article shares a common misconception that the fights here are about "most current Linux users" vs. "hypothetical mainstream users." I think the fights are almost entirely among people who already care about Linux, and are using it. I think GNOME developers make most decisions with an eye to people who care about and use Linux already (especially when judged by actions and not words).
I'm not someone who had a hand in GNOME 3 so I don't know the rationales. Nor have I followed most of the flames about it, nor been immersed in Linux user feedback lately, other than myself. So I've been trying to stay out of any debates about how GNOME 3 works in specific. I don't have a lot to say other than "it works well for me" and I know I do a lot of things differently than most people.
From general knowledge I would expect that anyone switching to GNOME 3 will hit speedbumps and initially be annoyed. I'm sure your wife would be. This is the cost of any big change. Whether the change is worth it in this case requires knowledge that I don't have.
It's easy to say CADT but it's also easy to point to countless technologies that became old and stale and were crushed by newer replacements. There isn't some easy guideline, like "never" or "always" change things. "It depends."
fwiw, I know enough about the tech to tell you that GNOME 3 is not from scratch by any stretch. GNOME 1.x -> 2.x preserved a lot less code. GNOME 3 is essentially a new UI in the window manager (but keeping a lot of existing tricky WM logic from Metacity), dropping some deprecated stuff, etc. What changed is very visible but not necessarily that huge code-wise. See also http://www.joelonsoftware.com/articles/fog0000000356.html
The issue is that the pixels changed.
I'm not trying to tell anyone that GNOME 3 will definitely succeed. There are just certain arguments about it that I think are wrong.
The bottom line is that success or failure, just as with GNOME 2 or anything else, will come down to detailed judgments about specifics. The developers will have to get it right, or not.
I wouldn't venture to say whether it's on the right path, on balance, without better visibility and immersion in the strategy and the feedback. For GNOME 2 I had the daily feed of raw information, now I just have my own usage and occasionally reading an article like this one or whatever.
The GNOME project at 15
Posted Aug 16, 2012 22:33 UTC (Thu) by hp (subscriber, #5220)
[Link]
Also of course, my first post on this article says why I don't think "GNOME should learn from GNOME 2" is right. Unless you think the main goal of GNOME 2 should have been to avoid flames. GNOME 2 became much more popular than many desktops that did _not_ get flamed (as much). Taking a lesson away from GNOME 2 like "we shouldn't change stuff" or "regressions are never good" would be historically wrong, because either of those lessons would have doomed GNOME during 1.x -> 2.x. Knee-jerk "CADT bad" would have doomed GNOME too. Truly targeting mainstream users instead of Linux users would have doomed it too. There are lots of ways GNOME 2 could have gone wrong. But flames were non-fatal.
It doesn't mean that if you're getting flamed you're going to succeed, but it does mean that you _might_ be right to do something that gets you flamed. You also might _not_ be right. That's the hard part. One needs to figure it out.
The GNOME project at 15
Posted Aug 17, 2012 0:38 UTC (Fri) by jmspeex (subscriber, #51639)
[Link]
It seems like you're assuming that software cannot change without a rewrite. Just look at the Linux kernel and compare what it was at the time of 1.0 vs 3.0. The two versions have nothing in common. Yet, nobody ever started a rewrite of the kernel and the only regressions that occurred were either unintentional (i.e. bugs happen no matter what) or were about hardware stopped using 10 years earlier. It's been an evolution and that's how you keep your users happy. It took years for gnome2 to re-implement many of the features that gnome1 had. Some It's not clear to me whether these features were always meant to be re-implemented or were only re-implemented because of angry users, but the bottom line is that for gnome2, "change" resulted in several years of being stuck with something worse. Not to mention that gnome1 had stopped improving long before gnome2 was out. So far, gnome3 appears to be the same. gnome2 development slowed down long before the gnome3 release and developers are still re-implementing features that were "lost" in the rewrite (again don't know how much is from "it took time" vs "we changed our mind and re-implemented the feature").
The bottom line is that this development method (and KDE is just as guilty as gnome) leads to long periods where the software is much worse than it should be. So by "learn from gnome2" I meant "learn to avoid these long periods of regression". I now realize that "it's a feature" and that even if gnome3 ever becomes as usable for me as gnome2 was before the "rewrite", it would only be temporary because by the time it works for me, all developers will have moved to gnome4, which will break the features I use.
I especially don't see how it needs to be that way. You can implement a gnome-shell like feature on top of gnome2 and make it optional (or even by default, I don't care). You can make the wm evolve without breaking everything. And more importantly, you don't have to make all these changes at once and you don't have to ditch the old behaviour. This means 1) people have time to get used to the changes when they like it 2) there's a chance to react when you're going in the wrong direction, and 3) you avoid bad regressions.
The GNOME project at 15
Posted Aug 17, 2012 1:43 UTC (Fri) by hp (subscriber, #5220)
[Link]
It sounds good, but if it were that simple... There's something hard about it. Nobody is just trying to piss people off.
If nothing else: there are very few developers doing quite a lot.
I don't think the kernel is directly comparable; one reason is 100x more developers, but another reason is that evolving UI is a different problem from evolving code. GNOME 2 to 3 evolved the _code_ quite gradually and smoothly with no big rewrite.
I'm trying to think of examples of UIs that gradually evolved between two pretty different states like GNOME 2 and 3, and having trouble. But maybe there are some interesting ones out there. I guess Apple is currently doing some sort of make-OS-X-more-like-iOS-in-each-release thing according to the media but I haven't tried it out myself.
The GNOME project at 15
Posted Aug 17, 2012 5:44 UTC (Fri) by jmspeex (subscriber, #51639)
[Link]
I understand that developers aren't *intentionally* pissing people off and it's just a side effect of something else. Also, I understand that making code evolve isn't easy, but rewrites tend to be even worse -- even if it looks simpler because "hey now I can understand all the code". UI or not, I can't think of any project (though there may be a handful) that really benefited from a rewrite. The only viable way I can see is when you have the resources to keep maintaining the old version until the rewrite is not only released, but achieves feature parity with the (still evolving) old version. This is what Microsoft did with NT and I'm sure it wasn't cheap.
In the end, I think the problem isn't even just for users, but for developers as well. From 1999 to ~2005, I wrote and maintained an application that had a gnome front-end. All I can say is that it was a rather painful experience. The API itself was OK (except for being C rather than C++, but I could deal with that) and it didn't take too long to get something working. The real problems came with maintaining the code with ever-changing APIs. Part of that was the gnome2 transition, which not only changed how some widgets behaved (it's OK for a major release), but also completely removed some widgets (GnomeMDI for example, which was supposed to be "the right way"). Even after the transition, APIs would keep coming and going. Oh, we're no longer supposed to use the gnome canvas, there's something new instead. Need graphs? Use GtkPlot, no use Guppi, oh wait we rewrote it and Guppi2 is much better, no but Guppi3 will be... You would never know which API you could trust to not end up being deprecated in 6 months. I stopped being involved around in that project around 2005, at which point the other main developer was working on a Qt frontend. (I still work on FOSS, but fortunately I haven't have to work with GUIs since then)
The GNOME project at 15
Posted Aug 17, 2012 6:54 UTC (Fri) by hp (subscriber, #5220)
[Link]
That sort of code and API sanity (avoid giant rewrites, keep the API stable) is far, far better these days than back then.
In OSS one can only do so much. The libgnomeui/GnomeMDI stuff took a long time to reach consensus. So for example, in January 2001 I was apparently telling people not to use it: https://mail.gnome.org/archives/gnome-devel-list/2001-Jan...
But, someone else would have told you to use it at that time.
It just depended on who you asked. There wasn't a dictator to decide.