If we want to grow our open source communities, we first should define what “community” means. I think we can agree that it is not the project code that we are collectively working on. But neither is it the website or storage management system that we use, or our mailing list, or our forum. Nor is it our wiki, our documentation, hardware, chat channels, blog, or license. It’s not even the project itself.
Community is the set of people involved in a project. More specifically, it’s a group of people interacting in pursuit of a single, shared vision. One consequence of this is that the old movie cliché, “if you build it, they will come,” is not actually true of open source communities. You can write some nifty code, create a nice blog, wiki, etc., but if you don’t have people, you won’t have a community either.
So, how do you build an open source community and get people to want to work with you in it?
It starts with the Golden Rule: treat others as you want to be treated yourself.
This covers your interactions with people on mailing lists, in chats, or in person at conferences. It sounds pretty obvious, but it does need to be said. If you want people to feel welcome, you need to behave in a way that would make you feel welcome to something that was new to you. It also includes how you present your project to others – it’s both good manners and good sense that when you are asking people to commit time to your project, you give them a clear sense of what you are doing so that they know what they are being asked to sign up for.
Then make you and your project as approachable as possible.
Once people understand what your project is about, they need to know how they can be a part of it. The more avenues you offer them – email lists, blogs, forum postings, etc. – the more likely it is that they will find you. Stay active in non-durable spaces like chat channels (IRC, Slack, Matrix, etc.) as well and create bridges between the durable and non-durable ones where you can. People can also find your project via your contributions to threads. When they go looking to solve an issue, they might see that you have a project in that area and check it out. So, it helps to put your head above the parapet in that sense as well. Offering a regular video call to your open source community is another good way to invite informal engagement that can lead to a more serious commitment once people realize how nice you are to work with (see above).
Along with being approachable, you need to be responsive. New community members won’t stick around unless you respond to people in a reasonable amount of time.
When people come to your project, they want to know that it’s active. You don’t have to get back to them instantaneously, but it should be clear that someone is jumping on bug reports or a pull request at a reasonable pace. Even if an issue elsewhere means that you can’t spare the attention for a while, you can send contributors a quick message to thank them and let them know when you should be able to get back to them. That’s all it takes to keep people interested. But if you wait too long, it will look like your project’s all but dead and they will go away for good.
When you are interacting with people, make sure to give constructive feedback.
Unless you are being obviously trolled or something equally out of line, always respond graciously when people reach out. Offer constructive feedback even when you’re deciding not to take a suggestion or contribution. You can always ask questions on a bug report or ask someone to do a patch in a slightly different way if you think that would be better. And, of course, try and explain why you think it would be better, too. The community in general will see this as constructive feedback and that will help everybody both understand what’s going on and see the positive spirit in which the open source community acts.
To encourage openness, make your bugs public.
Some projects are embarrassed by their bugs and want to hide them. But the more open and transparent you are about things, the more that your community will feel it has both a stake and a say in what is happening in it. This feeling is what binds the open source community and keeps it with you. More specifically, triage your bugs so that people can see that they are being responded to, commented on, and closed when fixed.
As you grow, you also need to accept that you will eventually lose ownership of the project.
This is a good thing, of course. Once the community starts feeling ownership and working on things for the sake of the project itself, they will start taking loads away from you, allowing you to focus on your own priorities for the project. Again, empower others to work on things they are motivated to work on. That doesn’t mean you should stop checking changes before they get merged, but sharing ownership really helps the community feel committed to the project.
If you are the head of the project, remember that you set the tone.
A project head may or may not be the lead coder. But usually one person is perceived to be the project’s leader and that person sets the tone for the entire project. That tone can mean the difference between a community that is productive and popular and one that is completely dysfunctional that nobody wants to be a part of.
And finally, always give credit.
Credit is the base currency of open source development. It acknowledges the work people have done and is all the payment most people want in return for their work. It’s also just the right thing to do. So, offer credit around whenever it’s due – for reporting, patching, testing, reviewing and signing off, etc.
Bottom line: if you want to have an open source community, you have to talk to people and do your best to make them feel welcome. A lot of us got into this line of work in part because we’re not enormously comfortable talking with people. But we can do it. And we can collectively achieve great things when we do.
Stay tuned to the Open Source Blog and our Twitter handle (@vmwopensource) for more on becoming a better open source community member.
