How to deal with a very productive contributor who wants to steer the project in a different direction?

Question

I am part of a non-commercial bazaar-style open source project which is developed and maintained entirely by unpaid volunteers.

A few months ago a new programmer joined our team who is both skilled and prolific. They provide a large number of commits and, contrary to the question "How do I deal with (enthusiastic) contributors who damage more than they help?", their code quality is more than adequate. By any sensible metric, their productivity in the past few months was higher than that of all other contributors combined. They have also taken over some non-programming related maintenance and project infrastructure responsibilities nobody had the time and motivation to do.

Unfortunately, it has lately crystallized that their vision for the project differs quite a lot from that of the other project members. They want to move the focus of the project into a completely different direction than the rest of us.

Lately they even started to remove features from the codebase, which they consider "poorly developed", "unnecessary bloat" or "must be removed before I can remake them much better". To be fair most of these feature were indeed in an unusable state, obsolete or not used by anybody, but their intentions are clear.

How can we as the original founders of the project keep our vision intact without losing this very valuable contributor?

Answer 1

Discuss, discuss, discuss

This is absolutely essential. You can't solve personal problems digitally - so when I say discuss, I mean call a meeting. You need to sort out some things with him:

• Project focus
  If everyone has a different idea of where the project's going, it's obviously not going to work. This is the root of the problem. Discuss with him what he thinks the project should do, and why he thinks this. There may well be reasons behind it that you haven't thought of, that might actually change your view. Then, as a team, come up with a project aim that you're all happy with. It should be a good compromise so that he doesn't feel like his ideas are being left out, but he does need to realise that he's one of many and needs to be co-operative.
• Working policies
  You need to work out who can do what. Your work should be organised so that there are no conflicts and no missed areas - two people should not be working on the same thing and neglecting something else.
• Features
  Again, important. Features are a big part of the project, so it shouldn't be set up so that any developer can add or remove features on a whim without telling anyone. Get it re-organised so that adding or removing features has to be approved by a person or team. You can't have this guy going around removing essential features because of a difference of opinion and derailing the project.

Answer 2

Bring it up, clearly.

This might seem obvious, but can't be stressed enough. If you are positive that the direction they taking the project into is incompatible with the vision of most, then this needs to be addressed.
Make sure that other people are on board with mentioning it to them, so you form a unified front, but avoid making the problem contributor feel like people have been conspiring against them. You don't want to come over as hostile.

Try to compromise.

As you said, many changes the contributor has made were actually warranted, maybe some of their ideas can still be incorporated in a version of the project that you can both get behind. You'll want to try to avoid losing your most active contributor over this. Without enthusiastic contributors, you don't have a project.

Don't compromise on single issues however, discuss the single issues, generalize what comes out of that discussion and apply those generalisations. Everyone should follow the guidelines, if you don't agree they can perhaps be discussed, but you don't just do things the way you think they're best. That has to be made very clear.

If you can't find an agreement.

If you can't work things out (and enough other contributors agree with you), you'll have to request that this problem-contributor stop making drastic changes to the project and actively roll back any changes they do make and perhaps even take away their rights if they persist. (if possible)

This doesn't necessarily have to be a bad thing, they could maintain their own fork of the project where they get to do whatever they want with it and can still contribute to the original project.