[Foundation-l] Community, collaboration, and cognitive biases

[Birgitte SB]

--- On Wed, 6/9/10, Rob Lanphier <robla at wikimedia.org> wrote:


> 
> One undertone that I've witnessed everywhere is that people
> in open source
> communities that have a clear organizational "owner" is
> that there is a very
> uneven distribution of people who want a peer-to-peer
> relationship versus a
> customer-vendor relationship.  This makes it really
> difficult to work out in
> the public, because some people seem to prefer the
> trappings of a
> peer-to-peer relationship (let me in on your early
> thinking, publish your
> roadmaps, work in the fishbowl), where others prefer the
> trappings of the
> customer-vendor relationship (the customer is always right,
> the customer is
> the boss).  Some will even go so far as to want a
> customer-to-peer
> relationship, which is clearly not sustainable.  To be
> really clear here,
> most of my impressions on this topic come from my previous
> work experience
> (been doing the corporate open source thing for a while),
> and only in a
> limited way with this community, but I've seen hints that
> the
> WMF<=>community relationship has some of the same
> traits.
> 
> From the vantage point of the "vendor" in this case, the
> problem is
> compounded by the cognitive bias Erik pointed to (belief
> that the group
> you're a member of is diverse, whereas other groups are
> not).  The net
> result of different expectations in the community is that,
> from the vendor
> point of viewer, it looks like the community is demanding a
> customer-to-peer
> relationship, since that is the "average" opinion of a
> pretty large and
> diverse group.  That's why I'm generally pretty
> careful about using the term
> "the community", because for those not used to working out
> in the open, it's
> really scary to get mixed up in public conversations.
> 
> One thing to consider about the IBM example is that IBM is
> a company of
> about 400,000 employees, and was probably in the middle of
> their "we're
> spending $1 billion/year on Linux" year when they
> instituted that policy.
>  They could probably stand to be a little inefficient in
> the name of
> insinuating themselves in the community.  We're not
> working with that sort
> of cushion.
> 
> As someone who currently works from Seattle (and worked on
> a distributed
> team in my last job), I also know that long distance
> collaboration (even in
> the same timezone as SF) has its disadvantages from an
> efficiency
> perspective.  Most people have a strong preference for
> face-to-face
> communication for collaboration for good reason...it's high
> bandwidth.  Even
> people who are really good at doing it take some time to
> figure out how to
> be effective using only email and IRC; forcing people who
> aren't good at it
> is really a productivity hit.
> 
> My recommendation is to strive to make it incredibly
> compelling for WMF
> staff to work out in the community.  That means
> adhering to WP:BITE and
> WP:GOODFAITH in spades, and reminding each other that we're
> all on the same
> team here.  It means making sure that it actually
> feels like it's increasing
> our productivity to do it, rather than feeling like a
> drag.  That's not to
> say the burden needs to be solely on you all, but I think
> "forcing"
> employees to work in the community is some customer-vendor
> thinking at play.
> 
> Don't get me wrong: I think it's an incredibly good idea
> for us to figure
> out how to all work together better, and clearly a big part
> of that is going
> to be strengthening our working relationship with
> non-employees.  It wasn't
> that long ago I was a non-employee Wikipedian, and may be
> one again soon.  I
> share your goal.  We have an amazingly diverse
> community with (very
> importantly) a fantastic volunteer work ethic, and I think
> we should be able
> to figure this out.

I think you are conflating two very seperate issues here.  There is a peer-to-peer relationship between developers (staff and volunteer) and a customer-vendor relationship between the larger non-technical consensus that is formed and developers (both staff and volunteer). Although I don't think I would describe it as "the customer is always right"; technical vetos by developers are common. The suggestion here is to eliminate the barriers between two groups of developers.  There will always be some kind of barrier between the largely non-technical community and developers.  There are a alot of rough edges to that customer-vendor relationship, but the volunteer developers have had alot of experience with the pitfalls there and can help staff developers navigate them.

Birgitte SB