You can only expect the help you ask for

POV of a man's hand being pulled down a rocky path by a woman

In response to my recent post on obligations, Gordon Messmer offered an excellent corollary:

It is only reasonable to expect the amount of assistance that you ask for.

This is an incredibly succinct expression of a concept that people with a lot of experience in the free and open source software world know intuitively: “Field of Dreams” is not a strategy for community growth. In other words, just because your project exists and is FOSS, that doesn’t mean people will show up to help. This is true even when they are using your project heavily. We often lament this through the lens of corporate under-investment in their dependencies, but it applies at the individual level, too.

Say what you need (specifically)

The best (but not infallible) way to get help is to ask for it, and your requests are more effective when they’re specific. “Help me!” might get attention, but what people think you need may not be particularly helpful. Asking for help with specific tasks tells people exactly what you need so that they can work on it if they’d like. This way, no one’s time gets wasted with well-intentioned-but-unhelpful contributions. Even if someone can’t or won’t do one of the things on your list, it might inspire them to come up with an idea that you haven’t thought of.

Using a label like “good first issue” or “help wanted” on issues is a great way to track specific tasks. If you need ongoing help with something that’s an ongoing effort, include it in your project readme or contributing docs.

But just having a list is still taking a “Field of Dreams” approach. Sometimes, you have to go out and actually ask in other venues. A few months ago, a long-standing bug in the GUAC Visualizer became more important because it was blocking the update of a dependency to resolve a newly-discovered vulnerability. When no one in the GUAC community could help, I posted in the OpenSSF (because GUAC is an OpenSSF project) Slack’s general channel. Someone stepped up to fix it within a few days. You can use your social media, forums, mailing lists, or anywhere else you have the ability to write words to ask for help.

Let people help you

“Of course I’m going to let people help me,” I hear you say, “that’s why I’m asking for help.” Well yes, but is it easy for people to help you? Have you documented things like “how to build the project”, “how to run the test suites”, “project code style”, etc? Is it even possible to test changes outside of the carefully crafted environment you’ve set up on your laptop?

You don’t need flawless documentation, but every barrier to contribution that you can eliminate or reduce makes it easier for people to give the help you’re asking for.

Documentation, of course, does not magically appear out of nowhere. You need to write it (or get someone else to contribute it). This takes effort. I’d go as far as to say that almost any first-time, non-trivial contribution is going to take a lot of effort from you (code reviews, answering questions, etc) — perhaps more than just doing it yourself in some cases. So why bother? Apart from the obvious “I don’t have the skills to solve this issue, but someone else does” angle, it’s an investment in growing the community. People who have a good experience on their first contribution are more likely to stick around to make a second contribution.

This post’s featured photo by Christopher Alvarenga on Unsplash.

Ben is the Open Source Community Lead at Kusari. He formerly led open source messaging at Docker and was the Fedora Program Manager for five years. Ben is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.