In August 2015, George Zhao of Huawei, formerly the OpenDaylight release manager, was assigned to be OpenDaylight community manager full time, a role that I had been filling on a part-time basis since October 2014. To help him ramp up as a first-time community manager, I agreed to mentor George. In the course of working together, I have had the opportunity to structure some of the things I have learned in my career, and pass them on to him.

This series of articles, resulting from my conversations with George, is a collection of personal thoughts and analysis on community management, which I hope will be useful to others.

(Check out Part 1 in this series.)

Where Should I Focus?

The first and biggest challenge for a new community manager is deciding where to start. Every community member will have their own set of problems they want you to solve. In addition, every open source project has a common set of challenges around maintaining an up to date website, maintaining high editorial standards and structure in the wiki, promoting the project and growing the user community. On day one, you will have a long TODO list.

The great thing about TODO lists is that they are never empty. For a community manager in a technical community, this is doubly true. If you are doing your job well, your community will be growing, and that causes scaling issues to arise all the time. You will continually discover things which would make life better for community members, the further down the rabbit hole you go.

That creates a problem—what is the most important thing for me to do today, this week, this month? Do I focus on bigger, longer-term tasks with a big potential pay-off, or smaller tasks which will make a difference now, but are not changing things very much? Is it more important to grow the developer community by recruiting a new partner, or to grow the user community by removing a click from the download process for end users?

To help address the issue (without even trying to answer the question—sorry!), there is a framework I like to use when thinking about prioritization at a week, month and release cycle scale. The foundational element of the framework is the recognition that there are multiple community types in an open source project, and for different projects, different communities will be the top priority at any given time.

The Four Communities

Painting with very broad brush-strokes, an open source community can have four different types of communities.

  • Core developers. Your core developer community is the group of people who collaborate on the creation of your main project. I see this a bit more broadly than some others, in that I consider people who are not primarily code developers, but who are participating actively in the project's core infrastructure (git, gerrit, mailing lists) as part of the core.
  • Engaged users. These are people who are using your project. Your goal is to engage them, to the point that they are actively engaged in your community, and would consider themselves part of the community.
  • External developers. Anyone who builds on your project as a platform—this will include anyone who packages your software and integrates it with their platform to deliver it to their users, or ISVs who build on top of the platform, or vendors who embed your project into their offerings. These people are economically motivated to see the project do well, but may not consider themselves part of the community.
  • Target audience. This is your growth vector for your user community - people who have a problem your software solves, but who are either unaware of your project, or have not tried it yet.

Gradient Graphic

These categories blend into each other, as people get more and more engaged in your project—for example, when a developer engages your project for the first time to make a change, they are neither a core developer or a completely independent observer, and similarly when a casual user uses your software, but has no contact with your community, they are more than just part of your target audience.

Balancing Impact and Effort

These types of communities require different sets of activities, with different levels of commitment, to grow. One shorthand people use for these types of activities is high, medium, or low touch activities. A community manager needs to balance their time between all such activities:

  • "High touch" activities give an interactive experience. They require a large time and money investment, but give a very high bandwidth experience to a small number of people (training courses, mentoring, local events)
  • "Medium touch" activities are less interactive, but usually involve a real-time element. They take less time to organise, and have a larger reach, but do not give the same rich experience (event presentations, webinars)
  • "Low touch" activities involve no contact with the people consuming the content, but can have a much broader reach (video tutorials, documentation, blog posts)

The best activities combine some of these—conference presentations are often recorded and can be consumed by others weeks later, you can create speaker notes as a leave-behind or blog post for a presentation, training material can be repurposed as a book, blog post series or presentation series.

In general, you will want to mix high, low, and medium touch activities. To get the right blend, you will need to think about the costs and benefits of each.


Deciding where to spend your time is one of the hardest things to do. In the absence of a decision, you will find your time is spent managing urgent issues without a clear roadmap for what you want to achieve with the community. A good community manager must balance short-term needs of the community with the longer-term goals they have set themselves around community growth and development.

In the absence of a decision on areas of focus, the decisions about how to spend your time will be made by others. Once you have decided on a focus, you can then decide on what to do to help that audience. As in life, a mix of approaches tends to work best, with some low-touch activities to enable the motivated self-sufficient learner, mixed with regular medium- and high-touch activities to help those who look for a more intimate approach.

The next article in the series will break down audiences according to their needs, and which activities give a good return on invested effort.

About the author

Dave Neary is the Field Engagement lead for the Open Source Program Office at Red Hat, communicating the value of open source software development to Red Hat customers ad partners. He has been active in free and open source communities for more than 15 years as a consultant, community manager, trainer and developer. In that time, he has worked on advising companies in finance and telecommunications industry on effective adoption of, and participation in, open source projects.

Read full bio