How to grow open source communities
The community generally refers to the users, maintainers, and code contributors of an open source project.
There are different types of community participants:
- active participants: engage on Slack, in community meetings, or on GitHub
- lurkers: join the Slack and/or community meetings, but don't actively engage
- passive users: simply use the software product and don't even join the communities
As an open source developer, you want to delight all types of users.
Delighting active participants
Active participants post in chat, comment on social media, and ask questions at community meetings—make sure you always respond!
It's frustrating to ask questions and not get an answer. It's critical to always respond, even if you don't have a good answer.
Always encourage active participants to get more involved:
- invite them to contribute
- tell them to respond to other users
- ask them to present or blog
Active participants love helping out and are a great way to build a community!
Delighting lurkers
Lurkers follow conversations in chat and monitor GitHub activity, but they don't ever comment.
You can make lurkers happy by creating a good community vibe and by outputting a steady stream of insightful content.
Lurkers are content consumers and appreciate good blog posts and docs. Make sure to consistently invite lurkers to become active in Slack or to make PRs in GitHub, so they know that becoming a contributor is an option.
Delighting passive users
Passive users depend on your software project but don't bother joining the chat or monitoring GitHub.
They're just interested in using your library to build their own apps.
The best way to delight passive users is to build a bug-free project that provides descriptive error messages, has awesome documentation, and is well-maintained.
Passive users don't like when upgrading library versions causes breakages, so avoid making breaking changes at all costs. Follow semantic versioning strictly if you ever introduce a breaking change. Always consider building new functionality alongside existing public functions rather than removing the existing functions so your code maintains backward compatibility. Deprecating is often better than breaking changes.
Community meetings
Projects should hold community meetings periodically to highlight external project contributions and new features and discuss the roadmap.
The meeting frequency should depend on the project's maturity. A project that’s rapidly incubating may have community meetings on a biweekly basis and a project that’s rather mature may just have the meetings on a quarterly basis.
The community meetings should be recorded and posted on YouTube so they’re available to people who can’t attend live.
Community meetings will only appeal to a small set of users overall (only the users who have free time and are super interested in the latest developments, even the ones that are not relevant to their job). Attendance for a community meeting will never be super high, but it’s still an important component of community building.