Open source projects aren't conflict free zones. People are trying to get along with each other most of the time, and sometimes this just doesn't work.
That is life. We have to be prepared to be confronted with misbehavior, crossing of social barriers, accusations, misunderstandings, egos, cultures, you name it, when all we really want to do is hack cool stuff. That's the downside of working at really cool software projects. There are other developers you have to deal with.
At Apache, conflicts mostly start or at least are fought over 'technical issues'.
Everybody appearing publicly at Apache - users, committers, members - is ethically bound to communicate in a consensus-driven and open minded way. But if you really don't find a consensus, and every supposedly fruitful technical argument makes people angry, frustrated, annoyed or any other kind of bad mood, there is probably a more substantial underlying community issue ventilating.
Warning signs are statements like 'I know I am right, why do you insist in your position?', 'This [my opinion] is a known fact. Period.', 'Everbody knows this, but you!', 'Simply change your tool/IDE/settings/operating system/keyboard layout/brain and shut up!'. 'I don't like people telling me what to do.'
This happens when people became unable to let any other opinion approach to there minds that they seem to be shutting down for everything what everybody else is saying. The blue screen of discussion death, so to speak. They become very defending when in fact they there is no reason. Finding consensus becomes impossible.
What's the solution when such a situation emerges? That's really difficult. So, let me tell you "The Parabel from the Developer with the Server Bug":
Once upon a time there was a developer. He was programming against a server API. He laid out the client application brilliantly. He wrote tests, he reviewed the code. He even briefely talked to other developers about it.
Then he let the client connect to the server. And all his excellent client was telling him is that there was a transmission error. Since he prepared his client program so thoroughly, certainly there was a bug in the server implementation. So he downloaded the sources (lucky him!) and looked into them. There he found ugly code, bad design, potential security holes. He ranted, he cursed. He thought about ways to torture the server app developer. He couldn't find the server bug, even less than the doomed soul writing this crap of a server. He turned away in disgust.
In the evening, he met a friend and told his story. They both shook their heads in disbelief about the misery with the server bug. At some point over the third cold beverage his friend asked the developer: Have you checked if it's a bug in your own client code? The developer just laughed.
Well, the next day the developer stumbled about a tiny little incorrectness in his own code, a probable misunderstanding of the server API spec. Small change. He started up his client again, and, can you believe it, everything just worked smoothly.
That's the end of the story. Is there anything to learn from this? In computer programs, you might be able to find a prove (test case, svn log, etc.) for who did wrong what and when.
This is not the same for community issues. If a fight breaks out, and you are a part of it, you are wrong every time. Fighting is a community bug. Take a step back before blaming others. Fix your own errors first. Let the others fix their own errors first, too. Then go back to discussion. Be polite. Be overly careful with every single word. Be pragmatic. Try to find a consensus, even if it's only to have a consenus. All parties will be unsatisfied. Maybe it will be painful for you more than the others. Maybe you have to go through this multiple times.
But you have created something beyond just coding. You fixed the community.
