[KimDaBa] LWN & Grand Plans

[Eivind]

On Sunday 24 April 2005 15:34, jedd wrote:

>  But it's often the case with reviews - while looking for this article
>  on the lwn.net site I found the same reviewer's article about various
>  email clients.  Some untruths mixed up with subjective assessment,
>  wrapped up in a non-standard set of criteria between each of the
>  products being reviewed.  Writing a comparative review is very
>  difficult, and obviously exceeds the skill-set of most people out
>  there who like to crap on about GNU/Linux stuff for a living.

I'm sorry -- but this is highly offensive.

Corbet has been writing about Linux and Open Source pretty much fulltime 
for the last decade, for Lwn since its inception in autumn 1997. 

He is well-informed, thorough, open for critique, very positive of the 
ideals behind Open Source and, ontop of that, runs one of the (imho) 
better online linux-magazines on a shoestring and a truckload of 
enthusiasm.

In other words: If you can't convince him, you won't be able to convince 
any *other* journalists. It is unwarranted to call what he does for a 
living "crap". Attacking people who write something you don't agree 100% 
with is not an effective way to win friends. Yes -- point out his 
mistakes. (I did, and many more did), but don't resort to personal attacks 
like "obviously exceeds the skill-set".

Yes. He missed several fundamental advantages of Kimdaba. (and quite 
possibly so for the others too). On the other hand, I think that his 
review is a lot *more* thorough than the review of a random user looking 
for an image-cataloging-app would be. In other words: Many (if not most) 
of our potential users would come away from a short test-fligth of Kimdaba 
with the same ideas he did.

What can we do about it ?

* Documentation. What we have is good, but we could always use more. In 
particular, we could need a feature-list for the new user. A "why select 
Kimdaba ?" kind of document.

* User-interface work. There are some functions in Kimdaba that are 
non-inituitive. For-example, Corbet is (imho) correct in pointing out that 
a print-function that exists trough a plugin nevertheless would better 
appear in "File/Print" rather than "Plugins/Images/Print", the first 
Location *is* where "Print" normally lives. Perhaps the rigth solution for 
this is for kipi-plugins interface to be extended so that plugins can 
somehow indicate where they would want to live in the menus ?

* Write our own Articles about Kimdaba. Havoc is working on this. Anyone 
else that feels Kimdaba deserves more positive articles in the press, 
could too.


Attacking people who choose to testdrive Kimdaba and write about their 
experiences is not the way to go -- not even if the testdrivers appear not 
to have a drivers license. (which ain't the case for Corbet in any case.)


Sincerely,
		Eivind Kjørstad