The roads I take...

As mentioned earlier, I recently stopped contributing to the progress dialog code that I wrote myself. Based on things I experienced and learned there and in other cases, I decided to write a guide for losing contributors. Completely losing someone like me is unfortunately hard, I did step back from this part of code but that's all.

It's much easier to completely get rid of non-core contributors or people working on only one part of the project, and those are what this 10-point guide is about.

1. When the contributor works on a major feature (like, says a download manager frontend rewrite on a new backend), make sure you require all dependent feature parts (like progress windows) to be implemented before any of the work of that contribution can land. People hate to have their code sitting in Bugzilla patches for a long time and needing to do a lot of additional work, especially on parts of code they usually do not use themselves. You need to take advantage of that.
2. If the contributor blogs or otherwise write messages about his work, make sure you have people around who take every attempt of humor (e.g. "Progress Dialogs? Eww!") as dissing the feature, criticize every single change to previous behavior as destroying that feature, the project and possibly the whole world. Take down any motivation he has to do further work in that area - that's imperative.
3. Have users bitch heavily about the work, esp. about the shortcomings the contributor himself knows about and make sure no alternatives, short of killing the contributions and going back to old code, are provided.
4. Very importantly, do care that no single appreciative word - let alone a "thank you" - is ever being mentioned about that specific contribution. Also don't make constructive comments about how to further improve things by staying true to the made contribution. Both could encourage the contributor to stay with the project and do further work on this code, which is exactly what you want to avoid.
5. If he is starting work on further improvements even after all that, make sure people post in the bug about all kinds of problems they have with the general approach, have people post patches to at least partially revert the work the contributor did in the first place and ones that go against his overall design, and refrain from having any constructive proposals on how to do actual improvements in line with the overall design.
6. If he makes multiple suggestions on how to improve things, chose the one he states to like least and successively criticize what he stated to not like as a problem in reviews.
7. If a constructive suggestion for improvements comes up nevertheless and is a graphical mockup, it should contain some icons that are not available in a license compatible to the MPL/GPL/LGPL tri-license used in code. The Public Domain Tango icons (which could be used) should be as far as possible from the wanted look, and the well-matching ones from the mockup should be from e.g. Crystal (LGPL-only) or Oxygen (CC-by-sa/LGPL/CC-by-nc-nd) icon sets to make sure they can't just be integrated the way they are in the proposal. Don't make it easy for the contributor to follow a suggestion.
8. If he decides to re-draw the icons himself to follow licenses and some icons already available in your application, and even contributes the SVG his drawing software did spit out (even if the code itself doesn't work with the SVG), then it's imperative to nitpick the source markup of those images, ignoring that only their rendering to bitmap images appears in the application. Ideally, have someone from your team rewrite them with said-to-be-better markup and different colors so any of his artistic creation is disregarded, his contribution mostly neglected and you make sure he can't take pride in any of his creation.
9. When the patches come together - if you can't get rid of him before that - and get their first rounds of review, make sure someone comes in with a comment about how much he likes the previous design that had been agreed to be flawed and need improvements up to that point.
10. In reviews, be as nit-picky as possible, don't let code in that isn't almost perfect, require coding standards that are different to everyone else around, esp. from usual Mozilla platform code, and never say thanks for the done work.

In short, make it as inconvenient as possible for the contributor to work in this environment, the Mozilla code base surely isn't scary enough by itself. The contributor should never have fun, and if he would at some point, make sure it subsides fast. Make sure he wants to cry over every single comment made about the area he is trying to work on.

Note that many of those factors may happen by themselves and you as core developer in the project may not be able to influence all or many of those factors. Also note that this is not supposed to be a rant about what happened to me in the progress window project, if it would be, I would write it differently, and some of the points above would be exaggerated. This is supposed to be a guide on how to get rid of outside contributors - or an ironic view of things to try to avoid if you don't want to lose them - whatever version you like or applies to you better.