Four ways to undermine a community

No readers like this yet.
Lots of people in a crowd.
Image by:

Opensource.com

At opensource.com, we often talk about ways to build and nourish communities. But sometimes what you do right is less important than what you’re doing wrong. We dug through our archives looking for cautionary tales that show how communities break down—or never begin to flourish in the first place.

How to wreck just about any community

1. Set up lots of policies, red tape, and bureaucracy

Nothing kills innovation quite like a mountain of paperwork. This story comes from Mel Chua:

Three unspoken blockers that prevent professors from teaching open source community participation
One of the hardest things about trying to bridge two worlds--for instance, open source communities and academic institutions--is all the stuff you don't hear on a daily basis when you're working remotely. Sometimes it takes several rounds of garlic bread and pasta for people to begin articulating what's blocking them from teaching their students how to participate in FOSS communities.
» Read more


2. Focus on tools and technology, rather than people

From Chris Grams we get an excellent piece of advice:

Avoid the tool trap when building communities
Over the last few years, I've had the opportunity to work with many different organizations attempting to build successful communities inside and outside the open source world. Many of them quickly fall into something I call the tool trap.

Meaning, they immediately jump into a conversation about what tool or technology they will use to support the community:

"Where are we going to put the wiki?"

"Should we build the website using Drupal?"
» Read more


3. Don’t bother recognizing the work of individuals

Wikipedia provides the example for this common source of community breakdown:

Love, hate, and the Wikipedia contributor culture problem
Last fall, a group of researchers at the Palo Alto Research Center (PARC) released a study showing an abrupt leveling off in the number of editors and edits to Wikipedia, starting in about 2007.
» Read more


4. Think of contributions, no matter how valuable or innovative, as coming from the nebulous “crowd”

Jaron Lanier's distaste for crowdsourcing provokes a debate between opensource.com writers:

Jaron Lanier: open textbooks "appalling and preposterous"
Jaron Lanier is certainly getting his share of press lately.  His latest guest starring role: a rant in Monday's very special episode of L. Gordon Crozier's technology column for the Wall Street Journal.  Seems like Lanier is becoming a go-to guy when one is in need of a sound bite denouncing "free culture" in all of its radical and dangerous forms.
» Read more


Is Jaron Lanier just a hater, or should we be paying attention?
Last week, my friend Greg DeKoenigsberg posted an article about Jaron Lanier's negative comments regarding open textbooks. At almost very same time, I happened to stumble upon an article Jaron wrote back in 2006 criticizing Wikipedia.

The common theme is Jaron taking issue with what he calls "online collectivism," "the hive mind," and even "digital Maoism" (ouch!).
» Read more

So, what did we miss?

We know that many of you are community-building experts, and some have revived a floundering community. We’d love to hear your stories. Together we can create a collection of "worst practices" that will help communities identify and address the problems plaguing them.

 

Tags
Business
Community management
Rebecca Fernandez
User profile image.
Rebecca Fernandez is a Principal Program Manager at Red Hat, leading projects to help the company scale its open culture. She's an Open Organization Ambassador, contributed to The Open Organization book, and maintains the Open Decision Framework. She is interested in the intersection of open source principles and practices, and how they can transform organizations for the better.
More about me

4 Comments

Avatar
Paul W. Frields | February 9, 2011
No readers like this yet.

I've seen bad actors called many things, by myself, and more importantly others -- negative, poisonous, haters, and some <a href="http://www.slideshare.net/dberkholz/assholes-are-killing-your-project">unprintable terms too</a> (quasi-NSFW for terminology only, no ugly images). Regardless of what you call them, community leaders need to be attentive to the tone of communication that each new contributor brings to the team to avoid accumulating or encouraging bad actors.

In my experience, new contributors whose attitude toward teammates is positive, humble, and willing to learn and teach tend to blossom into great contributors, and often leaders in their own right. Those who come off as brash, argumentative, and demanding tend not only to stay that way (or become more so) but also drive away other contributors who can't stomach that type of culture. While ambition and initiative are still important virtues for an open source team to thrive, these must be tempered with the ability to encourage and cultivate the best in others. (This shouldn't be surprising since these are also leadership skills, and in an ideal open source team every contributor has the ability to lead toward the shared goal.)

I've seen the big part of the battle often won simply by being attentive to new contributors. A bit of one-on-one mentorship, if possible, can set a new team member on a path to success, giving them a smooth orientation to the team and its culture. If the team's already afflicted by bad actors, though, this process can be difficult, especially if through neglect the bad actors have become part of the teaching process. New contributors then have a much higher chance of either turning away (from a reasonable, negative reaction to the bad actor), or taking on the same negativity because they believe it's acceptable, or even the norm.

How do you share enforcement of that culture? If everyone on the team has an equal understanding of the norms, it's simple to have consensus when a bad actor needs to be approached -- quietly and privately at first, to give them the chance to improve, escalating only if needed. If the team is not tightly bound in that way, a written conduct code might be necessary. We see these in many open source teams and projects, and they can be simple ("Don't be a jerk") or can rely on a sizable document that details what's acceptable and what's verboten. In either case, though, the goal is to treat each other well as a ground rule while pursuing the team's objectives.

Or in short: It's important not to confuse a culture that's capable of accepting anyone with a culture that's willing to accept anything.

Avatar
Chris Grams | February 10, 2011
No readers like this yet.

Hi Paul-- there are some really great insights in your comment above. In fact, I wonder if you might take some of these thoughts and turn them into an article about "dealing with bad actors in a community."

Or maybe the biz channel moderator should just post your re-post your comment as a new article so more people will see it:)

Avatar
Ghabuntu | February 11, 2011
No readers like this yet.

You might want to add Nokia's new partnership with Microsoft to the list...

Avatar
NH | February 11, 2011
No readers like this yet.

Nokia, a LinuxFoundation Gold Member, has money invested in that level membership, and at the same time Nokia has a proprietary business as well. It isn't an all or nothing deal, on one side or the other, nor should it ever be.

"partnership" is very generic in the business world, meaning just what the user of the term means by it. Microsoft has a market and a partnership very well means working together on products in Nokia's proprietary business. A good guess until proven otherwise.

If partnership means something else, then I have to think that Nokia would pull-out of the LinuxFoundation and clear the way, rather then have to deal with the title "bad actor" ? This is something the community needs to think about, and reserve saying anything that could be taken as judgement. Otherwise, it harms the community and drives away those that would want to work together with it.

Related Content

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.