A wander through the public email archive of a project’s development list or its user list is, for me, a prerequisite to involvement of any kind. But that may just be me. I am not a programmer with a particular itch that needs scratching. So I can afford to be choosy about where I spend my free time. And I don’t have the skill set to be fascinated by a project simply on the basis of its truly remarkable code – code from which I could no doubt learn a thing or two. Those are both great reasons to get involved in a project: individual need and learning. But they aren’t mine.
If your open source project scratches someone’s itch exceedingly and uniquely well, you will probably have no difficulty in attracting people with similar itches to your project. They might even stay around regardless of the environment because that itch has just got to be scratched.
If your open source project happens to have such brilliant programmers that they are collectively pushing the envelop or even defining the nature of the envelop, again, you will probably have no difficulty attracting people desperate to learn from you and develop their own skills. And again, they might even stay around regardless of the environment because of the substantial benefit they are getting in terms of learning.
I’m guessing, however, that the vast majority of open source projects do not fall into either of these camps. Certainly the majority of projects that I encounter on a daily basis are only moderately itch-scratching and very rarely paragons of programming excellence. They are the relatively unsung projects that address a particular need, but not necessarily uniquely. They do their best with regard to their code, but they aren’t going to be written up in next textbook for computer science 101. And nearly all of them would like to grow their project in some way. Indeed, many need to grow their project, to build their community base, or the project will not survive at all.
It seems to me that I am a likely candidate that such a project might wish to attract. I’ve got a bit of free time, a modicum of ability to provide content authoring or user support, but not such a high opinion of my own coding that I think my talents would shine better in the bright heat of one of those star projects mentioned above. What kind of things will I be looking for when I first visit the email archive for this project?
In no particular order, these are some of the things I look for:
- modest throughput
- lists which are too busy will take up too much of my time reading, so I won’t have time to contribute
- project focused
- if the majority of discussions on a development list are about the recent events on Big Brother, it’s not for me
- treatment of newbies
- I’ll be a newby if I join this project, so I want to know how I’ll be treated by those who have been around for some time. I can get abuse at work; I’m not going to bother hanging around for it on my own time
- societies are said to be judged by their treatment of their most vulnerable members; for me, that’s also true of open source projects
- clear guidance for appropriate behaviour
- this could be guidelines on the project site, but it also could just be evidenced through the example of the key members of the project and their periodic explanation to newcomers
- sometimes this guideline is codified into an acceptable use policy (AUP). AUPs do not have to be draconian, they just have to make things reasonably clear and give a pointer to what will happen (or what you should do) if there is a confusion.
- periodic summaries by the list owner
- this is not essential, but it is incredibly useful to have someone periodically summarize the discussions that have taken place on a list that is receiving more than 10 emails per day. Once per month is probably more than sufficient. It recaps for those who have been filtering this list to read later, and it reinforces the usefulness of the archive to those searching. I don’t see this nearly often enough.
- this probably sounds like a lot of work. Hey, if you want to attract me to your project, maybe it’s worth a bit of effort. You might even convince me that this would be an excellent way that I could contribute to the project, i.e. by writing this summary for the list myself
- treatment of those who for whatever reason abuse the list
- people can abuse a list in lots of different ways, some deliberate, but most inadvertent. How do the key contributors to this list deal with that abuse?
Remember, I’m not one of those star developers looking to make a mark in a star project. I’m part of the long tail that will, due to the network effect, potentially make even your modest project successful.
What’s the email archive profile for your project?
Using an archive to examine the “health” of a project is a good idea, but they are useful for two other things with respect to community building:
Firstly they should be great for finding answers to questions – complete and accurate docs are often hard to come by in Open Source projects. Mailing list archives should be a source of expert knowledge that will prevent users having to ask a question.
In a project that is reaching maturity the user list should be fairly quiet. Most of the answers should be available in the docs o in the archives. In a rapidly developing project the user list is likely to be quite busy.
Secondly, it is useful to guage what type of community the project has. You cn use tools such as the Apache Labs Agora project (see it running at http://people.apache.org/~stefano/agora/ ) to look at the dynamics between community membrs on various lists. This ill tell you how many “core” members of the community there are. Generally speaking, the more the better.
Thanks Ross. I agree with both points. I also agree that mailing list use evolves over the life-cycle of a project. I’ll have to think more about that.