When 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.
This 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:
- 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.
- 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.
- 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.
- 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.
- 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".