I disagree. I recognize that the author is writing based on their experiences, but that should not paint all contributors that way. I'm involved in two project

I disagree. I recognize that the author is writing based on their experiences, but that should not paint all contributors that way. I'm involved in two projects (Rust, Servo) which have immense numbers of contributions from volunteers. Both have mentorship programs (Servo's is more evolved, Rust's is getting on its feet). In Servo we spend a lot of time mentoring people. In return, once every few new contributors we get someone who sticks around, and perhaps even works on major things. This saves ton of time. I haven't ever measured this formally, but by eyeballing it I'd say contributors save more time than the review process and mentorship take. I also have a personal project, rust-clippy (http://github.com/manishearth/rust-clippy/ http://github.com/manishearth/rust-clippy/). It started out as my own thing, and I merged with another similar project and got a co-maintainer. It was mostly the two of us working on it. We could have gotten it to the stage which it is at now, but it would have taken forever. At one point I started tagging issues as easy/medium/hard, and wrote some documentation for newbies wanting to contribute. I advertised this a bit in the appropriate forums, and now I have tons of contributors; three of which have become maintainers (they still contribute a lot), and a couple others who frequently contribute. I don't have much time to work on this project these days, but it has grown so much without me needing to put much time in it at all. These days I mostly review PRs and take part in discussions, but rarely write code for it. The project is now a tool with more than 150 lints which most of the Rust community uses and loves. It would not have gotten there without the contributors. If you'd like your project to be mroe receptive to new contributors, I have a blog post I once wrote for this: http://manishearth.github.io/blog/2016/01/03/making-your-open-source-project-newcomer-friendly/ http://manishearth.github.io/blog/2016/01/03/making-your-ope.... Many of the tips there don't require much effort -- it's either a one-time thing you have to do, or a change in process that doesn't make the process longer. Aside: Often a distinction between "contributor" and "maintainer" is made, and this is cropping up in this thread too. In clippy this has never really been a thing. We have maintainers, but when someone becomes a maintainer they don't really do anything different -- they don't take on more responsibilities. Rather, most of the contributors I have ramp up from working on individual issues to reviewing and doing maintainer-y things, and once we think they've got the gist of it we give them merge powers. In Servo/Rust we also have a similar continuum -- we have folks who take part in review without having review access ("review access" is the ability to tell our autoland bot that something is reviewed and ready to test/merge), and at some point they are given reviewer permissions. So there is of course a difference in the powers available to contributors and maintainers, but in the projects I work on the most there's not much of a difference in what they do; maintainers don't have additional responsibilities, they just have powers which help they carry out what they were doing as a contributor anyway.