What should a community manager do?

Rod Whitby rod at whitby.id.au
Sat Oct 11 07:48:38 CEST 2008

Steve Mosher said:
> Sean asked me what I thought of having a community manager.
> I have my ideas about what a community manager would do to organize
> and mobilize, But before I put those ideas down, I'd like to throw it
> open to the community.
> Question: what functions do you see a community manager performing.

I'll answer this from the point of view of a "development community"
manager.  I think you already have a fine "end-user community" manager
in Michael Shiloh.

A development community manager must have the number one priority of
embracing all the disparate developers working on the Openmoko platform,
and being responsible for "bringing them into the fold":

a) Make sure that they are all at least subscribed to the one developer
mailing list, and that that list is forcible kept "pure" from end-user
support issues (there are already lists for that).  Yes, this means
contacting developers individually, and personally (in private)
requesting that they join the developer mailing list, and it also means
telling people who abuse that developer mailing list for end-user
support or chit-chat to go use the correct mailing list (politely, but
in public, so others learn).  Also make sure the community manager
"hangs out" on the official development IRC channel for real-time

b) Maintain a single build system and set of repositories which makes it
easier for all those disparate developers to use the "Openmoko"
developer resources instead of setting up their own elsewhere.  Make the
barrier to entry very low (if you can write either the code or the
manual page or the build system or the gui for "hello, world" for the
openmoko, then you're qualified to have access to the SVN or Git
repository).  Trust that developers will not abuse the repository,
instead of forcibly locking them out (Wolfgang told the Openmoko admins
to give me svn and git access on the 22 Sept, and nothing has happened yet).

c) Manage those developer resources (mailing list, repositories, wiki)
like they are your crown jewels.  Never let an external developer be
inconvenienced because some mailing list is sending duplicate messages,
or some repository system is not allowing anonymous svn checkouts, or
some autobuilder is not producing daily kernel packages.

d) Show your external developers the appreciation they deserve.  When a
developer produces a kernel patch which solves a GSM problem, don't
argue with him in public and make him feel that his work is not
appreciated.  Remember these developers are working for you for free.
Embrace what they produce, and *make* *sure* that it makes its way into
the official distribution.  If a developer creates their own downloads
area for kernels with their patches in them, then the development
community manager has failed in their job.

e) Focus the developers on the critical development needs.  Do this by
continuously reminding the developers of the most critical areas, and
encouraging them to submit solutions to these problems.  Treat those
solutions with utmost respect, never make an external developer feel
that they need to jump through more hoops than your employees to get
something into the official distribution.

f) Treat all the disparate development efforts as part of one "whole".
If you see duplication of effort, talk to those people in private and
nudge them towards joining efforts together in a single development
repository in which they both work, instead of forcing them each to work
in their own disparate development repositories in all corners of the
internet.  Continually encourage consolidation of the lowest levels of
development and structure your repositories and development processes to
allow multiple people to work on those areas in parallel.  There should
never be any areas where there is a single person (especially an
openmoko employee) who feels that they and they alone are allowed to
touch that code.

g) *Never* cause a developer's work to be wasted.  All those developers
who fixed bugs in 2007.2, then 2007.11, then 2008.x, then qtopia, the
FSO - every time that their work is somehow excluded by a decision made
in private you loose the enthusiasm and drive that makes the difference
between a herd of cats and an army of developers.  Keep the developers
aware of the long-term strategy of where you're heading.  Don't surprise
them with something that happened in private.

h) Structure your software architecture for consolidation and stability
at the lowest levels, and multiple co-existing choices at the highest
levels.  For goodness sake, have a *single* kernel that everyone
contributes to and uses.  Make sure that changes in that kernel *never*
break userspace without the person proposing the breakage going out and
proactively working with the userspace people to migrate before the
change is forced upon them by surprise.  Make sure that all the
different choices at the higher levels are all built from the same
source base, in the same set of repositories, and all use the same
official feeds.

i) Never fork wholesale from upstream.  If you need to make a branch,
then talk to upstream and try to make the branch in *their* repo.  If
you need to fork, then fork the absolute minimum set of things possible.
 The current state of org.openembedded.dev in OE vs org.openmoko.dev in
OM is a complete waste of time and effort that has not gained anybody

j) Mantain an autobuilder, and manage it proactively.  Whenever you see
someone mention a package on the mailing lists, make sure that someone
adds that package to the autobuilder so that it's part of the official
feeds.  Have mechanisms where developers can commit source code for a
new package and cause the autobuilder to build and release that package
on the official feeds without any employee intervention.  Treat
third-party feeds and packages listed on third-party websites as
indications that the development community manager has failed in their job.

I say all this based on the experience of running the nslu2-linux.org
project for the last four years, and building a community of over 100
developers and over 10 thousand users all working in common repositories
producing packages and images for four different distributions (targeted
to four different use cases) using the same top-level build system and
ending up in common official feeds on a single official download site.

See the following documents for more details:


-- Rod Whitby
(No, I'm not looking for the job)

More information about the community mailing list