Free choice and constrained choices

Matt responded to my thoughts on Gnome’s approach with a discussion of the nature of choice:

Gnome is free to innovate and show the world that there are better ways of doing things, but at the same time, exercise some of their own community’s rhetoric and give people a choice. The idea that it’s okay for Gnome to deprive their users of choice over the way they use their computer, is another reason that the Linux world is annoying me at the moment…Why should it be an all or nothing decision, for a user to make? … If Gnome is the best system for a person, corporation or whatever, except that the extra training required because of the spatial approach makes it unviable, why do people have to ditch an entire, very well developed desktop environment?

The notion of choice, that you can combine different bits into a desktop of your choice, custom-built by you for you, has been the war-cry of Linux since there first was a Linux desktop. I think, though, that it’s a pipe-dream, and the quest for this pipe-dream has hurt the development of the Linux desktop beyond measure. In an ideal world, a utopia of development, we’d have open and defined standards that everyone implemented, and those standards would define how individual components could slot together to form the perfect desktop. KDE applications would work on a Gnome desktop; Gnome applications would work on a KDE desktop. Currently, they do not—while you can run them, they use different UI guidelines, different configuration databases, different inter-application RPC methods. The pipe-dream is that organisations like can define these interoperability standards and give us our utopia. But I can’t see how that’s going to happen. Let’s take the example of a KDE application which needs to interoperate perfectly with a Gnome desktop. It should, when a URL is clicked, start up the browser that the user has configured as their browser. Now, it can either ask the KDE configuration mechanism (as it currently does), it can ask the Gnome mechanism, it can ask the KDE mechanism which (under the covers) asks the Gnome mechanism, or it can ask some kind of abstraction layer which knows how to ask both the KDE and Gnome mechanisms. If the freedesktop people specify a One True Config Approach, and it’s gconf (which it looks to me like they’re gearing up to do), how likely is it that the KDE people will start using it? And that’s just “how to find a web browser“. This is why I suggested, in LugRadio episode five, that we should abandon KDE and concentrate our development work on Gnome. While the ideal of infinitely-pluggable desktop components would be great, I really can’t see it ever happening. To put it another way, if KDE applications and Gnome applications and non-desktop-integrated-applications all work the same way, to the same UI guidelines, using the same configuration databases and the same RPC technology, haven’t we then essentially created one desktop environment anyway?
Further, Jono has also weighed in on the debate with some ideas on Gnome’s status as a framework:

GNOME is not written to be installed by the regular Joe – it is intended as a framework that distributors assemble to target their audience. This may mean tweaking the magic GConf key and turning the spatial Nautilus off, but that is the choice of the distributor…This is an area where GNOME and KDE are distinctly different – the GNOME guys are pushing for real and different innovative features, whereas the KDE folks are simply taking any feature and providing an off switch in the Control Center. I would love to see KDE become more framework orientated such as GNOME…The greatest sound engineers never add more bass/mid/treble to a sound, they simply take the other frequencies out.

I’m not sure that I view Gnome as a framework in quite the way Jono is describing, but I’m in wholehearted agreement about Gnome’s innovative approach as opposed to (an apparent) stagnation in KDE.
I can’t imagine how a preference to turn on and turn off the spatial Nautilus, as an example, would be anything other than confusing. (I appreciate that Matt isn’t talking about this specific example but more the general problem, but the point still stands.) Where would such a preference be? It would be confusing if you don’t know what it means, and it would encourage people to turn it off without trying it. Jono himself has been complimentary about the spatial Nautilus, suggesting off-line that he didn’t think it would be a good idea but has since found it to be a better system. This all boils down to the problem: if you know better than the users, how much do you enforce that? If you enforce it too much, then you’re restricting choice, and god help you if you’re wrong. If you don’t enforce it enough, then you’re missing a chance to really help your users even though they don’t know that they need help.

I'm currently available for hire, to help you plan, architect, and build new systems, and for technical writing and articles. You can take a look at some projects I've worked on and some of my writing. If you'd like to talk about your upcoming project, do get in touch.

More in the discussion (powered by webmentions)

  • (no mentions, yet.)