[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Fundamental KDE Library Problem..
From:       Andreas Pour <pour () mieterra ! com>
Date:       2002-07-04 14:30:14
[Download RAW message or body]

John Gluck wrote:
> 
> Hi
> 
> All the old stuff repeats a nauseam...

Hi,

Being not a developer, but having spent years on the lists and seeing
these dynamics repeated, I have a different (if, IMHO, more enlightened)
view of this process.

> 1- Suggestion = complaint.

This really is a gross misconception, particularly inapt for the current
"suggestion", to wit, that an OSS project stop being OSS and become a
commercial project where someone imposes some blueprint and then some
volunteer army implements it out of their love of following orders.

This "interpretation" - presumably genuinely felt, though perhaps
another tool of manipulation in the toolbox of those making
"suggestions" - flows often from people who, not actually doing any work
themselves, have a better idea of what others should do.  And they are
quite sure it's better.  So they do not just make a suggestion, but what
I term an "incendiary suggestion" b/c it tends to rub almost everyone
the wrong way.  Namely, the follow up their "suggestion" with some
comment like "do this, or KDE will lose" or "do this or I will use
GNOME" or any of a repertoire of oft-repeated "threats", insults, or
other unpleasant ways to try to force implementation of the
"suggestion". Or there is sometimes another tact, which is to pester, by
repeating the suggestion over and over again, at which point, again, it
becomes a demand.

I have yet, perhaps a few exceptions I have forgotten aside, to see a
developer react negatively to a true suggestion, as opposed to a demand
or troll or flame.

But what you term "suggestion" realy is, in essence, an unreasonable
demand, insult, troll or flame, and, human nature being what it is, this
elicits a defenseive or negative response.  Sure, it would be nice if
developers had ideal emotions and never got annoyed, but then, there are
far bigger problems in the world I would like to see solved.

> 2- You don't like it = you fix it. (really just another incarnation of #1)

Typically this happens when the writer goes beyond the suggestion or
request phase.  At other times, it is a valid response, as the developer
is saying, I don't want to implement this, but if you send a patch, I
would be happy to apply it.  So rather than seeing this as a total diss,
I see this as an offer to cooperate - after all, there are quite a few
projects, and developers, that don't accept patches.

My hope for developers is, that they do consider ueer suggestions, and
if it turns out that a suggstion is very popular, implement it, if
reasonable to do within the framework of the development environment,
the interests of other users, and the time available.

What's interesting it that, at a time when KDE is already being attacked
for being bloated, it gets equally attacked when not every suggestion is
implemented.  You can even find some unscrupolous articles criticizing
KDE for being bloated yet *and* for not including an entire library
which only this one whiner wants, all in the very same article!

> 3- We do this as a hobby = we don't want to learn about better ways.

This is exactly the kind of flame / insult / rude commment I was
referring to.  Look at how loaded this statement is.  "Better ways" -
you assume your way is better, but where is your OSS software project to
prove it?  Even with a way to prove it, the KDE development community
has developed over years into doing things a certain way, and the people
who do the development, like it that way.  So maybe you can come up with
a better process, but if nobody working on KDE wants to do work on KDE
using this process.  Then, what makes this new process "better"?  (Yes,
yes, I know, anyone who would not use their free time to implement an
idea which hypothetically may be better but certainly would stop the joy
in working on the project should be shot, and, yes, yes, I know, anyone
not wanting to take the risk of destroying an entire very successfuly
development community for the sake of seeing if in fact this other
methodology is better is a coward.)

The second flame in this "suggestion" - as you seem to view it - is "we
don't want to learn".  Quite contraire, people who don't want to learn,
would not be working on OSS projects - rather, they would be watching
TV, or be armchair devleopers like the ones making the "suggestions". 
In reality, OSS development is mostly about learning things and is done
by people who love to "tinker" - take things apart, put them back
together, see how they work inside - in short, by people who have a vast
intellectual curiosity.  The people working on KOffice, for example,
have, AFAIK never written an office suite before, and I am sure, they
have learned a lot in the process, and went into it, knowing they would
have to learn a lot.

The misunderstanding often arises b/c the person making "suggestions"
does not bother trying to learn anything about the community being
addressed.  One day, they pop up on a mailing list, and proceed to say,
"What you have been doing for years, with this highly successful
project, is all wrong, listen to me, you little children, *I*, who have
nothing to show for my skills, know how to do it better, and this is how
you should do things, and if you don't listen to me, KDE will fail,
fail, fail."  Pretty much, that is how a lot of these posts come across.

And then when the "suggestion" is not fully embraced, the litany of
complaints follow - you don't listen to users, you don't want to
"learn", etc.  Even as a non-developer, not addressed by these comments,
it is a heavy load and makes me very uncomfortable.  To me, the people
making the suggestion may very well have good intentions, but, when they
won't take no for an answer, they become dead weight, sapping energy
from the community.

So, in short, I attribute most of the problem to the fact that the
people making the suggestions lack communication skills and, most
importantly, lack any real understanding of teamwork, particularly
teamwork in an environment of purely voluntary association.  And they
also have unreasonable demands for the moral character of others - they
demand that developers work purely to make the suggestor happy, that the
developer's own happiness is a distant second to the happiness of the
person making the "suggestion".  So, you tell me, who is being
childish?  (To be clear, I am not talking about all suggestions here, I
am talking throughout about "suggestions" - in quotes.)

As an aside, this sort of miscommunication comes not only from people
new to Open Source, but people who are quite steeped in it.  Not too
long ago, there was a long discussion on kde-cafe, perhaps trickling
over from koffice-devel, where some rather well-known Open Source
personalities made "suggestions" about KOffice filters.  But these
people, who should really know better, went *way beyond* making
suggestions.  As my first comment in the thread was, it is abundantly
obvious to everyone who has a brain - and yes, KOffice developers have
brains - that filters are needed.  So the suggestion was not really
useful, but still, had it remained a suggestion, fine.

But the problem was, it did not remain a suggestion.  It kept being
repeated, and repeated, and developers told, as per my generalization
above, that KOffice is "worthless" without filters, that the developers
"don't care" about users, etc.  It was quickly apparent that this was
not a "suggestion", but rather a string of "demands" and, albeit
probably not intentional, insults, all designed to whip someone to do
what the "user" wanted them to do.  Demands that the people working on
the GUI, or whatever else interested them, turn instead to writing
filters, as if the skills involved in both cases were fungible and as if
the motivation needed to work on either project were the same and as if
anyone has the right to demand anything of anyone, particularly someone
who already is doing us all a great favor by using their free time in
such a productive manner (think about that, next time you are watching
TV and not contributing your time in a way others benefit from).

So this, in essence, is the disconnect.  You might want to term
something a friendly suggestion, but, in reality, it frequently - and
almost always when the response is negative - is not.  Rather, in my
formidable experience of many years of reading these exchanges, it is a
demand met with flames and insults when not carried out, similar to the
insults you levy here, merely b/c a "suggestion", as you call it, was
not carried out.

> 4- You get what you paid for = I really really don't want to listen. Or if you \
> don't want to stroke my childish ego then go away and don't bug.

Another clear exmple of where a "suggestion", not heeded, becomes an
insult and flame.  This one sentence actually contains 3 falsehoods,
insults and flames.

(1) "don't want to listen" - well, with this kind of stuff you write, I
would not be surprised if nobody wants to listen to that, as it's really
just flaming b/c someone did not implement s "suggestion", as you choose
to call it.  But, having read the thread, people did listen, and not
only listened, but took the time to respond, in some cases multiple
times.  B/c you did not like the response, you make a false claim, that
nobody "listened".  So this is flagrant lie number 1.

(2) and (3).  "childish ego", "stroke me", etc.  These comments
represent a destructive, negative attitude, really, and unfortunately
one the developers have to put up with time and time again.  I think
these words apply more aptly to the author, then the people it is
directed against.

> 5- there are many newbies = What is junk will stay junk. Don't try to mentor these \
> people, they won't listen.

Not even sure what this means, but, it does quit clearly sound like
another helping of flames.

[ ... ]

Ciao,

Dre
 
> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic