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