[Ksummit-2009-discuss] Meeting userspace requirements

James Bottomley James.Bottomley at HansenPartnership.com
Sun Jul 12 12:54:35 PDT 2009


On Sun, 2009-07-12 at 08:01 -0700, Dirk Hohndel wrote:
> On Sun, 12 Jul 2009 06:41:50 -0700
> James Bottomley <James.Bottomley at hansenpartnership.com> wrote:
> 
> > On Sun, 2009-07-12 at 07:29 -0400, Theodore Tso wrote:
> > > The reason why I like this taxonomy is I think it helps explain why
> > > certain ideas/request for implementations/patches get treated the way
> > > that they do, and if people understand this, then perhaps they'll
> > > understand that if they get treated a certain way, it's not because
> > > people are mean-spirited or malicious, but because we get these are
> > > the natural mechanisms which have evolved over time to filter out bad
> > > designs, bad code, and crackpots.  
> > 
> > Sure, this taxonomy will do as well.
> 
> I actually like Ted's taxonomy, especially as it explains how the
> community does not treat ideas equally or fairly at all - a big chunk
> of the likely response depends where it comes from and who speaks up
> for it. Which makes this mechanism fairly easy to manipulate.

There's an aspect of that, but there's also an aspect of "extrinsic
worth" meaning how much is the idea worth to the community at large ...
this is the one that's incredibly hard to gauge and it does govern both
traction and the building of consensus around the feature.

> > > I think it might also suggest ways that they might be able to reach
> > > out to various community members one-on-one, perhaps at a conference,
> > > or perhaps as a paid consultant (for those who don't already have
> > > full-time jobs at some Linux company), or perhaps via e-mail asking
> > > for some help and suggestions about how to push some idea, in a way
> > > that's productive and less frustrating for all concerned.
> > 
> > But both of our taxonomies miss one of the cultural impediments of LKML:
> > The desire to demonstrate worth by flaming someone to a crisp.  The
> > mechanical syntax checkers make it all to easy for someone to feel like
> > they've just been ripped to shreds in public just because they didn't
> > know we have style checkers (and the flamer did) --- with no actual
> > substantive discussion of the patch.  A lot of the time, a maintainer
> > can see what's going on and does intervene ... but they have to notice
> > first; this is where the firehose effect of LKML is most detrimental.
> 
> That's a great observation - this happens quite regularly; but how do
> we solve the problem? Is this actually a problem where the community
> behavior is wrong or is this an indication of a problem with the
> submitter / submitted code? 

It's certainly a problem with elements of the community ... but in a
system where value is defined by contribution, these aren't important
elements.  The problem tends to be that if you're new to the culture you
have no means of telling this.

> There's a ton of resources available to people who want to submit
> patches. It doesn't take much googling to find posts that tell you to
> use the syntax and style checkers. Or to simply start by reading three
> files in the Documentation directory of the Linux source. It shouldn't
> be hard to find SubmitChecklist, SubmittingDrivers and
> SubmittingPatches.
> 
> So maybe it is fair to say that someone who gets fried to a crisp over
> simple style / syntax issues hasn't really spent a lot of time preparing
> for their submission? It's not a nice way to deal with this, but it's
> effective (and I say this as someone who had it happen to him on a
> triviality...)

Heh, a true community response.  There is a definite truth to what you
say ... and absolutely people who read up on and absorb the culture fare
far better.  However, you and I both know that engineering realities
often decimate the time available to engineer to spend on cultural
absorbtion.  It's the engineer who persuades his company to take a
gamble on open source and tries to do the right thing while complying
with management deadlines who has the hardest time of this.  They're
also the most valuable to us: success here is likely a new company
converted to open source.

I can't quantify the numbers of failures above ... but I do know of
significant numbers of "near failures" which could have gone the other
way which makes me think the failure figures might be quite high.

James




More information about the Ksummit-2009-discuss mailing list