Bonus points for those of you who can guess where the main image for this post is from.

One of the interesting elements of working with a range of different companies is being able to better understand the dynamics that influence how well a community will succeed or fail. These dynamics are many and broad, and include having a solid strategy, the right balance of transparency, executive and frontline and support, simple and sensible tooling, and more. Sadly, the availability of gin plays no concrete role in this success. Bah humbug.

Within the context of companies building a community around a product, one of the most critical influences of this success, frankly, is having a product that (a) people actually want, and (b) that they can wrap their heads around it.

This may seem obvious, but it is more complex than it may seem. If you look at the rich tapestry of open source, you have some very popular projects that serve broad needs such as Kubernetes, Node.js, Git, Docker, Angular, and others. But then, you have projects that serve very niche needs such as OpenMRS, SymPy, Astropy, and eht-imaging. All of these projects are thriving open source communities.

Now, for some companies watching these projects growing in adoption and market recognition, it can generate a seemingly logical conclusion:

“Surely if we open source our struggling project on GitHub or GitLab we will attract an audience of users and developers, and therefore help our broader market success, right?”

Well, Danger, Will Robinson.

A Balanced View

While there is little doubt that open source can have a heck of an impact on projects, products, and companies, the way in which you accomplish this impact needs to pull together four key components:

1. Product – firstly, you need to have a product that the market wants, that can add value for your target audience, and maps well to your chosen open source model.
2. Product/Engineering Workflow – secondly, if you are going to run a public open source project, you need to ensure your product and engineering teams can operate with an open, asynchronous workflow and can interface with public contributors.
3. Community Strategy – thirdly, you are going to need a clear, unambiguous strategy for how you structure your community, hire the right team members, target the right audiences, build growth, and more.
4. Internal Capabilities – finally, you are going to need to develop the skills in your company to accomplish all of the above. This will require staff training, support, mentoring, and leadership.

Now, often when I am brought into a company, the client is typically very interested in focusing on points 2 – 4. After all, this is what a lot of people associate with the work I do.

My first questions though almost always focus on (1). Is the product you have suitable for open sourcing, and will open sourcing it bring you and your prospective community the value you and they want?

Open source is not a panacea. It is not a solution that will revive an uninteresting or poorly built product. I never recommend anyone goes down the open source road until they have assessed this important product suitability consideration first. Otherwise, they risk doing a lot of work for very limited benefit for anyone.

Essential Questions To Ask

Here’s the deal: open source requires a careful balance of open workflow, community/contributor management, and a clear delineation of where the lines are drawn between your open source and non-open source projects (and which teams work on what.)

To put it rather glibly, open source is not as simple as chucking some code into a public repository and blogging about it. It requires a careful balance of internal and public workflow, and needs a significant investment of time and energy to do well. As such, you want to be sure that this time and energy is not just worth it, but has a realistic chance of success for both you and your community.

When you are considering this, I recommend asking yourself 4 key questions:

#1. Is there a market need/fit for your product?

Open source has become increasingly interesting to companies who want to get developers using their product or platform. Developers are increasingly influential decision-makers in modern tech firms, and often prefer open source platforms.

Put the open source element to one side though and ask yourself the objective question, “Does your project serve a clear need and deliver enough value for your target audience?”

The #1 thing your audience are looking for is clear, valuable functionality. Does the software do something that pragmatically make your audience’s lives better? If it doesn’t deliver this, no amount of open source will save it.

So, try to understand what your core audience want and ensure your project can deliver it. If this is a new project, publish a roadmap for these key target features and focus on staffing the delivery of them. A compelling 1.0 is essential to interest both users and potential contributors.

#2. What is the on-boarding experience like for new users?

On a related note, how easy is it to get started using your project? Can a new user get up and running and experience tangible value within 10 minutes? No? Then you you need optimize your on-boarding experience.

I have seen some bloody horror stories here: projects that make users jump through endless hoops, require complicated configuration (with little to no documentation), have dependencies on obscure or unavailable services, and other dents in the experience.

This is the model I have developed over the years for thinking about building a clear onramp:

Your audience should be able to proceed simply and logically from one step to the next ultimately getting to the star, which is a piece of tangible value for them (e.g. completing a task, solving a problem, etc.).

Now, while every project will use a slightly different set of steps, an onramp generally breaks down into understanding value, setting up tools, learning skills, and using the tools and skills to produce something valuable. (1) and (6) are highlighted in the above graph because they should be on every onramp: you always need to communicate the value of your project (such as via websites, social media, etc) and validate the people who use it successfully (such as with rewards, engagement, and opportunities). The latter is especially important for building lasting relationships with your community.

Think about how to simplify the overall onramp (you should explore how muntzing can help here). Then, ensure that each transition from one step to the next step is logical and try to understand and resolve where people get stuck.

If you don’t do this, you will struggle to build a userbase for your project, which is a critical requirement before you can consider developing a contributor-base.

#3. What are your primary goals for open sourcing it?

The next question is why are you are open sourcing your project in the first place? From a company perspective this can vary and will often include one or more of the following:

• We want to increase market awareness and adoption.
• We want to increase engineering contributions to the project.
• We want people to build on top of the project (e.g. plugins or modules.)
• We want to increase the company’s brand recognition.
• . . .

This is where things can get complex: open source projects can often lead to many of the benefits listed above, but it is not just the nature of being open source that will drive these benefits, it is the focused strategy efforts you put in place that will.

For example, if your goal is “increasing engineering contributions”, putting code in a repo will not merely lead to this. Clear developer on-boarding, solid documentation, building meaningful community relationships with developers, developer focused content and outreach, and other efforts will help drive this growth.

The risk some companies face here is that they think of the value of open source primarily from their own perspective, but don’t focus enough on what value their users want to experience too. How can you build an open source community that gives your users greater information, flexibility, and communication with the project and your team? How can your users play a more meaningful role in the project? If you build an environment with your users’ needs in mind, you will build a a far more engaging and valuable community in general.

#4. What new skills and resources do you need to build in your company to do this work well?

It took me far too long to realize that a significant determining factor of community success is not just making the right strategic choices, but also baking those skills effectively into an organization.

For many companies, switching to an open source model is a significant change of workflow, policy, and how you incentivize your team. Aside from picking the right set of open source strategic steps (such as how you publish code, manage issues, build community engagement and growth etc.), you should also plan for how to bake these skills and expertise into your teams.

An an example, one key element of being an open source project is receiving and responding to pull requests with new features and fixes. This requires your team members to be able to review those PRs, test them, provide constructive feedback, and approve or reject the contribution based on merit. It requires calm and constructive feedback, often with people you don’t know and trust yet. It requires the overall code review process to happen end-to-end out in the open. Overall this needs a nuanced set of skills such as peer review, technical collaboration, open build management, and other pieces.

For companies less familiar with open source, this is all going to seem a bit weird and uncomfortable. Your team members are going to hesitant to engage, not only because it is new, but they also don’t want to put a foot wrong and get in trouble. This is entirely normal.

As such, think about how to break these skills down into simple pieces, provide the right level of training and support, and how to mentor and support people through this transition. Help them to build a habit around participation, and develop incentives, rewards, and other mechanisms to help them naturally orient to an open workflow and enjoy engaging in it.

Open source is an enormously powerful model, but focusing on these core product questions is an important part of the process. What other considerations should companies be making? Share them in the comments…