Community Types

Spider Tower BlockWhen I am with business people, I often find I need to distinguish  between the different kinds of community that are layered around various Free software commons. It’s common to characterise community members as either “developers” (the “open source” worldview often emphasises this) or “users” (the “Free software” worldview often emphasises this). More than that, using the term “community” to apply to every style of gathering leads to confusion, especially regarding motivations for participating.

As I’ve watched various community engagements by various companies and individuals, and discussed this with various people, it seems to me that there are four different development-related community types, in two bands. These aren’t absolute classifications with hard-and-fast boundaries, and most communities span two of the types, but the distinction is helpful when discussing communities. The categories are:

  • Co-Developer communities – where participants share broad commit access to a particular Free software commons using open source licenses and norms
    • Core co-developers – people whose main participation implements, evolves and maintains the code in the commons;
    • Extending co-developers (extenders) – people who co-develop software that builds on or aggregates the work in the commons, for example making extensions, plug-ins, localisations and distributions;
  • Deployer communities – where the main engagement with the code involves a running instance that is configured and run by the community members in conjunction with other software
    • Deployer-developers – people who take the contents of the commons and configure and customise them for deployment;
    • Users – people who use – and whose employers may pay for – the work of Deployer-developers and put it to productive use.

Nested community layers - oval diagram - (c) 2010 Simon Phipps - CC-BY-SAThis model for community types has gradually developed over time for me. Naming no names, I have especially observed the following points arising from the model:

  1. There are four distinct community types here, but people may play different roles in multiple communities. For example, package maintainers working on an operating system distribution may be Extenders with regard to the code they are packaging and Originators with regard to the distro. And many people in the other three roles are also Users.
  2. People may well play multiple roles within a community too. A Deployer-developer may well be contributing code as an Originator as they address problems during deployment, for example.
  3. There are many different ways to contribute to the commons while participating. Users are often a crucial source of documentation, case studies, bug reports and feature requests and the User role is by no means to be considered unimportant.
  4. The freedoms people need protected vary between the roles. For example, a User is likely to view being protected from lock-in as a primary freedom and to want a choice of Deployer-developers working on their behalf as well as the use of open standards by Originators. While the original Four Freedoms provide a baseline, I’m increasingly convinced there are more freedoms that need protecting.
  5. The way a commercial organisation engages with communities must respect both the role the organisation plays with respect to the community and also the roles of the people they wish to influence. Treating everyone as if they were, for example, Deployer-developers, will lead to negative reactions from all the Originators and Extenders.

I used this model extensively within Sun to advise the  engineering, marketing and management teams on their community engagements. Having a set of shared terminology to distinguish roles was important for avoiding the assumption that everyone means the same thing when they say “community”, especially when there are people who think that “community” is a synonym for “market”.

[This version first published on ComputerWorldUK. Also available in Portuguese/em Português]

Creative Commons Licence
This essay is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
While you are not compelled to do so, the author would welcome notification of derivatives, especially translations which will be gladly posted here. If your intended use is commercial, please do ask for permission as it is usually granted; it is  withheld because of past abuses.

7 Responses

  1. I must say this model is particularly true with the open source community I am familiar with – Drupal. Say, is this a model aimed at shaping the concept of ‘open source software market’ or what?

  2. […] try to define the XBMC community as it should be (in my opinion): This article gives some inside info and this post provides some info over […]

  3. […] their own identity – particularly in the context of the MeeGo trademark. I particularly like Simon Phipps’s analysis of the four communtiy types as a way to clarify what you’re talking about. For Tizen, I see between three and five […]

  4. I really enjoy the blog.Really looking forward to read more. Keep writing.

  5. We are a group of volunteers and starting a new scheme in our community. Your site provided us with valuable info to work on. You’ve done a formidable job and our entire community will be thankful to you.

  6. […] Phipps has written about the different types of communities which can grow around a free software project. He describes communities of core codevelopers, […]

Leave a comment