Tuesday August 28, 2007 Community Roles
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:
- 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.
- 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.
- 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'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.
links for 2007-08-28
-
Fascinating article on what happens when you take the OOXML spec at its word and go edit documents by hand. It seems MS Office is very intolerant of this sort of (valid) behaviour and that OOXML is insufficient for interoperability.
-
Having 23 of your business partners sign up the day of the vote is probably not against any rules but it's ethically suspect to say the least. OOXML continues its track record as the dirtiest application for standardisation in recent years.
-
Awesome new technique - watch the video.
