The Open Source Contributor Funnel  ## Metadata - Author: [[Mike McQuaid]] - Full Title: The Open Source Contributor Funnel - Category: #articles - Document Note: 1. Question: Who are the maintainers of an open source project? Answer: The maintainers of an open source project review and merge contributors from contributors and generally run the project. 2. Question: How can you encourage people to fix their own issues in an open source project? Answer: Encouraging people to submit a pull request rather than just asking for help can help them fix their own issues. 3. Question: What is the purpose of a "Code of Conduct" in an open source project? Answer: A Code of Conduct helps set expectations of acceptable behavior on a project to avoid toxic users, contributors or maintainers that make open source no fun and people don’t want to spend their time on projects that aren’t fun. ## Summarize: The article discusses the importance of attracting and retaining contributors and maintainers for open source projects. It emphasizes the need to think of the user and the contributor funnel, where users become contributors and contributors evolve into maintainers. The article provides guidelines for getting more and better contributions, such as encouraging people to submit pull requests and documenting expectations for maintainers. It also highlights the importance of retention, outlining specific measures to keep users, contributors, and maintainers engaged with the project. ## Bullet Points: - The user, contributor, and maintainer are important groups in open source projects. - Users are those who use the software but do not contribute code or documentation. - Contributors submit code or documentation but need someone to review and merge their contributions. - Maintainers review and merge contributors and generally run the project. - Most contributors were users first, and most maintainers were contributors and users before becoming maintainers. - Maintainers need to maintain their perspective as users to perform their role effectively. - Projects should utilize strategies to move people through the contributor funnel. - Strategies include asking people to submit issues instead of random mentions on social media, helping people create pull requests, and identifying potential maintainers from contributors. - Retention is important, and different groups require different approaches to encourage them to stick around. - Users value high-quality software, contributors benefit from open discussions and a clear issue tracker, and maintainers need a code of conduct and opportunities for private communication. - Adding new maintainers is essential to keep the project running smoothly. - Understanding why people contribute and applying effective strategies can attract more contributors and maintainers to the project. ## Paraphrase: 1. The article discusses the significance of attracting and retaining contributors and maintainers for open source projects. It emphasizes the need to consider the user and the contributor funnel, which involves users becoming contributors and contributors transforming into maintainers. The article provides suggestions for obtaining more and better contributions by encouraging individuals to submit pull requests and documenting expectations for maintainers. It also highlights the importance of retention, outlining specific measures to keep users, contributors, and maintainers engaged with the project. 2. The author emphasizes the importance of a contributor funnel in open source projects. They explain that users often become contributors to solve a problem they are experiencing, and contributors often become maintainers after helping build the project. Maintainers need to remain users to maintain context and empathy. The author likens this funnel to a sales funnel and acknowledges that there is a drop-off at each stage. To attract more contributions, the author suggests asking individuals to submit issues instead of random mentions on social media, helping them create pull requests, and identifying potential maintainers from contributors. Retention is also crucial, and the author offers advice for keeping different groups engaged, such as prioritizing high-quality software for users, facilitating open discussions for contributors, and establishing a code of conduct for maintainers. - Document Tags: [[code of conduct]] [[maintainer]] [[open source]] [[open source contribution]] - Summary: The document discusses the concept of the "contributor funnel" in open source projects, which helps understand why people may not be contributing to a project and how to fix it. The funnel consists of three groups: users, contributors, and maintainers. The document provides guidelines for increasing contributors and maintainers, such as encouraging users to submit issues and teaching them how to file better issues, documenting how to submit pull requests, and inviting new maintainers. It also emphasizes the importance of retaining users, contributors, and maintainers by keeping the project high quality, avoiding unnecessary discussions, and implementing a code of conduct. The document concludes by highlighting the need to understand why people contribute and how to attract more contributors to a project. - URL: https://mikemcquaid.com/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/ Homebrew, the macOS package manager I maintain, is one of the most active community projects on GitHub. We regularly attract large numbers of new contributors and valuable, [first-time open source contributions](https://mikemcquaid.com/stop-mentoring-first-time-contributors/). We’ve done this by thinking about our users, contributors and maintainers going through a “contributor funnel”. If you’re wondering why people aren’t contributing to your open source project (😭): thinking this way will help you fix this. ##### Who uses your software? Let’s start with defining groups of open source project users by looking at how they are interacting with your project. * 👩‍👩‍👧‍👦 the **users** of an open source project are the people who use the software but aren’t submitting code, documentation or performing issue triage. They may file issues but often these will be more of a “please help me” than a reproducible bug. Hopefully the project has at least one user: you. * 📣 the **contributors** to an open source project are those who are submitting code or documentation (i.e. as a pull request if on GitHub) but need someone to give them code review and merge their contribution. They do not have commit access to merge their own changes. You may not have any contributors to your project (yet). * 🛠 the **maintainers** of an open source project are the people who review and merge contributors from contributors and generally run the project. They have commit access. A maintained project has at least one of these: the person who started the project. Once there are no more maintainers, the project is abandoned. You want to have more contributors and maintainers on your project. A few guidelines in thinking about this: ` * most contributors were users first (“scratching your own itch”: most people start contributing to an open source project to solve a problem they are experiencing) * most maintainers were a contributor and user first (people don’t just jump into maintaining a project without helping to build it first) * maintainers cannot do a good job without remaining a user (to maintain context, passion and empathy) Combined, these start to look a bit like a [sales funnel](https://www.mailmunch.com/blog/sales-funnel/). People have to travel through each of the stages and there’s a fairly hefty drop-off at each one.  In Homebrew’s case, we have millions of users, thousands of contributors and tens of maintainers (ever). Think about these numbers when you’re wondering why your project with ten users doesn’t have more contributors. That said, you can help to push people through this funnel with some gentle nudges. ##### How to get more, better contributions  When your project gets a random Twitter mention you can consider asking them to submit an issue instead (and your issue template may help them submit a good one).  If you get a bad issue report consider asking people questions like this to figure out what the actual problem is and teach people how to file better issues in future. People will need encouragement to fix their own issues. Encourage them to submit a pull request rather than just asking for help. It helps if you can document how to create pull requests for your project (e.g. check out [Homebrew’s “How To Open A Homebrew Pull Request” documentation](https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request.html)). You may need to help some people use Git and GitHub to do this. Some people have amazing coding skills but have not used GitHub before. Look at the contributors to your project to find new maintainers but bear in mind new maintainers will usually need to be talked into it. Maintainers don’t tend stick up their hands and say “me me”; in my experience, when they do it’s often a bad sign. They need to be encouraged and invited. Document what the expectations are for maintainers so they can see before you ask them (e.g. check out [Homebrew’s “New Maintainer Checklist” documentation](https://docs.brew.sh/New-Maintainer-Checklist.html). ##### Do you have a leaky funnel? There’s no point in you getting more contributors, maintainers and even users if they leave your project quickly. I’m not talking about their initial attraction but retention on your project. Each group of your users need different things to stick around: * 👩‍👩‍👧‍👦 **users**: + 💰 Keep your project high quality. If you do a mass refactoring and introduce loads of bugs: people aren’t going to want to use your software. + 😰 No “guilty merges”. Don’t merge work from contributors you know isn’t good enough just because you feel bad about the work they’ve put in. + 🏗 No v2.0. By this I mean don’t do a mass rewrite or refactor that makes using your software radically different. Respect your users’ existing workflows and learnings on how to use your software. * 📣 **contributors**: + 🚳 No [bikeshedding](https://en.wiktionary.org/wiki/bikeshedding). Avoid long discussions about things that don’t really matter. It’s a waste of everyone’s time. + ☎️ Open discussions. Conversely, ensure there’s a place contributors can talk about the development of your software and ask questions that aren’t bug reports. + 🔐 No feature issues. Don’t fill your issue tracker with “feature requests” you know will never be implemented. Learn to say “no”. * 🛠 **maintainers**: + 💝 Code of Conduct. These help set expectations of acceptable behaviour on a project. Toxic users, contributors or maintainers make open source no fun and people don’t want to spend their time on projects that aren’t fun. + 🔏 Private chat. Give the maintainers somewhere to bond, discuss and resolve conflict privately. Not everyone feels comfortable doing this publicly. + 🌳 Keep adding maintainers. Most maintainers have a shelf-life so you need to keep looking for more maintainers for when the current ones leave. This also allows people to focus on the bits they find most enjoyable. After doing the above you’ll understand why people contribute to your project 😍 (and how to find more). Good luck!, The Open Source Contributor Funnel, Mike McQuaid, 01h5dwswcnr8xcwe9g8g3ytdx4.