Once you are up and running, energy needs to be put into the ongoing growth of the contributor base (assuming you haven’t hit capacity), and energy needs to put into keeping the current contributors active and involved. Again drawing a parallel between book development and code development, many open source projects have fulltime community managers. Jono Bacon is one such person – he is the community manager for Ubuntu and wrote the excellent Art of Community Book which is well worth reading, but please keep in mind that book community management doesn’t map directly onto free software community management.
Keeping the contributors involved can be a great job but it also has some gnarly issues. The vast majority of the work is social and some logistics – making sure that the technology for contributing is working and is not a burden, for example. You might not have to do any tech work yourself in these cases, but you will need to find the person that will do so. One thing that has almost universal value in this role is the ability to keep a one-to-one interaction feeling with active members of your community. You are a central pin in the entire mechanism and people like to be close to the action. Keep communicating with people, keep them talking, put them in contact with others working on similar issues, expand their networks, in other words – keep it social.
In addition to this, another secret ingredient is fun. Don’t make the mistake of taking things too seriously, and if you do, make sure that others don’t see it. It’s ok to blow your top occasionally – its actually good to be seen to be fallible – however, you should apologise as soon as possible and get the good feeling back in the air. For the most part, however, it is very important that the community enjoys the ambiance – this might seem an intangible ‘fun factor’ but it’s more likely that it’s carefully engineered by you than it ‘just happens’.
Another very important issue, is learning when and when not to channel attention and requests to members of the community. Those that are active will become natural pivots on the center of your community, and that redirection to them can turn into a burden for those core individuals if not managed with care. Make sure you are keeping an eye on their frustration levels – if you see they’re getting too much of a load put on them by normal community processes, then you may need to step in and redirect or take on some of that traffic.
These core members are very important to the health of the project, so don’t be disappointed when they leave. Communities have natural cycles and, in addition, community members have other lives. When they inevitably move on, make sure you acknowledge them in front of the community – this is not only a good thing to do, it will relieve any disappointment you may feel and it will signal to the community that everyone is respected and valued as individuals – not just as production engines.
Also keep in mind that, although natural hierarchies will evolve, it is quite important to keep the community in an egalitarian mindset. All contributions should be valued, and all contributors should be valued. That also means that you must keep the balance of power even. Core contributors will naturally get more say in how things go, so ensure that channels are open for all voices in the community to have their say. It is also for this reason that it is not a good idea to bring any publishing world hierarchical structures to community management. Don’t think of editors and writers, think of collaborators and facilitators.
If people are enjoying themselves and enjoying the social environment, they are of course not necessarily being productive. My experience is that people involved in this kind of project generally like being productive. If they are talking, it’s usually a sign they are working.