[Pattern Draft] Recruiting and nurturing contributors for InnerSource projects

[spier]

In conversations in Slack @MaineC has shared many great tips about how to keep the number of contributors to a project healthy. Her tips are focused on

1. increasing the number of contributors
2. helping contributors to level up into the role of Trusted Committer

We would like to interview her about these topics, and see how we could turn this content into a pattern.

See our full pattern syntax to understand the type of information we would like to extract by doing an interview.

[spier]

Also worth checking which other publicly available material on this topic we can integrate. e.g.
https://program.foss-backstage.de/fossback23/talk/S9P7QY/

[MaineC]

Some of the strategies I remember at the top of my head:

• keep easy to fix issues open so contributors have simple stuff to get started - nothing like a typo in the docs that will trigger humans to provide corrections and thus move through the contribution mechanics for the first time.
• lower the barrier for contribution:
  • Standard build and version control tooling are the most obvious factors. Google Chrome is the best example of a project that initially made contributions harder by using highly performant but little known build tools.
  • Use a programming language that is well known and that enough people in your target group of contributors are able to read and write.
  • Provide documentation - including documentation on things you would otherwise verbally tell your new hire during new hire orientation - the goal is to provide a route to self-onboarding.
• Make time for mentoring, make time for encouragement, make time for positive feedback - help, support and praise are the only currency you have to motivate contributors that do not depend on you financially.
• Understand the incentive of contributors to become involved and provide paths that fulfill that incentive.
• Actively reach out to contributors, go to where they are - but try to pull them to wherever your project is working.
• Make explicit what exactly you are looking for in terms of contributions: Mahout famously needed help with performance testing, build system etc. - but contributors thought they needed to submit new machine learning algorithm implementations to become committers - the least of which we needed.
• allow contributors to lurk on your project, to watch what you are doing and where you're headed so they have any easy time to spot how to best get active.

trying to think of a few more things over the weekend, hope it's ok to add them here.

[spier]

I was wondering if it would further help to think about this topic similar to a Sales funnel (also referred to a Sales pipeline).

While Sales and InnerSource contributions are clearly not the same thing, it might be that both the visual of a funnel as well as the comparison to Sales helps us to find different and interesting ways to think about and describe this.

Comparison:

• In Sales, the funnel visualizes prospects/leads coming in through the top of the funnel, that the Sales person is trying to eventually nurture into a sale of teir product.
• In InnerSource, the funnel visualizes user (or even just somebody interest in you project/product) and we as maintainers are trying to convert them into a contributor.

The idea is apparently not novel :) At least a quick search lead me to this post by one of the maintainers of homebrew:
https://mikemcquaid.com/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/

Also if you have never heard of a Sales funnel, here one of the many images that you can find online:

[rrrutledge]

https://opensource.guide/building-community/

[spier]

That's interesting @rrrutledge. Especially as the opensource.guide link refers to the blog post I shared above :) A small world out there.

When teaching the concepts to your InnerSource maintainers, can you just point them to https://opensource.guide/building-community/, or would you apply some translation from open source to InnerSource?

[rrrutledge]

Haven’t looked - just know that there’s a lot of overlap and want us to be intentional about how we manage that.

[spier]

@rrrutledge this is an interesting conversation, leading us to the general approach that we take when producing material within the Commons. However it may take us on a tangent, somewhat unrelated to this issue here. Shall we continue this in slack or would you prefer to do it elsewhere? e.g. Slack or GitHub discussions?

[rrrutledge]

Sure - we can continue elsewhere. I don’t have much more specific to share at this point, but it is something that I’ve been thinking about for a while. A GitHub discussion would be good so that we can point people to it later - do you want to start that?

[spier]

Sure. Where to start it? On a public repo I guess, right?

[spier]

@rrrutledge I have left my somewhat unfinished thoughts about this topic in this discussion:
New patterns: What to write, what to link, and what to skip?

Looking forward to continue the conversation there.

[spier]

Further input for the topic:

If you want a robust community, make sure you have something for contributors to do in all four quadrants! (quadrants over "available time" and "technical skill"