In conversations with founders, one question came up repeatedly: “How do you build a community around an open-source project?”

“Build it, and they will come” obviously doesn’t work. Sometimes, a project gets a lot of popularity overnight. That’s fantastic! But it is more likely that you have to do a lot of hard work to build and nurture your community.

This post is for you if:

• You are working on an open-source project
• And your goal is to turn the project into a business

The goal of this post is to help you on day 1, right after you’ve started your open source project when time and money are limited.

1. Track Everybody Interacting With Your Open Source Project

To start a cult, you need to get your first follower - the crazy one who sees value before anyone else. That first person legitimizes you and makes it easier for everybody else who follows.

When you start something new, only two things matter:

• Talking to users
• Building the product

The faster you achieve product-market-fit (or project-market-fit), the better. I found the best way to stay in touch with early users and people who interact with your open source project was by setting up a simple spreadsheet.

In the beginning, it can be as simple as a list of names, GitHub handles, email addresses, and how these people interacted with the project (e.g., created a new GitHub issue, responded to one of your tweets, was interviewed as part of our user research, etc.).

Your spreadsheet becomes your single source of truth for everything related to your community. It may start as simple as a list of people. Over time you expand it adding more information. A couple of examples:

• Add a note to annotate why somebody uses your open source project (work, fun, etc.)
• Add the user’s company/employer

These details help you understand where you are getting traction, what type of developers use your project, and who potential customers might be down the road.

Until you hit ~50 users who regularly interact with your project, there’s no need for automation. You will likely know most of the names, GitHub handles, or issues people bring up from the top of your head.

Don’t worry about doing things that don’t scale!

The advantage of the spreadsheet is the flexibility it gives you. It’s easy to adapt and change; you can add information, remove it, adjust it to your needs and share it with others in your team quickly. It’s a low-maintenance tool that gets the job done in the beginning. Once your community has grown beyond 50 users, you should migrate to a tool like Orbit.

The mere existence of the spreadsheet won’t do anything good. So how should you leverage it?

• Reach out to these people when thinking about building a new feature to get their feedback
• Invite everybody personally to office hours to bootstrap the attendance
• Ask active users for testimonials or case studies (especially if they are using your open source project at work)
• Convert people over to Discourse/Slack when you see them engage regularly
• Send swag - people love branded things

2. Build in Public by Default

Building in public is incredibly powerful. It doesn’t require you to be on Twitter 24/7 and write a blog post every week. The simplest, high-leverage trick I found is to change your engineering team’s mindset to build in public by default.

What does it mean?

• Leverage public GitHub Issues for everything that’s not explicitly confidential/sensitive (nearly nothing should be because the open-source project and not your future proprietary product should be what matters early on)
• Skip any internal engineering/onboarding documentation and put everything into your public docs
• Leverage a public Discord/Slack to collaborate and keep the number of internal/non-public channels to a minimum

The last point has an additional benefit. It helps you to bootstrap your community in Discord/Slack. If a new user or contributor shows up, the person will immediately see the energy and activity that’s already going on. To achieve that when using separate tools for public and internal communication is much more challenging. If you don’t know whether Discord or Slack is the right tool, look at this blog post.

All of this requires minimal effort. You would do the work anyway, but you might not have done it in public.

3. Do Recurring Office Hours

One of the most exciting moments in a week is when you demo the last product improvements to your team. You might do this on a Friday afternoon, or earlier depending on your team members’ different time zones.

Schedule office hours and share company progress publicly with your community.

Initially, keep your expectations low. The chances are high that nobody will show up. But it doesn’t matter; keep going. You would do demos as a team anyway. It’s critical to make it a habit, schedule them out many weeks in advance, and stay consistent. E.g., every Thursday morning EU time, and every Thursday afternoon US West Coast time.

Additionally, publish an agenda (publicly, of course) and record everything (post that recording too).

Over time people will start to show up. When it happens, engage the attendees. Do Q&As and ask for feedback. As soon as you get your first contributions, ask them to demo during the office hours.

It doesn’t always have to be a demo. Talk about your product roadmap or future capabilities, or interview a user to speak about how they use your project. The important thing is to do it in public.

4. Publish a Newsletter Regularly

This one requires a bit more effort, but you can still keep it simple.

Pick a tool like Mailchimp and publish a newsletter regularly. Even once a month is already impactful. You might struggle with the first few editions because you don’t think the content is exciting enough. If that’s the case, simply share the recording of the last office hour you did and the link to the agenda for the next one. Starting a newsletter is step 1, doing it frequently is step 2, and improving the content is step 3.

Share anything else topical that has happened since the previous edition. E.g., talk about the most relevant GitHub issues or new capabilities you’ve added. You can also show your roadmap of upcoming features, a list of events where you will be talking about the project, or highlight any contributions.

One channel won’t cut it - you need to share everything you do in multiple channels to reach everybody.

Don’t assume that your users are all the same. People consume information in different ways. Some people might never attend an office hour but like to watch the recording. Others are active users of your project and submit GitHub issues frequently but aren’t active on Discourse/Slack.

One small trick that helps to get more sign-ups quicker is to leverage an overlay that shows up after a user is on your website for a certain amount of time (e.g., 15 seconds). In my experience, it’s the best way to convert website visitors into your newsletter. You want to do this so that you can reach them.

5. Celebrate Your Early Followers

An open-source community is, first and foremost, a community.

Even if it’s just a handful of people, show gratitude for their contributions and celebrate them in public whenever you can. It doesn’t matter if it’s a meaty Pull Request or a tiny one to fix a typo in the documentation. Highlight those contributions, celebrate whoever made them.

In the early days, you’re primarily competing with the 20 other things those people could do in their spare time. If you are the project where the team is the most helpful, friendly, and genuinely interested in the person behind a PR, this can make all the difference to get the person to come back and do another PR.

If you are doing office hours or a newsletter, those are great opportunities to highlight contributions or welcome new people to the community. Think about other things you could do. E.g., you could send special swag (t-shirt customized with the GitHub handle, etc.) to everybody who created more than 10 issues or made more than 5 PRs. The effort for all of this is minimal. Still, the impact is significant, and people will be eternally thankful.

By doing that, you define the culture of your community. You lead by example because if you welcome those first 50 people warmly in your community, they will do the same for the next 5,000. It might seem like a problem you can worry about at a later stage. I strongly disagree. It’s tough to change the culture of your team, company, or community retrospectively. It’s much easier to do it from day 1.

Treat people the way you want to be treated, and lead by example from the start.

Tie It All Together

Most of these tactics don’t require much additional work.

• Do your demos publicly
• Communicate and collaborate as a team in public by default (community Discourse/Slack vs. company Discourse/Slack, public GitHub Issues)
• Track all your community members and make them aware of new capabilities, the office hours, and your ideas & roadmap through GitHub, the chat tool of your choice, and a simple newsletter
• Recognize any new community members if they contribute in any way, shape, or form

None of this is rocket science. What makes it hard is having the discipline to stay on top of it and creating the habit of leveraging everything continuously. It takes a while to get into it, but it will quickly result in a small and growing community. Sooner than later, you can start leveraging a proper tool like Orbit to scale your efforts.

If anything else is working great for you, please share it and let me know.