Linux for the rest of us.

The View from the Desktop

Two Sides of Open Source Development

I'd planned to write this week on a different subject, but events, typified by the experience of Cathy Raymond and the KDE developers, as well as some of my own experiences, suggest a general theme that might just as well now be adressed.

Over the last few weeks I've been involved in a long and occasionally heated exchange with the KMail developers over the address book format used in KMail as it will be shipped with KDE3.

From the earliest days of KDE, KMail's native address book has been the flattest of flat files: text, one address per line, separated by carriage returns. If you wanted to specify a name in association with an address, you could, but it wasn't required. If you wanted to create custom lists, so that messages would go to groups of people, you simply separated them by commas, with a carriage return at the end. You could edit the address book in any text editor (though if you had long entries, you needed to turn off wordwrap).

No longer. Addresses are now to be handled by a separate application. And what used to be "name <[email protected]>" has become this:

BEGIN:VCARD
VERSION:3.0
UID:c2pKpRkKW
FN:Name
EMAIL:[email protected]
N:Name;;;;
END:VCARD

(It no longer lives in ~/.kde/share/apps/kmail/addressbook, either; it's now ~/.kde/share/apps/kabc/std.vcf.)

It's worse. Some email addresses are just that: email addresses. There is nothing else to be said about them. That's because they aren't persons, they're something else. The original addressbook was perfectly suited for this kind of thing -- companies, mailing lists -- and the new one isn't.

The argument is that the VCard format is standard, while a text file is not. This is nonsense -- text files are always in good taste. The other argument, which does have some merit, is that this allows people who want to keep all sorts of other contact information -- addresses, phone numbers, astrological sign, whatever -- in one place, where applications such as KOrganizer can have at it. That's all well and good for those who want it. Some of us don't. But the old format has now been abandoned entirely. There is talk of tools to import existing KMail address books, and perhaps of a means of causing kmail to act as if nothing has changed (now, when you seek to save an email address in the KDE3 beta's KMail, you're given the whole KAddressbook application). But those who favor the gorgeous and entirely Linux-like simplicity of the initial addressbook are being sent to pound sand. And using a text editor to add to, modify, or recover one of the new address books? Impossible, or at least as close to it as trying to create an MS Word document in a text editor.

Which means that as soon as KDE3 is released, I'll be diving into the KMail source and doing everything I can to try to change it back for use here. I have no idea if I'll succeed, but I certainly intend to make the attempt. Yes, that's the strength of open source. But the fact that it needs to be done at all bodes ill, in my opinion, for the direction of some open source projects and the idea of doing whatever popped into one's mind rather than concentrating on design, backward compatability, and some of the other things that brought us to Linux in the first place.

KMail's developers have expressed the situation in several ways. From their public email messages:

"I don't think that the vast majoriy of less experienced users will be so happy making this choice for themselves."

(Translation: We're expecting a flood of dimwits who have fast machines. You know -- the same problem the developers in Redmond faced when setting the default Outlook settings that have brought us so much entertainment.)

"But most of the KDE users also want to store more information about some people. They would have to store the email addresses in two different places (in KMail's proprietary email addressbook and in KDE's central addressbook). This is ugly and contradicts the integration between the KDE applications. Therefore KMail's proprietary addressbook had to die."

(Translation: We imagine that most KDE users want this, and in any case we have this grand design that is more important than usability is. You know -- the grand design that lets KOffice import Word files to be edited, but not export them.)

"We, the KMail developers, made this decision in full consensus. It's very sad that you think we wouldn't care about the users."

(Translation: We talked to each other and decided what users want. You, a mere user, have no idea what you want, faced with the powerful result of a conversation we had among ourselves.)

And so on.

What makes the KMail developers' intransigence in this case so ridiculous is that no one is asking the KMail developers to come up with anything new, nor is anyone asking them to get rid of something that they find innovative and good. Yett they cling to the notion of getting rid of something which already exists and which some people find far preferable to the alternatives.

I was prepared to say that this phenomenon appeared elsewhere, too. I'm thinking of the KWord html export filter. But in its case a responsive developer went to extra lengths to provide the existing functionality in addition to the new things he's added in the KOffice CVS tree.

Word processors -- not just KWord -- love to load html exports with all kinds of stuff that often is not needed, especially if one is interested in exploiting html as a document transfer format. In the current release version of KWord -- 1.1.1 -- html export offers what amounts to a stripped choice, without formatting. I would love it if attributes such as bold and italic were preserved, but I'd do without them if getting them requires the alternative as presented in the current CVS KWord. Using it, a 20k textfile grows to 32k (in one example here) because each paragraph is preceded by the likes of this:

Now. of all that, the following is actually required: <p>. And in the current KWord, it is possible to use the format-less option and get little more than that. But this choice was gone in the KWord that is being developed against Qt-3 for use with KDE3. And again, I thought some hacking would be required not to achieve new functionality but merely to keep that which already exists.

I sent a note to the koffice-devel mailing list. I do not have posting privileges there, but it was approved by the moderator. In short order the KWord html export filter maintainer, Nicolas Goutte, responded, giving a full description of how the filter works and describing the features he could perhaps disable to provide a pared-down html export. We discussed it a little and he decided that a user-selectable "strict" mode, which would preserve attribute formatting -- bold, italic -- without the other stuff, which is actually an improvement on the stripped version offered in the current KWord. And less than a day later came news that Nicolas had split the filter to offer the stripped mode -- that the work had been done and was now ready for testing. I was amazed and delighted. This is the kind of response one used to get from lone developers on little projects. It is not, sadly, what one can usually expect (see above) from developers involved in great big projects.

And it provides functionality that in what I do is necessary, meaning that I'll be able to stick with KWord for a long time.

I've used KMail longer than I've ever used any other mail client; I began with it the day KDE-1.0 was released almost four years ago. For the first time, unless my hacking is successful, I'll seriously consider the alternatives.

This might well seem as if I'm making mountains out of molehills, and for those who have fast machines with huge drives and oodles of memory and who want GUIs to do everything for them no doubt I am. But there do exist in the world people who do not have the means to upgrade their computers every year or two, or even to buy more memory or a bigger drive, as inexpensive as those things have become to those of us who are relatively affluent. There exist in the world motherboards that max out at 64 megs of memory, because they do not have Tag SRAM support for more. Such persons and organizations have found Linux the obvious choice in the past, because it doesn't cost much to get and because its performance on low-end machines has been very good. But now we're leaving them behind. It might not seem a big deal to fire up a whole other application just to save an email address, or increasing the storage needed in the process. But that is not the only valid point of view. (Nor does it seem to many of us, in this day of cheap broadband, much concern to double the size of a file. But not everyone has fast connections, and in some places access costs are based on bytes transferred, and in those places it does matter. Fortunately, html exports from KWord will no longer be festooned with that kind of surplusage.)

My point is not that we should stop adding new features, but rather that we should stop automatically deprecating the old ones, which in many cases were more efficient. We're pricing whole countries out of Linux, not because Linux costs a lot but because it requires increasingly sophisticated hardware just to make it run. To say nothing of those who prefer to decide themselves to spend their resources on things they use, rather than increasingly resource-hungry applications that provide no additional functionality -- and if you do not use the new features in, say, the new address book in KMail, you have gained no functionality.

We've long been concerned with commercial, closed-source developers deciding for us the things that we want. In Linux, we have access to the source, but for most users that means little, because most Linux users are not programmers. As projects grow, the kind of developer-user relationship that once existed becomes diluted, and we risk being governed not by decisions made in a corporation but, just as bad, by a defacto technocracy.

It need not be that way, but it's something that will come to pass unless everyone is careful to avoid it.

As delighted as I am with the KWord html filter, I very much fear that the future more follows the KMail model. Which is a pity.

Posted 20 March 2002

News

Features

Guest Essay

Technicalia

Security

Community

Commentary

Home

The View from the Desktop

Two Sides of Open Source Development