…and where a lot of people fail at it.
Drama in Open Source is becoming a lot more prevalent these days, even between projects. For instance, a few weeks ago, there was a fairly alarming interaction between the bcm43xx Linux driver developers and the OpenBSD bcw developer. However, what you probably don’t know, is that there’s a lot of interactions not only between projects but inside projects as well. I’d name some projects where this is very prevalent, but that would be a waste of time and accomplish nothing, so I don’t think I will.
The drama monster can attack any project, small or big. Size doesn’t really matter, and it doesn’t really seem to care what the issue could be about. Anything is fair gain. Of course, the drama monster is a manifestation of human personality in general, but management decisions can be made to avoid this from becoming a major problem very early on. I’m not talking about “codes of conduct” policies either.
A look at the problem
In most projects, you have friendly people and unfriendly people towards your position. This is a way of life, and there isn’t much that can be done about it. The problem is that when you do not have backing from your friendly people, the unfriendly people will take that as an opportunity to attack your position. This can be devastating and causes a lot of otherwise great developers to leave projects. Again, I can produce specific examples, but that is uninteresting.
Most intra-project drama comes about because there is no steering committee (larger projects) or person to make a final decision (small projects). In a situation like this, the results can be devastating. When there is no central authority in the project, cherry-picking can occur. In some projects, this works to the project’s advantage. However, in other projects, it results in a whole lot of drama. A large contributor and indicator to whether or not bazaar-style development will be successful is the overall maturity level of the contributors. If the contributors are immature, a bazaar-style approach will eventually fail. If the contributors are mature, then this paradigm of development can prove to be very successful.
Combining the unified (“Cathedral”) and decentralized (“Bazaar”) paradigms, and why it does not work
Some projects more recently have tried to combine qualities of the unified development paradigm and the decentralized development paradigm. This has usually resulted in a large organization where people generally do what they wish with what they are working on. While this may prove advantageous at first, the deficiencies of this combined model usually expose themselves fairly early, especially when people have to work together on a component of the overall project.
This model can work if people rarely have to collaborate with other people directly. It can also work if the people who are collaborating are friendly to each other’s position on how the project should proceed. However, it can result in major problems if the people do not wish to collaborate. In this case, the cathedral side of the combined paradigm usually wins out and a developer loses his commit access. This results in further drama because then the people who are friendly to the now ex-developer decide to hold a grudge against the person that ex-developer argued with. This sort of drama is the most dangerous to any project following this combined paradigm, and can result in forks that may not be very-well considered.
Forking for political reasons is also not keeping it real
When major disagreements happen, so do forks. Most forks ultimately fail because they are political in nature and usually do not receive much public vision. Political reasons can be a good spark towards thinking out a plan for a fork, but should never be used as a direct cause to begin a fork. This is non-useful and will simply scare away developers that may otherwise choose to contribute. If a project does get forked for political reasons, then both sides of the debate are usually harmed. Nothing usually comes out of a hostile fork except for further problems. As such, forking for political reasons is not keeping things real.
So if forking is not the answer, what is?
It depends on the paradigm, but it seems that having a place where people can vent their issues without having it come back to haunt them is a very good start. Some projects and development communities (Atheme) have such a way already. People voicing concerns is usually productive, people filing complaints with more powerful people in the project is usually not the way to solve the problem, however that is also human nature. Allowing arguments to happen (as long as it is directed to somewhere out of the public view) is usually an effective solution to the problem.
