Fwd: Re: Application duplication (was: Re: cdbakeoven)

Marc Mutz Marc.Mutz at uni-bielefeld.de
Sat Apr 20 12:54:17 BST 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 20 April 2002 11:52, Ralf Nolden wrote:
<snip>
> Mom only wants to write a
> receipe and she doesn't care even for shortcut configuration.

Just because Windows dumbed down users to the point that they can't even 
browse the web without a help wizard doesn't mean we should do the same.

GUIs are not there to make dumbed down programs but to make programs easier to 
learn - in the ideal world, without reading the handbook.

> But as other
> people do, we offer the functionality in editors and much more to satisfy
> the 10% of the potential users who could ever make use of that, which is
> correct. The best tool for the users, please, but only one for each task.

Sorry, I have to disagree.

Free software is also about choice.
Unix and particularly Linux have always been about choice. Forcing one program 
on the user is just what Windows does. Let the user decide what she wants to 
use. There's improvement possible in the way that the different programs 
doing essentially one task are presented to the user, but "fixing" this by 
throwing away the choice is the wrong way. Many people really hate windows 
because it doesn't let them do what they want to do.

I understand that the "power user" can always go to apps.kde.org and fetch 
another package. But the fact is that most people don't bother, nonetheless 
they explore their new system thoroughly. They try various screensavers and 
stick with the one they like best. They try various browsers and stick with 
the one they like best (or use them interchangeably). Forcing a particular 
selection of apps without intersection in functionality just dumbs users down 
to the point of accepting what they are presented.

Another point is: You _can't_ really steer free software developers. Some try 
it, some even succeed. But KDE has always been a project where there was _no_ 
steering at the top level. I think we agree that it should stay like this. 
But that means that you simply cannot prevent the random developer from 
writing the 20th irc frontend. If you want to persuade developers to work on 
the included apps, then probably the 20th irc forntend will not be written. 
But it's questionable at best whether the particular developer then stays 
with KDE.

I agree that having four CD burning programs in the distribution is ugly. But 
that's an extreme and they're there to fight for the favour of the users, 
AFAIU. One or two will win. Keep them. The rest goes back to where they came 
from. There will never be new, groundbreaking concepts developed if there is 
no prospect of inclusion into KDE proper.

A good example is the treemap widget. It now more or less vegetates outside of 
KDE CVS and no-one makes use of it. There are many scenarios where such a 
intuitive visualization tool could come in handy (not the least of which is 
Konqueror), but because it was decided that it's not going to be in KDElibs, 
since it was considered too special, these use cases are not exploited. This 
serves as an example of the fact that if an app isn't in KDE CVS, it's never 
going to accumulate more than a tiny share of users.

To summarize:
- - Reducing choice dumbs down the user to the state of consumers.
- - If you lift the barrier for inclusion into KDE CVS, we will loose 
  developers. But we need _more_ of them, not less.

Marc

- -- 
Marc Mutz <mutz at kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8wVbp3oWD+L2/6DgRAtp7AKCSSz4FUPSGuRJOctTkDG4Wu3pVPwCgmCp+
CnWw/Pb1avhsZuFcUUUSr5o=
=dn9K
-----END PGP SIGNATURE-----





More information about the kde-core-devel mailing list