As I mentioned last week, my friend Alex Bayley wrote a lot at their old blog Infotropism about open source/data/culture, community facilitation, and related topics. (Alex is currently concentrating on Bayleaf Handmade Goods where you can buy clothing, accessories, and craft supplies designed for reuse and repair.) I'm re-posting another one of their thoughts, to make it easier to discover and reference, followed by my present-day comments.

The community spectrum: caring to combative

(retrieved from the Wayback Machine, written by Alex Bayley, first published November 9, 2009 and licensed CC BY-SA)

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?

(retrieved from the Wayback Machine, written by Alex Bayley, first published November 9, 2009 and licensed CC BY-SA)

Sumana's comments

Alex wrote this piece before the rise of cryptocurrency. Many cryptocurrency-related projects use the language of "community" in their developer marketing materials, and at least at first work collaboratively; none of the participants can make money unless the group works together to build and popularize the platform. Molly White discusses how this often plays out.

Sometimes contributors speak about concerns that the culture of their project, or of the industry as a whole, is changing to get stiflingly "nice," or crowded with mercenaries. Maybe something has changed having to do with scarcity, and that the shift in those constraints has encouraged a shift along the caring-to-combative spectrum. For example, some open source projects feel collaborative most of the time -- but then, when scarce opportunities such as paid Google Summer of Code slots come along, new contributors hoping for those slots act in competitive ways. Or: the project used to be so hard to deal with that only the very dedicated could grapple with it, but now it's become easier to use and access, so hobbyists can now wander through to play with it and show off their low-stakes art sketches to each other.

I'm also reflecting on how discouraging, how momentum- and credibility-killing it is when an environment claims to be caring or collaborative, but then you stumble into a neighborhood within it where people compete or even combat (perhaps because that's where the turf war/status play is higher-stakes). This is the kind of thing that can bring your own work to a screeching halt, or, more insidiously, slow you down such that it takes you a while to recognize that the project is now draining your soul.

I'd now describe Kernelnewbies, Railsbridge, and similar efforts using the term "tidepool", as I discussed in my 2014 speech "Hospitality, Jerks, and What I Learned":

"...places where certain people can sort of rest and vent and collaborate, and ask the questions they feel afraid of asking in public, so they can gain the strength and confidence to go further out, into the invite-only spaces or the very public spaces....spaces where everybody coming in agrees to follow the same rules so it's a place where you feel safer -- these are like tidepools, places where certain kinds of people and certain kinds of behavior can be nurtured and grown so that it’s ready to go out into the wider ocean."

I have found that starting a tidepool, nurturing it along, and then demonstrating concrete results that benefit the larger "ocean" is a fairly reliable part of a strategy for encouraging change in an open source/culture project, as with the Wikimedia code of conduct. Those are examples of people creating more caring/collaborative tidepools in competitive/combative environments, but if you wish that your more caring/collaborative environment had a more competitive/combative tidepool, you could set up a challenge or tournament! But be careful of competition leaking out and affecting people who find it discouraging: there's a reason why, Dreamwidth, for instance, avoids leaderboards.