Jason Stubbs wrote:
1) There is a fairly clear chain of command.
I've seen a few people make this kind of comment recently, and I'm never
sure whether they mean it as it sounds or not.
There isn't really a chain of command, since there isn't really anything
being commanded. There is no developer community membership like we
have, there are no policies set out, etc. There is no silencing of
people, or controlling of others actions, or forced unsubscriptions
(apart from for problems with the email system).
What I think people mean to say is that for the major subsystems, there
is a fairly clear structure to the technical contribution flow and the
review process. But there is also a huge amount of code which is not
'maintained' in this way, where the only realistic patch-target is
Andrew Morton, the lead maintainer of the whole kernel.
But in my opinion this structure doesn't really relate to the flaming.
2) Each technical area usually has a clear authority - ie. a spokesman whom is
listened to and usually has one's posts challenged with clear respect.
I don't really understand how this relates to the question why linux
kernel flamewars don't appear to harm the kernel community in the way
that gentoo-dev flamewars appear to harm the Gentoo community.
Here are my thoughts, and I think there are several answers here:
Firstly, in some ways, flaming there does harm the kernel community in
the way that flame wars harm Gentoo. For example, the media frequently
misinterpret those discussions and misreport on them. Users with little
or no technical background suddenly decide they are qualified to make
judgement on technical decisions and blog about stuff, write angry
emails to LKML or the developers directly, etc. One example that springs
to mind was from one of the udev/devfs wars, and Rusty Russell's amusing
response which really highlights the way that some people make judgement
without having justifiable involvement.
http://lkml.org/lkml/2003/12/23/307
Another answer: the flamewars don't matter because a lot of the time,
the people involved do not really fit into the community anyway. For
example, Hans Reiser and reiser4. The development community is heavily
built around technical excellence, but Hans repeatedly argued that
despite breaking half the rules in the book, his code should be included
REGARDLESS since it's obviously absolutely necessary in order to take
Linux to the next level. Hans also managed to start some heated
discussions by aggressively responding to mails which were purely fair
technical review of reiser4. It took a long long time for reiser4 to
reach anywhere near mainline and it's still a fair distance away.
I also feel that the community is more mature, in that people truly with
a grasp on the community generally do not get involved with the heated
discussions when they go beyond the point of technical review. By this I
mean simply: people don't have the apparent urge to respond to mails in
the way that people do here -- kernel developers don't seem to take bait
from trolls.
In general threads also seem to stay on topic more than they do here as
well. Steve Long's initial reply to the thread here didn't add anything
to the discussion Grant was trying to start, and he even admitted so!
I'd say on the LKML replies like this generally don't happen, or if they
do, they get 0 responses.
Another factor: think about the level of ratio of developers to users on
both lists. Even if most posts here are by developers, there are a
comparatively large number of non-developer readers, plus the
discussions make good reading material linked from the GWN and forums etc.
Now look at the LKML. It's often hard to find general discussion behind
the truckloads of patches and river of technical review emails. A large
proportion of the content is not "understandable" unless you have a good
knowledge of C, operating systems, and the technical area in question.
This isn't a place that users hang out, users dont really read it
either, and you need to be a decent developer to get involved in the
first place.
Daniel
--
[email protected] mailing list
