As a user of free and open source software, I have a deep respect for all projects that work hard to produce free software. As a member of this community, I also feel that it is my responsibility to let these projects know when there is a bug or problem with the software; constructive criticism is often one of the biggest gifts you can give to a project, after all, we won’t get anywhere if we keep telling ourselves how great we are. The purpose of this essay is to discuss a theoretical problem that has always faced free software, and is now beginning to materialise in some projects. The problem is that of refining our technology.
Contributors are the backbone of our community. We need hackers, documentation writers, sound engineers, usability testers, expo organisers, advocates and other generous participants. Without these people contributing, we would have no software, or we would have software that is significantly less feature laden and stable than we have now. The problem we are facing though is that every contributor who is getting involved with a free software project is essentially using their spare time and hard work to “scratch their own itch” and contribute the scratch to the project in question. This is not a problem per say, but the problem lies in the fact that not every personal contribution can be merged into the project. As an example, if someone wanted the clock in KDE/GNOME to be displayed in binary, they could write a patch and submit it to these projects. The patch may then be merged and added if it is good. Irrespective of the fact that 95% of the user-base may never use the feature, a patch is often rated on its technical quality and compliance; if it meets the grade it is often added.
We have a difficult decision to make here. Someone has contributed a patch that they have spent their time and effort creating, but the patch adds a feature that may detract from the general direction that the project is heading in. Do you allow the patch and possibly bloat the project up unnecessarily, or do you say no and possibly alienate a contributor? It is a difficult decision to make, and there is no clear option either way. One alternative is providing some kind of additional plugin system where these additional features can be added. This has occurred with various projects to a relative degree of success.
I think the most important aspect of running a free software project is having a sense of direction. Let us take GnomeMeeting as an example. It is quite clear from the direction of this project that there is a very definite and finite direction that the developers are pushing for. GnomeMeeting is aimed at being a light, easy to use, voice over IP application that allows you to talk with your friends and colleagues. In my experience of keeping a beady eye on the project, it seems that the direction has been rigorously followed. The result of this work is an application that is simple and easy to use.
Many would say that GnomeMeeting is a simple example; it has a fairly singular set of requirements and aims. Things get considerably more difficult to manage when you look at more expansive software projects such as KDE and GNOME. I have been involved with KDE to varying degrees over the past four or five years and I love the desktop and greatly admire the people who work on it. The one criticism I do have though is that the sense of direction in KDE seems to be flagging somewhat. As someone who cares about the direction of the project, it seems only right to share these views. The reason why I am writing this in my O’Reilly blog and not in a private email to the KDE developers is that I think some of these points can be heeded by other projects. These points are not only directed at KDE; various other projects may find this essay interesting.
The problem I have seen with KDE recently has been an overload of features that I suspect the target audience will not need. The term target audience is always an interesting concept to get clear in your head, and this concept gets considerably more difficult when you take into account the vast range of users that KDE has amassed. The problem with a project such as KDE and GNOME is that they are essentially trying to please all the users all of the time. These projects want to please those who want a simple to use desktop, those who want to configure everything imaginable, those who want to remove chunks of the desktop and many other weird and wonderful uses. The problem is that you really cannot please everyone all of the time.
Let me share an example. My dad is a Windows user. He needs his computer to write letters in Word, browse the Internet in Mozilla (I moved him over to Firefox, OpenOffice.org is next) and that is about it. My dad is very much a task-centric user. The OS and GUI to him is of unimportance; it is all strange magic that eventually gets him to the point where he is sat in front of Word - this is where he feels comfortable. The Windows control center scares him, he doesn’t like options boxes, he doesn’t care about themes - options are just things that may possibly break the system.
My dad is the kind of audience that I expect KDE to target. He is a novice computer user who just expects things to work. He doesn’t care about half of the stuff that is present in KDE; he only needs the GUI to be able to manage his files and load his programs. The problem is that KDE is getting so feature laden that it is making the environment more complex to use. If I sat my dad in front of the KDE Control Center, I think he would give up straight away. The problem is not so much the way the KDE Control Center is designed; the tree topology works reasonably well, the problem is the sheer amount of stuff in there.
In some ways the GConf concept is a good one. Some features in GNOME may be so specific and advanced that the vast majority of people will not need to fiddle with them. The most common and basic options are available in the general configuration tools, but the more specific options are essentially stuffed somewhere in the background out of view. This is great because the target audience does not see them and is therefore not confused by them. The problem with this technique though is that you need to know obscure GConf keys to get lesser known options to work.
I feel the best option in a situation like this is to make the desktop and configuration available in a series of schemas. You could have an Easy schema that has the most common options available and removes choices that may be too advanced or are not needed by someone such as my dad. You can then have a Medium schema that satisfies those with a tweaking finger. The final option could be All, which is the current situation. The desktop would start initially in the Easy schema and if you need more options you simply change the schema. There should also be functionality to add and remove options and features from your chosen schema. This gives you the ability to tweak your desktop in the way you desire. As an example, if you don’t use Konqueror, you should be able to remove its options from your schema.
This is by no means a perfect scheme and would need to be refined by people with some concrete usability experience, but this would at least improve the situation to make the desktop work in a way that is better aligned with the needs and experience of the user. The more advanced user can always make an easy desktop more advanced, but the less advanced user simply gets lost with an advanced desktop.
Just to re-iterate, I have a great deal of respect for the KDE and GNOME teams. I know many developers personally, and these comments are intended to hopefully make people think of another way of making things work. We are getting to a point with our software where the desktop is going to play a key and integral part to new users and businesses. This means not only refining the technology that we already have, but working together to meet the goals and ambitions of desktop integration with the freedesktop.org project.
Sensible suggestions or random utterings? Chalk your thoughts below…