CNET también está disponible en español.

Ir a español

Don't show this again


More on "firing" one's community

Russ Danner's take on the need to fire unproductive members of one's community.

I cited Russ Danner in my last post on firing one's community members. Russ has since added some additional detail, which he has allowed me to post here. I also heard back from Martin Michlmayr (Cyrius), who noted:

Actually, destructive community members are a serious problem in many projects. I've seen major problems resulting from destructive community members at least in Debian and the Linux kernel project. Ben Collins-Sussman and Brian Fitzpatrick from the Subversion project discuss this problem in a talk: How Open Source Projects Survive Poisonous People (And You Can Too). A video is available online and there's a summary here.

So what do you do about them? Or even non-"poisonous" people who are destructive of communities, despite their best intentions? Russ responds:

The first question I have is what does it mean? I don't think it means kicking them out of the forums. The only reason I would banish a community member from the public resources is for abuse / malice.

My thoughts on firing a community member are similar to the way the sales/solutions engineering staff let "on the fence" customers down. You might not call that firing the customer - but it is probation. I really agree with that policy and I feel it translates well to the community.

I actually think it [firing a community member] happens all the time. We simply stop responding to the guy. I've certainly seen the professional staff at Alfresco "walk away" from worm holes - and I think it is the right thing to do. [Note: Russ is active with the Alfresco community; hence, the reference.]

It generally relates to an issue, not the member, long term but I'd be willing to bet there are community members we simply don't bother with either because they have been a pain in the rear in the past or because it is obvious that they will be going forward. There are some people who have cannot be satisfied or are simply freeloading to a point where it is unsustainable for the company. If the community can help them, cool - there are a ton of people reading/answering in the forums, the forge serves as examples for those who are clever enough to figure that out and the documentation is ... there - help yourself.

We need customers, not long-term courtships that consume time and money and have no commitment. We need community members that can help themselves and others.

[Communities] need to support needy members and the newbies to a point and then let them go to make room for others. Either they will blossom or fade. We need to prioritize our energy. Only so much mentoring can go to the newbies and only so much time can be spent with the needy members. The softballs should be left for the community to answer - it builds the community credibility and gives them something achievable which they can build on.

The engineering staff should be pulling the top community members along and answering the more difficult questions or filling the gaps in the understanding of the strong members. The company can't hire every good community member - if it can, it's not doing a good enough job at creating strong community members.

The community needs to have room and encouragement to grow. And needy folks should be encouraged to pay for the access to on-demand support. It's important that everyone should have a clear expectation of what they will get from the company engineers as it relates to their activity in the forums, community release etc. The source code is free - the support is best effort (professionally speaking.)

I think Russ is dead-on with his comments. You have to take the training wheels off the community at some point, and let people support themselves. If someone is stuck in an obnoxiously needy state, set them free. You'll be doing them a favor. And if they're just a jerk, set them free. You'll be doing yourself a favor. :-)