This page contains information about how to measure and evaluate communities of users. We are typically interested in open source software projects.
It was started to share some information and materials between OSS Watch and Libresoft, while doing a study of Apache Software Foundation (ASF) mailing lists.
- To being with, we have made the definitions really really basic, so that the analysis of projects is simplified to the maximum. But it would be easy to change the definitions to make them richer (for example, weighting the contribution of each person to the list, as opposed to using a hard threshold of has written/hasn't written).
Contributor/Known User: Somebody who has sent an email to one of the user lists of the project, over the lifetime of the project
Unknown User: Somebody who uses the software, but who has never written to one of the project's mailis section contains a number of hypothesis concerning sustainable communities. It is our intention to explore these hypothesis in detail and to provide supporting/refuting evidence where possible.
The dia file for the diagram:
Ants are the key to long term sustainability
A healthy community is one that encourages all participants to be ants. That is all participants are encouraged to support users in their progression to being Ants. This hypothesis can be broken down into a number of further claims as outlined in the following sections.
Supporting Known Users is the key to sustainable communities
If a community invests time and effort into supporting known users some of those users will make valuable contributions to the community and will therefore make the community more valuable and sustainable. In a healthy community the ideal progression through community ranks is:
unkown user -> known user -> contributor
There are many possible routes to becoming a contributor. For example, the ideal lifecycle for a user becoming a contributor is:
Unknown user -> Symbiote -> Ant
However, an alternative path would be:
Unknown user -> Leech -> Symbiote -> Ant
Unkown user -> Ant
A community that consists only of Lone Wolves is weak
Lone wolves do not encourage users to become contributors. Without attracting new contributors it is more difficult to survive the departure of existing contributors as their interests change. A community should ensure that Lone Wolves are encouraged to become Messiahs, thus they pass on their expertise to the user community who can then provide replacements for departing contributors.
The ideal lifecycle of a Lone Wolf is:
Lone Wolf -> Messiah -> Ant
A mature and varied community will have few messiahs
In a mature community we should see Messaihs disappearing as they need to become users. As project newcomers contribute more the Messiah becomes less of the "one and only expert". Eventually there will be a contributor who knows more about some aspect of the project than the Messiah. This results in the Messiah becoming a user asking for support. So, they are no longer a Messiah, they are now an Ant.
The ideal lifecycle of an early contributor will be:
Messiah -> Ant
Messiahs are the lifeblood of a young community
Young communities will not have a self supporting user base. It is necessary for messiahs to step up and cultivate known users by providing support and guidance in order to encourage the creation of symbiotes. As a community grows and the number of symbiotes increases messiahs become less important since the use community is increasing in its ability to be self supporting.
Inspiration for further work
Mailing List Analysys
“In successful open source developments, a group larger by an order of magnitude than the core will repair defects, and a yet larger group (by another order of magnitude) will report problems.” (Mockus et al., 2002, p. 329). http://freesoftware.mit.edu/papers/crowstonhowison.pdf
this section summarises comments arising from discussions occurring in various locations about this document. The idea in to try and capture info so that it can he rolled into this page.
Types of Contribution
Ross: We need to define what a contribution is. In open source development a contribution is usually regarded as any (constructive) interaction with the community. No attempt is made to measure the value of a contribution since this is almost impossible to do. If we use this definition then I am concerned with the placement of Symbiotes in the diagram. They appear to be no more useful to the sustainability of the project than Leeches. This is not, in my opinion, the case. Consider that a Symbiote may help a user who later becomes a contributor. I think symbiotes are better placed along side "Brain Drains".
Roles for community members
Ross: We should map community roles to the taxonomy described here (actually that document is rubbish, it needs rewriting and expanding)
Ross: "Brain Drains" is a very negative term. I understand why it was chosen, but I feel that it it is too negative. Unfortunately I do not have a better suggestion right now.
Misc. Taxonomy comments
Ross: I think we should remove the word "never" from most definitions. "Never" implies that there is no way of moving from the that status. So, for example, instead of "Users who never become contributors..." we would have "Users who have not yet become contributors...". Even in cases like the Messiah, the term "never" is too final, it is perfectly possible for a Messiah to become a user as the community grows and third party contributions that the messiah does not understand are made.
The following is an attempt my to formulate Ramón's diagram into a true Venn diagram (because math is the source of all goodness in Comp Sci). Yes, I'm aware I can't draw.
Ross: I quite like this, but why have you introduced "helpers"; what makes them different? flow are they defined? I'm also concerned about "unknown users" being in the same section as "leeches". Unknown users are not a drain on project resources, leeches are. For this reason id put Unknown means outride.
Stuart: they mean whatever they meant in Ramón's diagram's captions when he says someone "helps". My diagram is an attempt at a change in style rather than a change in content.
Ross: ok, I see. In that case I need to think about this. Your diagram introduces a new "class" of community member. it is one that is implicit in the original diagram, making it explicit is probably good, but more thought is needed. My concerns about the placement of unknown users and leeches remain.
Comments from Tony Linde
The following was sent as a comment by TonyLinde to the mailing list and is posted here to make it clear that the comments and diagram are freely reusable:
> An interesting take, Ramón. I tried to ignore this and get on with my > own work but ended up with paper and pen trying out my own hierarchy > :) See attached.
Cool. This has some parallels with a diagram I did for Simal.
I particularly like the fact that this is showing potential paths through the lifecycle of a user, we need to compare your paths lo the ones I describe above.
> I started with the top level project consisting of people and other > artefacts (lists, site, wiki etc + product which consists of releases > containing code and docs etc). > > I split the people into known and unknown. The unknowns were those > who just happen on the site and pass on (passerby: does the project > need to do something to its site to entice them in?), those who are > interested but are just keeping an eye on things (what are they > waiting for, can we find out?) and those who've tried the product out > who then split into dropouts (do we know why they stopped?) and those > still using it (consumers: how can we get them involved?).
Without the limitations of our mailing list archives this breakdown of users makes a great deal of sense. we need to get this into the main document.
> The knowns have provided an email address at some point for some > reason. Those I split into those who've taken no part in the project > at all (name: that's all we have for them), those who no longer take > part (inactive but do we have a record of what they've done in the > past, what can we do with that, why are they inactive?) and those > active in the project in some way, split into contributors (those who > give back: code or answering questions or ...) and inquirers (those > who only ask questions: how do we get them further involved?).
Some of these map to people in Ramóns diagram, some of them are new. Again, we should capture the new ones above.
> I also made a list of all the activities I could think of which might > relate to 'people' in and around a project and came up with: > > lurk, code, document, email (ask, answer), test, feedback, use, > administer, manage, market, host (site, code, mirror)
We should also capture, and expand these. Given the limited scope of our initial project idea (mail archives) we defined a contribution as any mail to the user or dev lists. Of course, in reality a contribution can be much more than this.
Having said that, mails to the list are a reasonable approximation since most of these activities result in email.
The "lurker" one is interesting. We can't get that from a mail archive (although we can collect subscriber lists from now onwards if we want to). However, lurkers are very important to community development.
> And I don't even like the word, 'project'. For me, a project has > always been of limited scope: people, resources, time. An ongoing > development is more of a programme than a project but I doubt that is > going to change now.
I agree with your definition of project here. I'll change my language, maybe if enough of us do that the world will follow