Seven questions to steer open source project community development

In my role as a community architect at Red Hat, I advise a number of project leaders on the ways in which they can develop the audience and community for their projects. In that capacity, I often talk to the leaders of projects with which I am not very familiar. Over time, I have found myself asking the same questions over and over, and I have found them useful, not only to help me understand the projects, but to help the project leaders understand what they are trying to achieve.

I have asked these questions so often, I have created a template that I use during these conversations, to take notes and share the results with the project leaders afterwards. In this post, I will run through the seven questions I ask, and how the answers to these questions can shape all follow-up recommendations for community development.

What is the project?

This should be a very basic question. What I am looking for here is how the project helps its users. What problem does it solve? How would you describe your project to a potential user of the project, in the most succinct terms possible that they would understand?

All too often, open source projects describe what they are in terms of terminology that is unfamiliar to many potential users, or focus on how they do what they do, rather than the problems they can solve. 

For example, if I ask an Istio developer what Istio is, the most basic answer is “it’s a service mesh.” I would argue, though, that most container application developers do not have an understanding of what a service mesh is. The shorthand doesn’t help me understand if I should use it. A better explanation might describe Istio in terms of an application data plane and control plane, if I am talking to someone from the networking world, or perhaps a concept of traffic cops assigned to components of an application if I am explaining the project to someone unfamiliar with the concept of a service mesh.

When I ask this question, I ask as many follow-up questions as I need to in order to understand the project and what it can do, to a level where I can explain it to someone else.

Who are its users?

Many open source projects do not have a very clear understanding of who uses their projects, and what those users do with them. In the past, I have used the concept of personas to characterize archetypes of groups of key users of a project (as popularized by The Inmates are Running the Asylum by Alan Cooper), and more recently I have been thinking in terms of “jobs to be done.”

I like to categorize a project’s potential or current users with a number of criteria.

• Is the project more useful to an individual, or to an organization?

• Is your project particularly useful in a specific industry vertical or business domain?

• What size of organization will find your project most useful? Are you targeting sysadmins in large enterprises, or the small and medium business space? 

• What are the job titles of the people who will be downloading, installing and using your project? Are they the same people, or are the users different from the project administrators?

• What is the relationship between the people who download and install open source projects, and the people who evaluate and purchase commercial products?

The priorities for how to structure the project, where to promote it, and even the engineering effort you will put into certain features, will all change based on the answers to these questions.

For example, if your project runs in a datacenter or on a cluster of servers, your audience will typically be a business audience, people running IT professionally (or as a volunteer in a university). For a mobile application or a web development framework, the majority of your audience will be running your project on their personal computer, workstation, or cellphone. The resource prerequisites change, and the problems and motivations are different, for these groups.

Understanding the relationship between project users and product buyers is critical for any company creating an open source product strategy. The adoption of open source into a company is not a straight line between use of an upstream open source project to conversion to an enterprise open source product. What I've seen is that open source adoption is grass roots, bottom-up, while enterprise open source products are often evaluated and purchased top-down. The adopters of an open source project inside a company can be a valuable influencer for a purchasing decision, if they are connected to the purchasing process, or if the person responsible for purchasing is aware that their company is already using the product.

How do you engage with your user base today?

Once people are turning up to your project, engagement is key to growing your user base and community. There are many ways to engage with your users, requiring different amounts of effort, and giving differing outcomes. 

It can be hard to figure out where you should focus your efforts. It is useful to take stock of all of the ways that you are currently engaging with project users, in order to identify blind spots and easy opportunities for improvement. It is useful to categorize these as low, medium, and high touch (terminology borrowed from sales). Low-touch methods represent very little interaction between potential users and your community, while high touch methods represent one-to-one or one-to-few efforts.

Here are some examples of the types of things you can categorize this way:

• Low touch: Website, documentation, online training, newsletters, podcasts, blogs.

• Medium touch: Mailing list, bug tracker, community forum, conference presentation, webinars, user groups.

• High touch: Phone calls, one-on-one or one-to-few training, conversations at conferences, community meetings.

Ideally, your project will have a healthy mix of each of these. Your website, documentation, and promotion content is a great way to help new users to be autonomous without needing help from a senior community member. 

Your bug tracker, mailing list, and forum provide opportunities for community members to engage with your community, ask questions, provide feedback, and gives you an opportunity to find out more about how people are using your project. Finally, the high-effort activities like training, conference booth attendance and follow-up, and in-person conversations can be very valuable on a one-on-one basis, but do not scale well.

When thinking about how to balance effort in these activities, I find the funnel model used in sales to be useful.

Low-touch activities are good for raising awareness of your project and getting people to look at it for the first time. It is well worth effort to ensure that new users have a clear understanding from your web site and other materials what the project does, how it can help them, and how they can try it out and get started quickly.

Medium-touch activities are great for creating a “center of gravity” around your project--making it possible not only for you to communicate with your users, but also enabling your users to help each other, and create a network effect. And high-touch activities are great for building relationships with key community users, gathering community case studies, and helping larger groups to be productive and to become advocates for your project.

A key consideration when crafting all of these engagement paths is to consider how someone who is unfamiliar with your project might start using it, and over time gain seniority in your project, to the point of becoming a core contributor.

What alternatives are there to your project?

You can tell a lot about a project by who they compete with, or what other projects people use to do the same job. If your project doesn’t have any competition, why is that? Is it in an emerging technology area? Are there projects that people are using to do the job that your project does, in a different way? 

If there are other projects that do the same job, but no clear leader, how are they approaching the problem differently from you? If there are open source competitors, is joining them rather than trying to compete an option? If not, why not? If you have a competitor who is an incumbent in the market, what can you tell about them, and about their customers?

Analyzing your competition can help you answer a number of key questions in the early days of a project. Who are your competitor’s customers? What do they have in common? What are their motivations for using the competitor, and what are the pain points that they have? 

Answering these questions will help when it comes time to prioritizing features, and deciding how to contact your potential users. Perhaps you can piggy-back on the existing gatherings that people are having related to your competitor’s technology to spread your message. 

If you are an upstart disruptor, then your messaging will be anchored to your competition - “cheaper than…”, “an open source alternative to…”, “simpler and faster than…”. If you are in a new market, and your project is in a land grab, you will need to focus on spreading your message fast--which means a higher marketing budget or more aggressive community plan, and more focus on defining the problems you solve for potential users.

Are there adjacent projects you are closely associated with?

If your software is frequently consumed with, or is particularly useful to users of, another project, then that presents a great opportunity for you to grow the awareness of your project in its early stages, and to understand your user needs better. For example, Ceph can be used to manage storage for OpenStack or Kubernetes. For Ceph, these are adjacent communities. Catering to adjacent projects to find an audience may affect your technology roadmap, the events you target, the effort you put into specific integration projects, and so on.

An adjacent project provides you with a potentially friendly audience who have the problem that you solve, and who you can engage in market research, UX testing, a natural set of events to engage to raise awareness and meet potential users. This is also connected to understanding your competition. The communities that are important to them will be important to you too.

What are your goals for the project?

The existential question for every open source project is “why does this project exist?” Specifically, for a project which is released by or driven by a vendor: what do we want to achieve by investing in this project? Surprisingly, many projects have difficulty answering this question.

As a vendor: why did you open source this piece of software? Are you trying to grow a market, promote a standard, disrupt a competitor, or increase demand for another product in your portfolio? Each of these requires a different message, and a different set of investments.

Understanding your reasons for open sourcing the project will help you clarify the investment required to achieve your goal, and will help you stay aligned across engineering, product, and sales teams down the road. In the absence of a strong common vision for the project’s goals, you may find yourself under-funding the open source project, in part because it is perceived as competition to the products you build on top of it.

A good open source product strategy provides clarity on which markets you are targeting, the market segmentation between product and project, and the role that the project plays in your entire business strategy and product portfolio. Clarifying these things will pay dividends when discussing the technical roadmap, or the relative prioritization of community promotion vs sales lead generation.

Who are your key stakeholders?

There are a small number of people who will care deeply about your project, and can represent a group of people or interests which affect the project. These people are your stakeholders. In the case of vendor-sponsored projects, they will typically include an engineering lead, product management, product marketing, and a representative of the field (field engineer, sales). 

You may also want to include someone from your content services or support organizations, and product security. This is the group of people you will brief to prepare a stakeholder review, and you should gather them once every six to 12 months to check in on the state of the project and ensure alignment on the goals and the required investments to achieve those goals.

Conclusion

These seven questions provide a single-page document which is a baseline, a frame of reference, for any planning conversations. After running this exercise, you should have an understanding of what problems your project solves, and for who. You will be able to express it in language that makes sense in your potential users’ frame of reference. You will understand how your project fits into the market, and what you want to achieve with it. 

Finally, you will have identified the key group inside your company who should be aligned on your current status and future strategy. Combining the answers to these seven questions together, the next steps usually become obvious to all involved, and will help your project be more successful in achieving its goals.