One of the great pleasures in my career has been teaching at the Mendoza College of Business at the University of Notre Dame. There's nothing like teaching IT concepts to business students and seeing the light bulb go off when they see the potential of technology in their work.
Occasionally, I will get a request from a student or student assistant for a reference. Sometimes for a foreign exchange program or sometimes for a job. This week, one of my former assistants asked me to be a reference for him at a non-profit organization in Chicago for which he wants to volunteer. I agreed immediately, naturally, but it struck me as a little disappointing that someone has to jump through the hurdle of getting a reference just because he wants to volunteer to help people.
To be fair, this is an organization that works with children, so in this case I can understand the need for more scrutiny. But this is not the first time I have come across non-profit and charitable organizations who will clamor for more volunteers with one hand, and then set up a lot of barriers for entry that keep potential volunteers at bay. My own local Habitat for Humanity used to have a web site design that would make it very easy to donate money, but getting on the volunteer list to actually join a build was very difficult. (They have since fixed this issue, so I can pick on them a bit.)
I am sure this was not an intentional decision, just as other organizations where I have seen this issue is likely not done deliberately. The most common reason seems to be the organization in question is so focused inward on daily operations and programs, they assume an false-consensus bias that says "if I know how this works, everyone knows how this works."
The problem is, of course, that just because you know what's going on in a project or organization, you can't assume everyone else will too. You have forgotten what it was like to be the new person, just starting out and not knowing who was who and which way was up. If you were lucky, there was someone who guide you in and help with the initial transition.
This is not a universal problem, of course, but some organizations are better at this than others. And it is something that every free and open source project should at the very least keep an eye on. Indeed, since many FOSS projects tend to lean (or fully participate) in to a meritocratic governance model, they can be especially susceptible to making it harder to join their project than it needs to be.
We need a fence, the argument goes, to keep out the riff-raff. We don't want just anyone throwing patches into the repository. They need to know what they are doing. From an egalitarian point of view, this seems a bit exclusive at best and snobby at worst. But it might surprise you to hear from a community analyst's point of view that there is some validity to this argument.
Goal-oriented projects by their very nature need to have some level of skill because participants are actually making something. So there almost has to be some division of labor. In software development, some people are better at UX, some are better at working with APIs, so it's only natural to organize people based on their skill sets.
But just because there is a skill-based fence around your project, does not mean there's no gate in that fence. Let's back up to the hypothetical snob's argument: "We don't want just anyone throwing patches into the repository. They need to know what they are doing." This is very true. But the rest of that statement needs to be: "...and we need to show them how to participate."
That's the gate.
I am not advocating that you show them everything they need to know. You won't be teaching anyone Python or C++ from scratch (unless you really want to). But you will need to show newcomers to your project how to get started. And start at the beginning, telling them:
- What Your Project Does
- How to Get Your Project
- How to Use Your Project
- How to Contribute to Your Project
This might seem ridiculously obvious, but you would be surprised how many software (and indeed, any) projects can drop one or more of these core fundamentals.
Your FOSS project will be the Most Important Thing to you, and as such you will probably know the tricks and paths to take within the project at a purely intuitive level. But the institutional knowledge that helps you can be a barrier to anyone else who wants to join your project. Spending time on your community's fence and building clear and easy-to-find gates will ultimately make your community richer and stronger.
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.