--- On Wed, 6/9/10, Rob Lanphier robla@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