Tag Archives: opensource

What does a community manager do

Last week I took some long-postponed vacation time and missed Stormy’s blogging prompt. But this particular question needs answering.

What does a community manager do?

Whenever people ask me what I do, I find myself struggling for words, because being a community manager is a daunting mishmash of interrelated tasks that range from marketing to HR to event management to journalism to … everything else.

During the Obama years, the term “community organizer” was bandied about, and that comes close to what a community manager does. And then there’s the confusion around the term “manager”, because I’m not a manager, and I don’t manage the community.

So what do I do?

Well, it’s a bit of this and a bit of that.


A major task of community management is to be the lead cheerleader for the community. I’m the community manager for RDO, and so it’s my job to promote RDO to the various audiences that might care.

In the case of RDO, that includes the larger OpenStack community, cloud operators in the general IT work force, and also internally to people at Red Hat who need to be informed about what’s happening in the “upstream” community, and how it affects our “downstream” product, Red Hat OpenStack Platform.

To this end, I manage our Social Media presence, post updates to our mailing lists and blog,  make announcements on IRC, and so on. I also show up at conferences and answer questions from attendees, put together presentations to tell people about what we do, and speak at events.

Event planning

At Red Hat, we have an actual event planning team, and they are awesome at what they do – booking facilities, shipping stuff around, planning and setting up and tearing down the physical booths at events, coordinating and communicating with all of the people that will attend.

I don’t do that.

But I plan and coordinate events that my part of the community will show up to. I plan small social events around the main events. I make sure that those events work with the schedules of the people that I’m responsible for, and encourage them to come and bring their friends.

And I help out with small regional meetups, providing swag, as well as helping with (i.e., funding) travel and lodging for speakers that might not have budget to do that on their own.

Make personal connections

A major job of the community manager is to become an expert on the community members. Who knows what. Who is willing to speak on a particular topic. Who has the connections to make things happen.

Then, when a question is asked, or when someone has a need, it’s my job to connect them with the right person that can help them.

So … kind of like first-tier support, triaging problems, solving the ones that I’m able to, and referring to second-tier support those problems that are beyond my expertise.

There’s also some mentoring that goes in here – helping people new to the project know where to fit in, and where to find the information they need.

Look for stories

I look for stories of people using our project, and tell those stories to the world. In this part of the role, I’m the journalist, looking for ways to tell the story about how our project makes life easier. Much of this is amplifying stories that other people are telling. And then some of it is going out and gathering the stories, and then finding ways to tell those stories.

Everything else

While I don’t write code for the RDO project, I do a little bit of everything else – whatever people need done, I try to fill in, or find the right people to do those tasks.

So, that’s why it’s difficult to know how to answer when people ask me what I do at work.

Open source stats – but what do the numbers *mean*?

I recently sent a report to project management containing some numbers that purport to describe the status of the RDO project.

I got a long and thoughtful response from one of the managers – we’ll call him Mark – and it seems worthwhile sharing some of his insights. To summarize, what he said was, don’t bother collecting stats if they don’t tell a story.

1. Focus on the goals

Listing a bunch of numbers without context – even with pretty graphs – doesn’t tell us anything unless you relate them to goals that we’re trying to achieve.

Several weeks ago I presented a “stakeholder review” to this same audience. Any statistics that I present in the future should be directly related to a goal in that review, or they are just meaningless numbers, and possibly a distraction, and, worse still, might cause people to work towards growing the wrong metric. (Google for “be careful what you measure” and read any of those articles for more commentary on this point.)

2. Focus on the people

One of the stats that I provided was about how certain words and phrases feature in the questions on ask.openstack.org. Mark looked beyond the numbers and saw three people who are very active on that website, two of whom are not obviously engaged in the RDO community itself. Why not? How can we help them? How can they help us? What’s their story? Why are we ignoring them?

3. Focus on the blips

In February, our Twitter mentions, retweets, visits, and so on, went through the roof. Why? And why didn’t we do that same thing again in March?

As it turns out, in February there were two conferences that contributed to this. But, specifically, we captured a lot of video at those events, and the Twitter traffic was all around those videos. So clearly we should be doing more of that kind of content, right?

4. Ignore the stuff that doesn’t seem to mean anything

We track “downloads” of RDO, which roughly speaking means every time someone runs the quickstart and it grabs the RPM. Except RDO is on a mirror network, so that number is false – or, at best, it reflects what the trends might be across the rest of the mirror network. So we have no idea what this metric means. So why are we bothering to track it? Just stop.

5. Ask not-the-usual-suspects

This last one wasn’t one of Mark’s observations, but is what I’m taking from this interaction. We tend to ask the same people the same questions year after year, and then are surprised that we get the same answers.

By taking this data to a new audience, I got new answers. Seems obvious, right? But it’s the kind of obvious thing we overlook all the time. Mark provided insight that I’ve been overlooking because I’m staring so hard at the same things every day.

By the way, I’ve presented Mark’s insight very bluntly here, because it’s important to be clear and honest about the places where we’re not doing our job as well as we can be. Mark’s actual response was much kinder and less judgmental, because Mark is always kind and supportive.

3 ways you find the right type of contributor and where to find them

Another one of Stormy’s questions caught my eye:

“What are 3 ways you find the right type of contributor, and where do you find them?”

Thinking back to the last few years of work on RDO, several answers come to mind:

The people asking the questions

Watch the traffic on your mailing list(s) and on the various support forums. The people that are asking the most questions are often great potential contributors. They are using the project, so they are invested in its success. They are experiencing problems with it, so they know where there are problems that need to be addressed. And they are outspoken enough, or brave enough, to talk about their difficulties publicly, so they are likely to be just as willing to talk about their solutions.

These are usually good people to approach ask ask to write about their user experience. This can often be done collaboratively, combining their questions with the eventual answers that they encountered.

If they appear to be the type of person who is implementing solutions to their problems, ask them to bring those solutions back to your community for inclusion in the code.

In RDO, people that participate in the rdo-list mailing list will sometimes end up contributing their solutions to the project, and eventually becoming regular contributors. We probably need to do a better job of encouraging them to do this, rather than just hoping it’s going to happen on its own.

The people answering the questions

In watching the question-and-answer on ask.openstack.org I often see names I don’t recognize, answering questions related to RDO. Sometimes these are Red Hat engineers who have recently joined the project, and I haven’t met yet. But sometimes, it’s people from outside of Red Hat who have developed expertise on RDO and are now starting to pay that back.

These are the people that I then try to approach via the private messaging feature of that website, and ask them what their story is. This occasionally evolves into a conversation that brings them to more active involvement in the project.

Most people like to be asked, and so asking someone specifically if they’d be willing to come hang out in the IRC channel, or answer questions on the mailing list, tends to be fairly effective, and is a good step towards getting them more involved in the project.

The people complaining

This a tricky one. People complain because something is broken, or doesn’t work as they expect it to. The traditional response to this in the free software world is “Patches Welcome.” This is shorthand for “Fix it yourself and stop bugging me.”

The trick here is to recognize that people usually take the trouble to complain because they want it to work and they’re looking for help. This passion to just make things work can often be harnessed into contributions to the project, if these people are treated with patience and respect.

Patience, because they’re already frustrated, and responding with frustration or defensiveness is just going to make them angry.

Respect, because they are trying to solve an actual real world problem, and they’re not just there to hassle you.

It’s important that you fix their problem. Or at least, try to move them towards that solution.

Once the problem is addressed, ask them to stay. Ask them to write about their situation, and the fix to it. Ask them to stick around and answer other questions, since they have demonstrated that they care about the project, at least to the point of getting it working.

When people complain about your project, you also have a great opportunity to brush them off and persuade them that you are uncaring and unwelcoming, which they will then go tell all of their friends and Twitter followers. This can be a very expensive thing to do, for your community. Don’t do that.

When people come to #rdo on Freenode IRC to ask their RDO and OpenStack questions, I frequently (usually) don’t know the answer myself, but I try to make an effort to connect them with the people that do know the answer. Fortunately, we have an awesome community, and once you bring a question to the attention of the right person, they will usually see it through to the right solution.

Retaining community contributors

Stormy, at OpenSource.com, recently asked the question “What are 10 steps to keeping new contributors once you have their attention”

I’m not sure I have 10, but here’s what I’d say:

Celebrate their contribution, loudly and publicly

People like to be noticed, and they like to be thanked. Tell them that you noticed their contribution by telling the whole world about what they did.

There’s a number of ways to do this, from tweeting every first contribution, to including a Thanks section in your monthly newsletter, to doing a weekly blog post that lists new contributors for that week. Whichever approach you take, make sure that you personally send them a message telling them about it, rather than just hoping that they notice it.

If you have very few new contributors every week/month, then take the time to describe what the new contributor did. If you have dozens every time, this can be more of a challenge, but sending them a personal note is still a very critical part of the process if you want them to stick around.

Give them the keys

A lot of people in open source think that everyone should have to earn their place on the contributor list, by consistent, high-quality contributions over a long period of time.

I’m at the other end of the spectrum. I think you should hand out committer rights like candy. If someone shows initiative and contributes once, give them the opportunity to contribute again, immediately, with no barrier to entry.

What’s the worst that can happen? You have to revert a patch. This is why you have revision control.

So, give them the keys on day one. But there’s a caveat here, which is the next item on my list:

Give constructive criticism

Nobody likes a patronizing pat on the head. Give constructive feedback. After thanking them, tell them patiently and kindly what they can improve. This shows that you consider them to be a contributor to a serious project, and not merely a statistic to report to your boss.

If you have a style guide, and they didn’t live up to it, point them to it, gently and kindly, and give them specific pointers on what they need to improve.

Don’t be one of those jerks that throws it back in their face with a nasty remark. That will guarantee that they won’t come back. Remember that your goal is to retain new contributors, and train them up in the way that your project operates, not merely to act as a filter to keep out unfavorable contributions.

Ask them to do it again, with a specific request

People like to be asked. Asking someone, personally, to do a particular task, is much more effective than a shotgun “Hey, can someone …” sent out to an anonymous faceless mob on a mailing list.

Once someone has contributed something, that’s your opportunity to say, “Hey, I notice that you have some interest in the WhizBang feature, and Ticket 31245 is about that, too. Maybe you could take a look?”

Ask them to write about it

The new contributor experience is a rare and valuable thing. You don’t know what it’s like any more. You remember bits of it, but mostly you’ve forgotten, and become jaded with your second, third, and 700th contribution.

Encourage this new contributor to write about their experience. What was too hard. What was fun. What was unexpected, frightening, exciting. Who helped them. Who got in their way.

These are hugely valuable data points for your project. And they are also a great way to tell this new contributor that their input is valuable, and that you’re trying to make your project more welcoming.

And, of course, once they have written about it, share it with the developer community, along with the name of the contributor, and say, here are some ways maybe we can make this better for the next person.

Point them to the documentation

You have docs, and then you have hidden docs, and then you have the stuff that “everybody knows”. Steer this new contributor to the docs, and take the opportunity to turn the other two categories into actual docs.

Some of this will come out of the blog posts that these new contributors write. Some you will need to write yourself, based on their feedback of the new contributor experience.

This is tedious, but, remember, you’re making an investment in the next time. The better you make this process, the easier it will be for the next person, and the sooner you can pass this part of the job on to someone else.

Ask them to mentor the next new contributor

Ask them to turn that first-timer experience into mentoring another first-timer, as soon as possible. They’ll have the recent experience. They’ll know the potholes that you have long since learned to steer around. They’ll know which people in the community are helpful, and which ones are jerks, who you’ve long ago dismissed as “Oh, that’s just how Larry is.”

Too many beginners

Last weekend at FOSDEM I gave my “Write A Better Manual” talk. I got a question afterwards that I’ve never actually received before:

We’ve done such a great job of attracting new members to our community that it’s causing a problem. Our lead developers are spending all of their time mentoring beginners, and no code is getting written. What do we do?

Once I got over my “I wish I had your problem” moment, we had a great conversation about concrete ways that you can address this problem. And, of course, it is actually a problem, because it can lead to the demise of your project every bit as much as not enough new community members.

Here’s some things that you can do, even if you don’t have exactly this problem:

Turn the beginners into mentors

Someone has just come to your community, and asks a question. It’s one of the questions that you get every day, like “how do I find my IP address?” or “how do I connect to a wireless network?” or “where is the toilet?”

Rather than answering the question yourself, ask the not-quite-beginner to answer it. This does many things at the same time. It saves you the time and trouble of answering. It indicates your confidence that this person is part of the team. It lets this person know that it’s ok for them to start mentoring other people. And the next time the question is asked, you won’t even have to say anything – they’ll just answer it. You’ve taken the first step to making a mentor out of the mentee.

Take shifts

Mentoring beginners is amazingly rewarding, but it’s also exhausting. You shouldn’t have everyone doing it, and you shouldn’t have the same people doing it all the time. Take turns. Even go so far as making a rotation schedule – one week on, 3 weeks off. Your mentors will come back rejuvenated and ready to start up, and will get “off shift” just about the time that it’s starting to be frustrating.

Know when to quit

Even if you don’t take specific shifts, mentors should be told that they can, and should, take breaks. Mentoring is incredibly important, but it’s only part of your “job”. Work on code for 3 hours for every hour you spend answering questions on IRC. Or something like that. You’ll find that if you set yourself a specific quota of mentoring time, you’ll look forward to it more, and you’ll be more effective at it.

If you’re not good at it, don’t do it

Finally, some folks just aren’t that great at mentoring. Either they’re not very patient, or they’re not great at communicating, or maybe they’re just too valuable at writing the code or the docs, and should stick to that.

These people should be encouraged to stick to what they’re good at, because, frankly, some people do more harm than good when it comes to talking to beginners.

Celebrate your problem

But, at the end of it, recognize that most projects would love to have the problem you’ve got. Celebrate your beginners. Bring them along. Eventually, they will “graduate” and become the core of your community.



Project Leader

I was recently asked to write something about the project that I work on – RDO – and one of the questions that was asked was:

A healthy project has a visible lead(s). Who is the project lead(s) for this project?

This struck me as a strange question because, for the most part, the open source projects that I choose to work on don’t have a project lead, but are, rather, led by community consensus, as well as a healthy dose of “Just Do It”. This is also the case with RDO, where decisions are discussed in public on the mailing list, and on IRC meetings, and those that step up to do the work have more practical influence than those that just talk about it.

Now, this isn’t to say that nobody takes leadership or ownership of the projects. In many senses, everyone does. But, of course, certain people do rise to prominence from time to time, just based on the volume of work that they do, and these people are the de facto leaders for that moment.

There’s a lot of different leadership styles in open source, and a lot of projects do in fact choose to have one technical leader who has the final say on all contributions. That model can work well, and does in many cases. But I think it’s important for a project to ask itself a few questions:

  • What do we do when a significant number of the community disagrees with the direction that this leader is taking things?
  • What happens when the leader leaves? This can happen for many different reasons, from vacation time, to losing interest in the project, to death.
  • What do we do when the project grows in scope to the point that a single leader can no longer be an expert on everything?

A strong leader who cares about their project and community will be able to delegate, and designate replacements, to address these concerns. A leader who is more concerned with power or ego than with the needs of their community is likely to fail on one or more of these tests.

But, I find that I greatly prefer projects where project governance is of the people, by the people, and for the people.

Living in community: Curbing your passion

I’ve had a very frustrating set of interactions over the last 3 days, on an open source community mailing list. Doesn’t matter which one, because I think that these things are universal.

I said “here are some ways we can make things better.” Or, at least, that’s what I thought I was saying.

Several people heard “everything is broken, and it’s your fault.”

At the end of several very heated email conversations, it became clear to me that we all agreed on (almost) everything, and were getting hung up on that initial statement. It wasn’t even that the things that I was proposing were opposed, it was that the way that I presented them was perceived as criticism of what people had done for the last few years.

Email is notoriously bad at conveying nuance. This is amplified in a multi-cultural, multi-lingual community.  Here’s some practical things that I took away from this conversation – most of which I should have already known

Suggest improvements. Don’t focus on shortcomings

Pointing out breakage is easy. Proposing solutions is where the real work is. Now, sometimes, you need someone to say “this is broken and I don’t know how to fix it.” Those situations are very tricky. Tread lightly.

Focus on what needs improving, not on who made it that way

This sounds easy, but is really hard. There’s always someone who spent hundreds, or thousands, of hours, making the thing the way that it is, and so when you point out that the thing isn’t perfect, that person might take it personally. I honestly don’t know how to avoid that, and this week has shown that very clearly. But I can look back and identify some of the things I did poorly, and apologize for them.

Curb your passion

This one is unintuitive. We need to be passionate about our community. But sometimes when you’ve been pondering something for a few months and arrive with all of that passion, people are more likely to mistake that passion for anger, criticism, and so on.

Yes, some people need to get thicker skins. Don’t read everything I’m saying as that we need to pamper everyone’s bruised feelings. But when people aren’t looking in your eyes, it’s easy to take passion as an attack. We’ve all done it.

I’ll close with one of my favorite quotes from Confucius, who said, “There is honor in the email not sent.”

Yes, he said that. I was there.

Read your email twice before you send it, and delete half of them unsent. This will lead to a better universe, and fewer three-day shouting-fest email threads.


Features, not lies

A colleague is attending the nginx conference in Austin this week, and shared with me several anecdotes in which a speaker preached misinformation – or if I want to be generous, grievously outdated information – about Apache httpd, to support the notion that nginx is better.

This led to the following:


Each time I have encountered nginx people at conferences, and attended their talks, they have compared nginx to grossly misconfigured, 10 year old installations of Apache httpd 2.2 to support their claim that nginx is leaner, faster, and easier to administer.

Here’s the thing. nginx is a solid project. I have zero beef with the software itself. I have used it myself, when the need arose. What I object to is the habit of the fans of nginx to lie (or exaggerate, or just spout uninformed opinions) to make themselves look better. If you must compare, compare our latest to your latest, and have experts correctly configure each. That way, each will show where it shines, and where it doesn’t.

It is possible to configure ANY software badly. This is why it’s almost always a bad idea for an expert on SoftwareA, who knows little or nothing about SoftwareB, to compare them head to head – they’ll invariably be comparing a well-configured A to a less than optimally configured B. And in the case of nginx vs Apache httpd, these guys almost always use 2.2 or 1.3 as an example of … well, all of the things that 2.4 fixed. 5 years ago.

Any intro to marketing class will tell you that you need to talk about your own strengths more than you talk about the other guy’s weaknesses. This is a message that nginx and presidential candidates seem to have missed. And, in the case of software, it’s even more important, because whereas Donald Trump will always be a monster, every time you point out a legitimate shortcoming in Apache httpd, we fix it.


In a talk I attended earlier this year, Shaun McCance mentioned, as though it was established science (which it is) the 90-9-1 principle of community participation. I’ve thought of it frequently since then, to set expectations and to keep myself sane.

The idea is that in any community effort, 90% of the people are going to sit around saying that it’s a great idea, but not actually doing anything about it. 9% of the people are going to work casually on it in their spare time, as convenient, and between them will do a huge amount of the work. Then 1% of the people – usually one or two dedicated people – will pour themselves into it wholeheartedly, putting every spare moment into making it a success.

Note that it’s not the exact numbers that matter here, it’s the undeniable fact that you can’t expect everybody to work as hard as you do on everything. It’s all too easy, when doing anything on a volunteer basis, to look around and get frustrated, discouraged, even angry, at the 90%. Understanding that this is the normal, expected, even healthy way that communities operate, can help you refocus on what you can (and can’t) do in any given effort.

Sometimes (most of the time) it’s ok to be in that 90%, and you don’t need to feel that you’re not pulling your weight. However, if you’re in the 9% or the 1%, it’s not reasonable to get angry with the 90%. They have other things to do, and are likely the 1% on something that you’re not helping much with.

By the way, here’s a couple of resources about this notion:

This article claims that the concept is dead. Note that this article appears to be someone just making up new numbers to illustrate the same concept. What’s important here, folks, isn’t the exact numbers, but the general concept. Way to miss the point. (This article also appears on dozens of sites in various different forms.)

Wikipedia claims that it’s a feature of Internet culture.

Here’s an actual statistician doing scientific analysis, rather than me making up numbers.

Paul Biondich keynote, LinuxCon Europe 2014

In his keynote yesterday, Paul Biondich mentioned a few numbers – OpenMRS has been in development since 2008, and is deployed in over 70 countries – but mostly, the number he focused on was one – individuals whose lives have been touched by the project. Doctors, patients, and Open Source developers.

I’ve been following OpenMRS for several years, since discovering the project while I was working at SourceForge, and learning that it was started by a visit to Kenya, to a hospital where paper-only medical records were hampering patient care. The trip, which Paul almost declined to go on, changed his life and the course of his career, and he began to devote his time to developing OpenMRS, which is now the standard medical records system in many countries, including Kenya.

Paul observed that medicine is, in large part, an information science. Having access to the right information at the right time can be the difference between the life and death of a patient. Of course, it’s only one tool in the toolbox, but it’s a critical one.

Paul, and all the other people at OpenMRS, have long been an inspiration to me, and represent all that is good and noble about Open Source. His keynote is well worth watching once the videos are posted.