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