[KimDaBa] LWN & Grand Plans
ekj at zet.no
Mon Apr 25 08:35:14 CEST 2005
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
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,
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.)
More information about the KimDaBa