One of the quirky aspects of "community" in the free and open source ecosystem is that, for many members of a given project, they are physically and geographically isolated. Using tools like git, mailing lists, and any number of messaging tools, developers, writers, and other community members can focus their efforts and do their work from any place on the planet with electricity and a connection to the Internet.
As someone who has worked from a home office for nearly 18 years, I can tell you, it has its advantages. I can set my own hours, create a comfortable office environment, and work on my own pace. There are, of course, disadvantages too. I have to self-motivate, be my own IT systems administrator, and deal with somewhat atrophied social skills.
In your community, you are often going to have people in exactly the same situation. Somewhere out in the world, working full- or part-time on your project, from their homes or schools or offices. Maybe there are other project members nearby, but often they are working alone, connected by electrons instead of photons. So how do you manage a community of dozens or hundreds, when many of the are alone?
When I was a younger man, the Internet wasn't public, long-distance phone calls cost extra, and letter writing was the lest expensive way to maintain communication between you and someone on the other side of the country. My kids, children of the Internet and the smart phone, can't imagine such a world (indeed, some of my co-workers are getting young enough to recall those times). For them, for all of us now, communication between many people around the world can be trivial.
(An aside: "can be trivial." The digital divide is still all too real, and many talented people are still cut off from learning and working on the Internet. It's gotten better, but connectivity should by no means be taken from granted.)
Such connectivity makes it fairly easy from a infrastructure level to have global projects. But just having access isn't enough. Nor is just setting out a whole bunch of code on a repository somewhere in the hopes that people will just saunter in and start improving it. You need to work to build community.
In a business setting, where everyone is hired to work on a given product or goal, the very structure of the business often helps bring people together. You and the people around you are getting paid to build X. Teams are created by specialization. Managers are hired. Processes are set. Goals are defined. If there are questions, you can ask the person down the metaphorical hall.
In a globally distributed FLOSS project, many of the same processes occur: teams are created by specialization. Maintainers are selected. Processes are set. Goals are defined. If there are questions, you can ask the person down the metaphorical hall. You just have to remember that the hall is a keyboard, webcam, or smartphone.
There are, of course, processes to keep in mind for working with remote community members, which can make it easier to build that sense of community.
Not So Alone
Likely the number one priority for building community is establishing the communication process. People need to know who to contact, for what reasons, and what media to use. It doesn't matter if its email or text, IRC or Slack. Find a channel and stick with it. You can have multiple channels, but make sure everyone knows how they are supposed to be used. Many projects I have worked with include some sort of instant messaging channel for quick questions and online meetings, and use mailing lists or forums to have longer, more complex discussions.
Don't go overboard on the opportunities for communication. Just because you could use IRC, Slack, Askbot, and Signal doesn't necessarily mean you should. Pick one, maybe two, and keep it simple.
Beyond making channels available, make sure your channels are transparent. Ensure that everyone knows that if you are doing this kind of question, go here. If you have this sort of comment, go there. This kind of process flow should be clear, concise, and easy to find. People shouldn't guess.
Nor should they guess about who is involved in what aspects of your community. Who are the project managers? Maintainers? Who do they go to when this part of the project blows up? These things should not be a mystery.
Another key communication tool is a Code of Conduct. This is pretty straightforward, because they will help settle disputes and enforce civility when, not if, the need arises. People will eventually argue, and without rules that can be used to referee such disputes, things will spin out of control very quickly. Don't be militant about the rules ("Thou shalt always use the Oxford comma!"), but definitely be consistent on enforcement.
Many people have, and will, say that having local/regional/national events is also a great way to build community. And it's true: face-to-face meetings are amazing for building relationships and fostering communication. Our team at OSAS is about to have a bi-annual in-person meeting this weekend in Boston for just that purpose.
But your project may be too big, scattered, or financially constrained to do such meetings. But you can attend larger events and host smaller meetups within the context of those events. Or send representatives to staff a booth.
If physical travel is a problem, think about hosting virtual events. This does not mean just online meetings (though those count), but organized goal-oriented events that can bring together a number of your community to accomplish something fast. Sprints, hackathons, mentoring programs, QA days... any organized event like this, even online, can create a sense of shared experience among you community members.
At the end of the day, that is what you should be making for your community: shared experiences. They should be positive, but they don't have to be ("remember when we stayed up all night rebuilding that server?"). Good or bad, experiences that community members can share and reminisce about later help weave the tapestry of your community, and will make everyone feel less alone.
About the author
Brian Proffitt is a Manager within Red Hat's Open Source Program Office, focusing on content generation, community metrics, and special projects. Brian's experience with community management includes knowledge of community onboarding, community health, and business alignment. Prior to joining Red Hat in 2014, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.