17

Note: this is a hypothetical situation, not one I have actually encountered. (And one I hope I won't encounter)

I started a small open source project and have gathered a few loyal committers. We don't have much in the way of a hierarchical structure and make our decisions by way of consensus. This has not led to any significant problems.

Recently, the core contributors have split based on differing opinions about a rather central part of the project. (Which relates mainly to how users interact with the product on a very fundamental level.) A compromise seems unlikely and I fear the project will take a serious blow if it loses almost half of its contributors.

How can I limit the damage this disagreement will deal to the project and how can I prevent something like this from happening in the future?

For the sake of completeness, here are two related questions (separate links)

  • 2
    Projects have splintered before and they will again. – ratchet freak Jul 7 '15 at 12:41
  • @ratchetfreak good point, some projects have a large enough contributor base to take it though, I fear this one doesn't. – overactor Jul 7 '15 at 12:42
  • Did the project have a written product vision? – Michael Schumacher Jul 7 '15 at 13:07
  • @MichaelSchumacher not one detailed enough to resolve this. – overactor Jul 7 '15 at 13:16
12

Been there, done that.

Why does it happen?

In my experience, a split due to creative differences usually happens because different people have a different idea of what the project goal actually is, but nobody is aware of that. As soon as a contributor realizes that someone else's vision is different from theirs, arguments and power struggle will start, which can quickly become personal and tear a project apart when not moderated properly.

How to prevent it?

The best way to prevent this situation early on is to communicate your creative vision of the project early, clearly and often. Every project should have some kind of official document which outlines the goals. Make sure every contributor knows and understands it, so everyone is on the same page and nobody gets any misconceptions about where you are heading. Make clear that anyone who wants the project to go somewhere else, should fork from the start and not get involved in the mainline in the first place.

Should there be any disagreements about aspects of the project direction which were not set in stone beforehand, it is important to make a binding decision before things turn ugly. Having a clear hierarchy or well-defined decision making process is fundamental here. Without a binding process to make a decision - whether autocratic or democratic - people have no other choice but to "reach consensus" by either talking down the opposition through countless hours of filibusting in your communication channels (time they could rather spend working) or driving them out of the project through bullying and intrigue (a lose-lose situation for everyone involved).

Unfortunately, when the conflict is already under way, it is likely too late to establish a proper decision-making process. Such a process only works when everyone supports it. But when you try to establish it now, everyone will perceive it in the context of the current conflict and their support for it will depend on whether this process would decide the current matter in their favor or not. Opening up this new battlefield now will likely deepen the trench instead of bridging it.

The split still happened. How to deal with it?

When the project is under a copyleft license (or when under a permissive license the other group is committed to keeping), you can still merge any of their commits into your codebase or vice versa, so the manpower is not completely lost to your project. But a split is still a considerable blow to the project because organisation structures and infrastructure need to be duplicated, coordination between the forks is impaired and their commits need to be carefully reviewed for relevance and merge conflicts.

  • is right about cost. It is very hard to support software when the project has forked and users are unaware that they are now on one side or the other. They attempt to follow documentation for one, file bugs on the other, expect features in upcoming releases to be on both, etc. Once they are aware, they now have to consider which fork they would prefer. The takeaway is: establish vision and organize process during the period of agreement. It may feel unnecessary at the time, but it is ultimately irreplaceable. – Joe Atzberger Jul 22 '15 at 19:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.