Contributors do not save time

This is very much untrue. I manage several open source projects and contributors save me tons of time. You have to mold contributors into the productive team members you need them to be to save you time. I often receive pull requests from first time contributors that are not immediately mergable. I don't take the approach of just merging it and fixing it myself - I do invest the time in coaching the contributor into making their pull request a strong candidate for merge on their own. This often produces returning contributors who get it right more and more often on the first try and can be trusted to write larger and more important swaths of the code. Bonus - these contributors you've worked with will often start to get in and help review entry-level pull requests, too, which reduces your workload even more for onboarding new contributors.

Contributors rock! More of them would help me get my projects done so much faster.

I think the author misses a key point.

The article begins by laying out a premise that not all work is equal, in the sense that contributors will contribute work that maintainers aren't wont to do for one reason or another.

But what follows is the claim that this creates an additional work burden for maintainers, in terms of review. But what is each contribution, and how does it contribute to future work by maintainers and contributors alike?

Projects with a lot of attention benefit not just from "work" but from advancing design and efficiency where, as the author says, "each contributor brings fresh eyes and experience to the project". Simply counting hours worked doesn't account for this, because a tremendous amount of work may simply be avoided by this kind of contribution.

My feeling is that this is actually a problem with github and the "pull request" method specifically. All of the back and forth, waiting for the contributor to update commits is a huge time sink for me. It takes 10x as much effort to merge a small pull request than to actually write the code myself.

The solution I see, is to make it so that rather than commenting on pull requests, I "adopt" the pull requests. I merge them into a private branch, fix the spelling errors and the "bad" variable names, and then I push the bundle. For some reason, most contributors want to have a clean commit history and don't like this method. I agree that it is messy. I think that my "solution" points to the need for a better solution. Either one implemented by github or one implemented by a competitor which destroys github.

Well, the writer is correct: dealing with a contributor increases your own workload. But...maybe we could use the interaction to turn an occasional contributor into a maintainer? Although that's tough, hopefully the contributor grows into that role and, over time, reduces your own workload as well.

For fixing simple stylistic / spelling problems, I really like the take taken with `git am`: https://blog.spreedly.com/2014/06/24/merge-pull-request-cons...

I think what the author writes is true if you want to maintain absolute control over the project.

However, in this post (http://felixge.de/2013/03/11/the-pull-request-hack.html) and the related HN discussion (https://news.ycombinator.com/item?id=5357417), we see that by empowering and trusting contributors we can often get surprising and unintuitive results. I've tentatively tried this and been pleasantly surprised in my own projects.

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/). 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-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.