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

[Aryeh Gregor]

On Wed, Jun 9, 2010 at 8:46 PM, Rob Lanphier <robla at wikimedia.org> wrote:
> As you know, any time you want to compel someone to do something, there's
> always the carrot and the stick.  One thing I don't like about the way
> you've phrased that is that is that you seem to be advocating the stick.  Am
> I reading that right?

I'm not clear what you're asking in practice.  I don't think Wikimedia
should be penalizing people for not making enough wikitech-l posts per
week or anything, no.  I do think it's reasonable for it to make
organizational decisions, like what sort of communication fora are
used for developing its software.  I also think it's reasonable for it
to ask its paid employees to try to treat volunteers similarly to paid
people: ask that they try to respond when intelligent questions are
raised, maybe review patches, that kind of thing.  Some people don't
do well in community-oriented jobs, and that's fine; there are an
enormous number of non-community-based development jobs available at
other organizations.

> 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).

Are you talking about people paid by the organization, or volunteers,
or users?  As far as I've seen, the users and volunteers here
overwhelmingly prefer a more peer-to-peer approach.  If someone
applies for a job at the Wikimedia Foundation, on the other hand, they
should expect to be dealing with the community on a day-to-day basis,
and shouldn't apply if they don't want to do that.  Every development
job I can find at
<http://wikimediafoundation.org/wiki/Special:PrefixIndex/Job_openings>
has "You must be comfortable in a highly collaborative,
consensus-oriented environment" as a requirement.

> 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.

Is vendor-to-customer development more efficient than peer-to-peer in
the end?  A lot of open-source projects (e.g., Firefox) have as many
features as their closed-source counterparts, on a much smaller
budget.  And of course, Wikipedia managed to become awfully large on a
tiny budget, based almost exclusively on community (i.e.,
non-Wikimedia) contributions.  Paid developers get less work done, but
you encourage an effective development community.  Volunteers don't
only do development themselves, they also provide a pool of people to
recruit who won't need to spend time getting up to speed when hired.

> 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.

On the other hand, by involving volunteers as much as possible, you
get a great deal of free labor.  Empirically, this seems like a very
effective approach for organizations that don't have much money, like
Wikimedia or Mozilla.  Open-source software is turned out on far lower
budgets than typical commercial software.

> 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.

This is exactly what's *un*important.  Many of the most
community-oriented projects are notoriously vitriolic, while
cathedral-style developers virtually always treat even completely
braindead users as though they were made of glass.  Being nice is a
good thing (to a point), but it's not at all essential.

The essential thing is to give developers the ability and the will to
contribute.  For them to have the ability to contribute, development
must all be public and easily followed, even if that results in
superficial efficiency hits.  How can anyone contribute usefully to
the Usability Initiative (say) if they have no idea what the rationale
was behind any of the design decisions, because the decision-making
was done face-to-face or by phone?  That's more efficient for the
employees, but sure as heck less efficient for the volunteers.

For volunteer developers to have the will to contribute, they need to
be rewarded, and one of the surest rewards is respect.  Respect means
that they're treated according to their history of contribution.  It
means that they can object to something and be listened to even if
their objection contradicts what some paid people agreed to in a
closed room.  It means that an established volunteer contributor has
more say in practice than a new hiree.  It means they make decisions,
they don't just give feedback.

> 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.

I don't understand what you mean by this at all.  Neither an employee
or an employer plays the role of a customer in any sense here.

On Thu, Jun 10, 2010 at 12:37 AM, Rob Lanphier <robla at robla.net> wrote:
> Um, ok:
> http://meta.wikimedia.org/wiki/Product_Development_Process_Ideas

Wiki pages can be used for collecting ideas, but I don't think that's
important right now.  We have ideas, we just need to discuss them to
figure out which ones are best.  Mailing lists are a good way to do
that -- wikis are bad for discussion.