A project isn't just defined by its code contributors. Technical writers, tutorial writers, users answering questions on StackOverflow and in issues are first-class citizens in determining the success of your project. How can you create the right conditions for an open-source community to thrive?
Part I – Contributors
Part II – Community (you are here)
Part III – Users
2. Build a community. Community is an ambiguous term, but I'll define it for open-source projects. It encompasses users who are talking about your project, writing tutorials for it, contributing code or documentation, or using it in production. You want to help these valuable users find and help each other.
- Add shoutouts to the release notes to highlight community contributions. You can do this automatically with your release script. Everyone loves to see their hard work recognized.
- Create plugin architectures where they make sense, and keep the plugins in the central repository. Plugins help extend your software to use cases that you don't have time to support fully or envision. The skaffold design did this extensively, having pluggable ways to build a docker image and deploy it. This helped us reach more users by meeting them where they were.
- Create paths to more responsibility. The plugin architecture gives a clear on-ramp to full maintainership. First, since plugins won't be a hard dependency of the main project, they can safely be maintained by others and in earlier alpha states. For example, a vendor may maintain their own plugin for your software. Big projects like Kubernetes and Linux were bootstrapped on vendor-maintained in-tree plugins. If the project becomes huge, you can always move them out-of-tree, but that's a good problem to have. How do contributors become maintainers? Can they?
- Create a slack channel or discord. A slack channel or discord are great ways to engage with your users in a more casual way. I spent most of my time hanging around the Kubernetes slack in the early days, answering questions from newcomers and experienced users. Learn about user friction, commonly asked questions.
- Put documentation in the central repository. Too many open-source projects overmodulize their repository structure. Keep everything in the same place when you're starting. Multiple, tiny repositories can stop your project from achieving mass scale. Knative, a great serverless framework for Kubernetes, made this mistake. Without a clear entry point, new users don't know where to go. Repository structure does not have to match your microservice architecture.
- Consider office hours or community calls. This is more project-specific but make time that power users or potential contributors can take advantage of. Developing these advocates now can pay off immensely later.
Part I – Contributors
Part II – Community (you are here)
Part III – Users