How do I deal with (enthusiastic) contributors who damage more than they help?

Question

From time to time, an open source project will attract contributors who have a lot of enthusiasm, but lack skill, knowledge (or patience to know the project). These contributors can cause clutter, put off other contributors or sometimes directly harm the project.

Presuming that this contributor is actually harming the project in some way (which might not always be the case), what is the best way to deal with them. Preferably in a way that doesn't hurt anyone's feelings, appears professional and benefits everyone involved (if at all possible).

I'd like any answer to this question to discuss projects with different ways of contributing. (Direct commits, pull requests, ...)

Answer 1

Linus Torvalds has talked about his experience on this subject; the book Producing Open Source Software also has a section that deals with difficult people, which is mostly related. If you want to read more, look these up.

• Maintain control. How is it possible that contributors can do damage in the first place? Did you give them commit privileges without them demonstrating trustworthiness and aptitude beforehand?

  Open source doesn't mean you give away all the keys to the world; that's an invitation to disaster. You are still responsible for nurturing a community and directing the project in right directions. The most successful open source projects are very authoritarian at the topmost levels, as this makes decision making faster and easier, especially for the difficult decisions for the greater good that hurt a minority in the process.

  There is a term called Benevolent Dictator which is an example of this fact. This is where an individual wields final decision-making power over the entire project, much like a dictator. The reason why this often works is that open source projects are perpetually under threat of being superseded by a superior fork, so the dictator often acts in a manner that is beneficial to the project as a whole, hence the "benevolent" part.

  Just because your project may be large and has lots of contributors, doesn't mean you give them all commit privileges. Take a look at the linux commits; although hundreds of people contribute code, they are being merge-committed by a handful of people only.

  So don't give out privileges willy-nilly, keep the means to limit disruptive behaviour like spamming and being rude in forums.

  In the case study of the producingoss book, a loquacious mailing list poster backed down after being threatened with being filtered. Method matters a lot but the important point is that you need to be able to control and limit problematic people's actions.

• Set expectations, communicate early and often. When a project starts, many things are ambiguous or only known by the founders. When you start getting outside contributions, you will inevitably run into issues like coding style, naming conventions, testing procedures and so on. If there are differences, you should have conversations about these early, and set up policies and guidelines if necessary. This is not so much about having something to bash over the heads of people, but more about setting expectations for contributors.

  Be open to communications, and be proactive. If someone wishes to contribute, talk to them to make sure they understand what the expectations are, and how to improve the chances of their contribution being accepted. One of the worst things that can happen is that this is not made clear, and a contributor works in the dark for months, to contribute a giant changeset that is broken and unsalvageable. This is a big waste of time and leads to hurt feelings all around. Linus talks about having a similar experience in this video here; it shapes why he is so blunt and rude.

  "...I've literally had developers who were working on things that I didn't really like, but I didn't shut down early enough. They worked on it for a long time; they felt that it was ready, they submitted it to me, and I said "no this was horrible" because at that point I had to make a decision. And at least in one of those cases I had some other friends basically email me later and saying "the guy is suicidal"."

  Hopefully you will encounter much less drama than this, but you should still keep an eye out for what contributors are doing. If they go dark check up on them, make sure they are not going down the wrong path.

Answer 2

The best way to deal with people who are ultimately being more of a bother than a help is to:

First Talk to them. They may not know what they are doing wrong, talking to them may help solve the problem.

Second If they still have not improved you may need to remove them from the project. Although this may be difficult, it may be the only thing to save your project.

Tip (another idea) If they are new, try to suggest they learn more of that language, and become more knowledgeable, explain this could help them (and the project) in the long run.

*Warning Depending on how much they contributed they may have legal ownership (or co ownership) over the project. Try to work out a deal with them. To prevent legal issues if you publish the project!