Open source communities don’t just happen. They require work. Sometimes the technical interest in an open source project is enough to attract a group of people to get involved. However, after some time, things are going to get too big for those with a particular bent (documentation, coding, testing) to manage the interactions between the various participants, moderate awkward (or downright aggressive) communications, help encourage new members to contribute, raise the visibility of the project into new areas or market sectors, and all the other pieces that go into keeping a project healthy.
Enter the community manager. The typical community manager is in that awkward position of having lots of responsibility but no direct authority. Open source projects being what they are, few of them have empowered “officers,” and even when there are governance structures, they tend to operate by consent of those involved—by negotiated, rather than direct, authority. That said, by the time a community manager is appointed, it’s likely that at least one commercial entity is sufficiently deep into the project to fund or part-fund the community manager position. This means that the community manager will hopefully have some support from at least one set of contributors but will still need to build consensus across the rest of the community. There may be tricky times when the community manager will need to decide whether their loyalties lie with their employer or with the community. A wise employer should set expectations about how to deal with such situations before they arise!
What does the community manager need to do, then? The answer to this will depend on a number of issues, and there is likely to be a balance between these tasks, but here’s a list of some that come to mind. As always, I welcome comments and suggestions for how to improve or extend this list.
- Marketing/outreach – this is about raising the visibility of the project, either in areas where it is already known or new markets/sectors. There are lots of sub-tasks such as branding, swag ordering (and distribution!), analyst, and press relations.
- Event management – setting up meetups, hackathons, booths at larger events or, for really big projects, organising conferences.
- Community growth – spotting areas where the project could use more help (docs, testing, outreach, coding, diverse and inclusive representation, etc.), and finding ways to recruit contributors to help improve the project.
- Community lubrication – this is about finding ways to keep community members talking to each other, celebrate successes, mourn losses, and generally keep conversations civil at least and enthusiastically friendly at best.
- Project strategy – there are times in a project when new pastures may beckon (a new piece of functionality might make the project exciting to the healthcare or the academic astronomy community, for instance), and the community manager needs to recognise such opportunities, present them to the community, and help the community steer a path.
- Product management – in conjunction with project strategy, situations are likely to occur when a set of features or functionality are presented to the community which require decisions about their priority or the ability of the community to resource them. These may even create tensions between various parts of the community, including involved commercial interests. The community manager needs to help the community reason about how to make choices and may even be called upon to lead the decision-making process.
- Partner management – as a project grows, partners (open source projects, academic institutions, charities, industry consortia, government departments, or commercial organisations) may wish to be associated with the project. Managing expectations and understanding the benefits (or dangers) and relative value can be complex and time-consuming, and the community manager is likely to be the first person involved.
- Documentation management – while documentation is only one part of a project, it can often be overlooked by the core code contributors. It is, however, a vital resource when considering many of the tasks associated with the points above. Managing strategy, working with partners, creating press releases: all of these need good documentation. While it’s unlikely that the community manager will need to write it (well, hopefully not all of it!), making sure that it’s there is likely to be their responsibility.
- Developer enablement – this is providing resources (including, but not restricted to, documentation) to help developers (particularly those new to the project) to get involved. It is often considered a good idea to separate this set of tasks out, rather than to expect a separate role to that of a community manager, partly because it may require a deeper technical focus than is required for many of the other responsibilities associated with the role. This is probably sensible, but the community manager is likely to want to ensure that developer enablement is well-managed, as, without new developers, almost any project will eventually calcify and die.
Nobody (well, almost nobody) is going to be an expert in all of these sets of tasks, and many projects won’t need all of them at the same time. Two of the attributes of a well-established community manager are an awareness of the gaps in their expertise and a network of contacts they can call on for advice or services to fill those gaps.
I am not–and could never be–a community manager. I don’t have the skills (or the patience), and one of the joys of gaining experience and expertise in the world is realising when others do have skills that you lack and being able to recognise and celebrate what they can bring to your world that you can’t. So thank you, community managers.
This article was originally published on Alice, Eve, and Bob and is reprinted with the author's permission.
Comments are closed.