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

Rob Lanphier robla at wikimedia.org
Thu Jun 10 16:42:16 UTC 2010


On Thu, Jun 10, 2010 at 8:59 AM, Birgitte SB <birgitte_sb at yahoo.com> wrote:

> --- On Wed, 6/9/10, Rob Lanphier <robla at wikimedia.org> wrote:
> > 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.
>
> 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.


My point is that many people conflate these two relationships, and that
furthermore, the two are inextricably bound in a world of total
transparency, since its impossible to communicate to one group without the
other overhearing.  Furthermore, a "customer-vendor"-style relationship
between the larger non-technical consensus and the development community is
probably not sustainable in the world of completely transparent open source.
 It still needs to be more collaborative in nature.  The latter point is
fairly well understood when the development community is almost completely
decentralized (think Linux or Apache), but becomes muddier (but no less
true) when there is a central organization involved.

Rob


More information about the foundation-l mailing list