Blog post

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

By Brian Prentice | April 20, 2010 | 7 Comments

“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!

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Ian Skerrett says:


    Another interesting post and it is clear you are doing a lot of great analysis of the open source world (just couldn’t use the word ‘community’ 🙂 )

    I agree with basically everything you have laid out here. However, I think the root of community is not in the open source license but in the governance of the community. In mature open source communities there are well defined rules and traditions for how individuals and organizations can join and contribute to a community. All to often open source companies fail in the area of governance and this is why they have a hard time developing a proper community.

  • Chris Grams says:

    Fantastic post, Brian. Picked it up, and ran from where you left off on

    Thanks for opening up the debate!

  • Brian Prentice says:

    Hi Ian Skerrett – you know, I thought a lot about this exact issue of the governance structure of a community. I agree it is central to understanding the viability of community. It’s a topic I hope to explore more in the future and would be happy to get links to those who are already thinking about it.

    But I just want to remind you that I’m not saying that an open source license is the root of community. I’m saying that shared participation is the root of the community. The open source license is conducive to community model because it removes a layer of distrust that can inhibit shared participation.

    Nonetheless I think your observation is very important and warrants much greater consideration across the breadth of the IT industry (including us analysts)

  • Chris Gams – thanks for the kind word. I read your post yesterday and thought you added some great additional insights into this discussion.

  • Ian Skerrett says:


    I couldn’t find any relevant links on community governance, which actually surprised me. Maybe if I get some time I will write up something.

    I think there are a number of aspects that need to be considered to encourage community participation, including:

    – What are the rules and who decides what code is accepted into the project? This also includes who determines future roadmaps and future features.
    – How are new committers brought on board to the project?
    – Who maintains control of the copyright of the contributions?
    – How are project plans and decisions communicated?

    Then there is non-code related things:
    – What are the contribution agreements?
    – Who determines licensing and IP policy?
    – How are the rules of the community changed? If there is a legal entity (which most well establish projects would have)? How is the Board selected and who can sit on the board?
    – How are trademarks controled and shared?

    Obviously there is a range of implementations to open source governance. At a high level there seems to be 1) Foundations, like Eclipse, Apache, Linux, etc and 2) Corporate. Each has its strengths and weaknesses. IMHO, the independence of the Foundations leads to easier community participation, since everyone tends to be treated as equals. In fact the way you have influence in a Foundation is through your participation not through management control.

    Governance is certainly an area that needs more attention. It would be interesting to see your thoughts.

  • Ian – awesome comments. Thanks so much for taking the time to put these down.

  • Great post and I totally agree that we need to nurture the use of community. A spot on resource to conversations about community and governance is obviously Jono Bacon’s (ubuntu) brilliant book ‘the art of community’ and related blog