Select a language
It is an easy metaphor to fall into: we compare the communities that surround our free and open source projects to the actual communities in which we reside. For the most part, the metaphor works really well. I myself have used the metaphor to describe things like server and IT infrastructure to streets, water lines, or power grids. Governance of open source communities to the way different neighborhoods, towns, and cities govern themselves.
Making this comparison is not, after all, rocket science.
But there is one aspect to the communities-as-communities metaphor that breaks down, because should be no comparison: the way communities enfold newcomers into their midst.
When someone moves into a new home in a new town, there usually isn’t going to be a formal set of rules in place that explain how the community works. For the most part, you move into the community and sort of learn as you go. Where is the nearest grocery store, which is the best hardware store, who are the neighbors who are the most helpful… pieces of knowledge that you just pick up.
There are exceptions, naturally. If you move into a new country, there are going to be formalities to quickly learn: new laws, new ways of acquiring services. And if you enter a new domestic community, perhaps you have a realtor who can walk you through where to find what.
For an online community, such entrances are often the case, too. A new user or contributor rolls in and wants to learn all they can about the lay of the project’s land. Through watching and asking questions, they will be able to learn what they need to know and—if they have the patience—they will eventually become a “veteran” member of the community. Just like a residential community.
Except this should not be the way it happens. When you move into a new home the learning curve is probably not very not very high. Plus, you know the questions to ask: where is what, who is who? In an open source project, you might not even know what it is you don’t know yet. And in many open source projects, the technology may have a steep learning curve as well as the language itself.
I had a personal lesson in this yesterday on my way to the airport with my co-workers after a successful weekend at SCaLE 16X. As we were winding our way through LA traffic, I discovered that one of the Red Hatters in the car was, like me, a private pilot. And for a few minutes, we rambled on about flying, planes, and navigation, until we realized that we had inadvertently excluded the other passengers in the car with our jargonism. A minor faux pas in the grand scheme of things, but it was a reminder that communities can have barriers that you don’t even realize are there.
This is why it is important that open communities make a special effort to build inclusionary practices that help onboard new members. We have an extra responsibility to create explicit paths into a project, because the very nature of our projects creates larger barriers to entry. Onboarding is something that we cannot ignore, not if we want people to continue to move in and reside in our projects.
Image courtesy of State Farm, released under CC BY 2.0 license.
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.