Community Roles

Spider Tower Block

In considering the nature of open source communities that gather around various Free software commons, I often find I need to distinguish between the different roles people play. It's common to characterise community members as either "developers" (the "open source" worldview emphasises this) or "users" (the "Free software" worldview does this). But it's increasingly clear that neither approach is sufficient.

As I've watched various community engagements by various companies and individuals, and discussed this with various people (most recently Luis Villa), it seems to me that there are four different roles. These are:

  • Originators (originating co-developers) - people who co-develop a particular Free software commons using open source licenses and norms;
  • Extenders (extending co-developers) - people who co-develop software that builds on or aggregates the work of Originators, for example making extensions, plug-ins, localisations and distributions;
  • Deployer-developers - people who take the work of Initiators and Extenders and configure and customise them for deployment;
  • Users - people who use - and often pay for - the work of Deployer-developers and put it to productive use.

This model for community roles 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 roles, 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. 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.
  4. 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'll be using this model in the coming months within Sun to advise our engineering, marketing and management teams on their community engagements, so corrections, enhancements pointers to research and other constructive comments would be most welcome.

Update 31-Aug: There's an interview with me that discusses an earlier version of this and much else up on java.sun.com today.

Comments:

You left out an important group of any community, the users who contribute documentation, tutorials, and sample applications. These are often the early adopters who painstakenly take the time to leave a trail for the rest of the world to follow (with a lot less head-banging).

Posted by Diva #2 on August 28, 2007 at 02:22 AM PDT #

Do you think they are indeed a separate category, or are they a kind of deployer-developer?

Posted by Simon Phipps on August 28, 2007 at 02:41 AM PDT #

Hi Simon. I would like to suggest that the conventional developer-user role model distorts our thinking. Subdividing the developer roles only accentuates that distortion by increasing the focus on those editing code.

If we look at the community around a successful open source project the vast majority of people never touch (or even look at) the code. However they: market the application to their friends and colleagues; they support other community members by asking & answering questions, writing documentation, providing examples; they report bugs; very importantly they suggest possible improvements & new features; and finally just by using the project's application they make the community larger & more significant.

Just as you have shown how to "unweave the software bundle" to demonstrate how code is only a part of the value provided, we need to do the same thing again with the community roles.

-- Ron --

Posted by Ron Goldman on August 28, 2007 at 06:21 AM PDT #

Ron: Thanks for that. Are you suggesting discarding the three developer roles, or subdividing the User into multiple roles? The thre developer roles have proven a very important distinction in discussing communities with executives.

Posted by Simon Phipps on August 28, 2007 at 07:12 AM PDT #

Simon: I want to discard the developer-user distinction and then list all the roles that people take on to make an open source project a success, including moderating discussions on mailing lists/forums, integrating contributions, designing new features, doing usability studies, graphic design, managing releases, maintaining the website, editing a project newsletter, evangelizing the project, etc.

This list would include your 3 developer roles, though the Originators role seems somewhat historical---aren't Originators also Extenders? Are you trying to distinguish the core team from the more occasional contributor?

-- Ron --

p.s. I appreciate the need to simplify matters when talking with executives. There may need to be two different models: one for understanding successful open source projects & another for clarifying how/why a company can engage with or sponsor an open source project.

Posted by Ron Goldman on August 28, 2007 at 09:44 AM PDT #

Simon, two points:

I would change:

"Users - people who use - and often pay for -"

to

"Users - people who use - and may pay for -"

If you look at most commercial OSS projects, less than 0.01% of users are paying customers. "Often" seems to be overstating reality.

Also, I think you need another role to represent the HPs, Unisys, Dell's of the world. They may fall into "deployer-developers" but often these vendors simply ship another OSS vendor's code as is, without configuration or customization. These vendors do offer the OSS vendor a route to a large set of customers and often own the support relationship with the customer.

Posted by Savio Rodrigues on August 28, 2007 at 11:13 PM PDT #

Interesting discussion.

I did a review of academic research into open source software quality (published in IEEE Software, Jan/Feb 2007) in which community membership and roles featured heavily (can supply a PDF by email if you don't have IEEE library access). A user model which research studies commonly outlined was the layered 'onion' model which is pretty much what you're talking about here - large numbers of users on the outside layer then decreasing numbers of different user roles until you get at the core developers in the centre. The titles I kept coming across were users, bug reporters, contributing developers and core developers. It's quite simplistic, but a good overview and easy to understand for those not too heavily involved in open source.

I think the term Originators can be misleading - it could be taken to mean people who originally started up a project but may have left. I think the term Core Developers is good for this central team, who provide project leadership, release management, and act as codebase lieutenants, accepting or declining contributions.

Agree with the Extenders role - this is a very good title.

Not sure about the term Deployer-developers - I found a consensus on this third layer to be people who have moved beyond users and are contributing feedback, which is why I use 'bug reporter', but agree that it also covers other inputs such as feature requests. Not sure I would really put deployers here - even when I deploy open source software within my own organisation, within the terms of the open source project I would still consider myself very much a user. There are many user types for a software product from new users to advanced users through to admins and deployers - to me they are all end-users of the product, and do not constitute a different role within the open source project unless they start to contribute in some way.

Posted by Mark Aberdour on August 28, 2007 at 11:21 PM PDT #

Mark: Thank-you for the feedback, it's helpful. I've seen the onion model before. One of the things I thought it lacked - which I'm trying, not 100% effectively, to correct here - is an indication that deployers/users are rarely focussed on a single function. All the roles apart from Originator are non-exclusive and the people playing them span multiple communities.

Ron: That's also one of the reasons I think both styles of model are needed. As you hint, I have to explain to Sun's executives that not everyone in a community is a customer, and this model allows me to do so :-)

Posted by Simon Phipps on August 29, 2007 at 06:51 AM PDT #

Hi,

Interesting points, but not sure how you contribute to the cause here.

JJMacey aka Adler

Posted by JJMacey on August 29, 2007 at 10:25 AM PDT #

Hi Simon,

I would simply re-define customer to include all those that give something of value, although Sun executives may not necessarily appreciate that definition :@)

But the breaking down of that barrier between user and producer is one of those phenomenons enabled by the Internet, in the general case, and by open source dev models, in this specific case. It's a favorite topic of Doc Searls, and he may have something to add here.

As you point out, these roles are not exclusive and frequently overlap. However, as pointed out above, you don't really make room for the advocate - that person who's an early adopter and evangelizes for the project. In my experience, while this role is often filled by the originators it can also be that early adopting user who can't write code but is an influential user that others look to recommend new technology.

Others may quibble with your exclusion of those who contribute docs and other non-code, but really, those could easily fit within the extender or deployer-developer roles.

-John Mark
Hyperic Community Manager

Posted by John Mark on August 29, 2007 at 12:27 PM PDT #

John-Mark: I can see from all these comments that I also need to consider a model that's a view from inside the community looking outward. I think the comments you're making are completely valid. The Advocacy role you're considering almost certainly is an overlay on all four of these outside-looking-in categories.

Posted by Simon Phipps on August 31, 2007 at 03:07 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Thoughts and pointers on digital freedoms and technology markets. With a few photos too.

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today