Defining & Defending The Meaning Of “Community” – An Open Source Imperative

“The beginning of wisdom is a definition of terms.” – Socrates

An old saying that has particular relevance in the world of information technology. Our industry loves couching ideas in clever new terminology. Sometimes the attempts are laughable. But every so often a new term will resonate. Unfortunately in IT, it’s only a matter of time before everyone co-opts the term for their own purposes. And once a term ends up mean anything it ultimately means nothing.

Such is the perilous state of the term “community.”

This should be of particular concern to anyone with an interest in the future of open source software because “community” has always been one of its most unique, albeit amorphous, qualities. Unfortunately there are many self-described open source advocates that are fuelling this terms irrelevance.

If “community” ends up losing it’s meaning through commercially-driven misappropriation than all efforts to expand the understanding and adoption of open source will be severely hampered. It’s like a free market version of Newspeak. The broader interests of open source require a stringent definition of community – one which captures its unique value in the context of information technology. With that base line established we should all call BS on those that attempt to use in any other way.

As I see it there are four working definitions of collective behaviour relevant to the world of information technology. They are:

• Crowd – a collection of people whose defining characteristic is proximity (physical or digital)
• Mob – see definition for crowd, add anger (thank you anonymous blog comments)
• Affiliation – a collection of people whose defining characteristic is a shared interest. Affiliations can emerge quickly and are more self-sustaining than crowds. A key reason is that there tends to be a focal point, sometimes a member, through which interact flows through or centers around. As long as the focal point of an affiliation participates then the rest of the affiliation can simply observe.
• Community – a collection of people whose defining characteristic is shared participation. Communities are ultimately geared towards some form of action. What drives the collective participation of the community is the individual vested interest of each member. Finding an intersection between members’ individual vested interest is highly complex and that means communities are uniquely difficult to catalyze and sustain. Furthermore, communities are only viable when a critical mass of its membership contribute. Unlike an affiliation, too much observation kills a community.

There is a strong affinity between open source and community The reason for this symbiosis is the open source license agreement. Modification and redistribution rights make it impossible for a single entity to control the underlying asset – the code. That simple fact creates a certain element of trust – or to be more accurate it removes a certain element of distrust – that can hamper shared participation in code development and maintenance. But to reiterate the point, that participation occurs because a community member has a vested interest in doing so. Maybe they need to undermine a competitors market position. Maybe they need to distribute the cost of building a key sub-component for their product. Maybe they just want to build their personal reputation.

However, defining and assessing communities must be based on the type of participation being shared. I would argue that a community of code contributors is a very different group than a community of people providing support and advice. The membership may overlap – but the nature of the shared participation is different. On that basis then an open source project might have several different types communities. But the simple application of an open source license agreement doesn’t guarantee any community will emerge, as many projects can testify.

On the other hand, a project’s users or a company’s customers do not constitute a community. That’s because there isn’t really any shared participation. This group is better defined as an affiliation (sometimes even a crowd). The same can be said about groups of channel partners like resellers or system integrators.

This is exactly where things are starting to get unstuck. Increasingly it is fashionable to use to the term community to represent the sum total of all relationships a company has – regardless of who it is. In this context everyone is on equal status which is clearly a nonsense. One more additional user probably makes no difference to every other user. But another code contributor can have a significant impact.

That existing proprietary vendors are co-opting the term community in this way is not surprising. But I find it hard not to be cynical when I see a growing number of “open source vendors” – particularly those subscribing to open-core business model do this.

The open-core business model is designed around converting users of a free, functionally-reduced, “community-supported,” open source version to a proprietary, paid-for full version. This focus on conversion rates drives their perspective on community. In their world, anyone that can potentially be converted into a paying customer is a member of their “community.” But when we start applying a proper definition of community, as in a community of code contributors or a community of project support providers, then things don’t look so rosy for a lot of these open-core vendors. The fact is that many are simply failing to get any traction catalyzing these groups. So it’s convenient to lump everyone – including those who casually download the open source version of their product – into a big bucket they call community. Its suits their marketing objectives. And it certainly doesn’t hurt their ability to shake some extra funding from the venture capital money tree.

Using the term community in this fashion is a little like pissing in the open source pool. It’s anti-social behavior that the perpetrator hopes will go unnoticed but which, if done by too many, soils the entire pool. If a community can be anyone and everyone than it devalues the honest-to goodness-communities that have emerged around some, but not all, open source projects. And make no mistake – catalyzing and sustaining a community is half magic and half hard work. When it happens it needs to be uniquely recognized and rewarded.

So sorry for being pedantic but if community is going to have any meaning it must be limited to collective behavior based on shared participation. And I’m prepared to call BS if a vendor does otherwise.

I hope you do too!