On Thu, Jun 10, 2010 at 8:59 AM, Birgitte SB <birgitte_sb(a)yahoo.com> wrote:
--- On Wed, 6/9/10, Rob Lanphier
<robla(a)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