This is part of my “Craft of Community” series of blog posts; you can find more through my craft of community tag.
Like I said in my last post, I’ve started and participated in a pretty wide variety of communities: large and small, technical and non-technical, open and invite-only, non-profit and corporate-sponsored, focused and general. The only thing they’ve really had in common has been that they’ve all been online, to at least some degree; my life’s been pretty Internet-mediated since I first got online in 1993 and I can’t think of any communities I’ve been involved in since then that haven’t had at least an informal mailing list. So that’s just to declare (at least one aspect of) my bias up front.
Last year one of the designers at my work linked me to The Competitive Spectrum over at the Yahoo Developer Network, and it introduced me to a whole new way of thinking of the variety of communities. It’s part of a larger set of social patterns related to reputation, which is a whole nother subject, but for now I just want to talk about the spectrum itself.
The Competitive Spectrum describes communities as being:
- Caring: members are motivated by helping each other.
- Collaborative: members share goals and help each other to achieve them.
- Cordial: members have their own goals which do not conflict with each other.
- Competitive: members share the same goals, and compete against each other to achieve them.
- Combative: members must achieve their goals by preventing others from being doing so.
Yahoo gives some examples of each (mostly drawing from their own web properties), but I found it interesting to consider some technical communities I know and think about where they fit into the spectrum.
Most open source projects are collaborative, at least on the surface. Contributors come together to build a piece of software, each contributing their own time and skills to achieve the shared goal. However, you see some spread on the spectrum as well: as contributors get to know each other through online chatter and real-life meetups, they can be quite caring; some developers submitting uncontroversial patches that scratch their own itches do so in a way that’s basically cordial; and at times, developers who are keen to see their own preferred solutions make it into core, or whose egos become tied up in their contributions or their role in the community, can tend toward competitive or even combative.
It’s interesting to compare Dreamwidth, an open source project I’ve blogged about before, which seems to tend more towards the caring end of the spectrum. I’ve seen countless examples of generosity and personal support in that community, and can only think of very mild examples of competitiveness (and none of combativeness). It’s impossible to tell how much of this is due to their founding principles, the project’s relative youth, the fact that the project is centred around a journalling platform that tends to expose contributors as “real” people, or the fact that the majority of contributors are women who have (for the most part) been socialised to behave this way: any or all of those may be contributing factors.
There are a handful of open source projects that actually show a kind of dimorphism: part of the community at either end of the spectrum. One example of this is the Linux Kernel, whose mailing list is known to be one of the most combative in the field, while the Kernel Newbies group has a friendlier, more helpful, caring feel:
Kernelnewbies are a community of people that improve or update their Kernels and of aspiring Linux kernel developers and more experienced developers willing to share their knowledge. We help each other learn how the Linux kernel works and occasionally discuss other operating system kernels.
Along similar lines, the Rails community, which has a reputation for being quite rough, has Railsbridge, whose mission is “to create an inclusive and friendly Ruby on Rails community.” In both these cases, the more caring group was founded in reaction to the main group’s unwelcoming reputation. We could look at these groups as separate communities, except that the membership and activities tend to cross over and blur. (The question of what delineates a community and how you define the edges is a hairy one, and I’m not going there for now.)
You can apply the community spectrum to any kind of community, not just open source projects, nor even just online communities. It’s easy to see how it can apply to anything from sports teams to cancer support groups.
This model’s really helped me realise that what works for one community may fail dismally for another. It’s not hard to see how a community’s place on this spectrum can influence everything from appropriate leadership to rewards for participation to what kinds of online forums or real-world meetups will work best for the group.
So, how about your communities? Where do they fit on the spectrum? Anyone got any other interesting examples of dimorphism?