How do I deal with a difficult programmer joining an open source project? | Hacker News Reader

How do I deal with a difficult programmer joining an open source project?

programmers.stackexchange.com

22 pointsDanBC9 comments

I dont know why this is being upvoted, the stack overflow question is a personal rant that doesnt really make any sense.

But to answer the question, the best open source projects I have worked with have had peer review, someone else on the project is the one who actually pushes your code into the repo, this works a great sanity test and catches most of the common implications that you may have missed, but another good part of this is that it works as lazy concencus now all the people who may have issues with your patch have the opportunity to discuss it before it lands while at the same time not adding too much overhead and bureaucracy to get code landed.

The other thing is that the code (or individual parts) have to have owners who have the final say in any disagreements, its impossible to get everyone to agree on every change and sometimes an owner just needs to come in and make a final decision, open source that attempts to work as a democracy has a very hard time in my experience.

So it sounds to me like the main issue here is that the original poster did not understand Forking and Pulling, and how important it is to compartmentalize your team using those 2 GIT(hub) features?

You don't go handing the keys over to the main repository to just anyone. You make contributors fork your work, then you pull in changes that you like. This leaves you 100% in control of versioning and the main branch of the project.

"How do I deal with a difficult programmer..."

If you're not project lead, you don't.

Something along similar lines came up on Ars Technica a little while back "How should I behave as a developer in a project that’s headed for failure?": http://arstechnica.com/information-technology/2013/07/how-sh...

There are some good ideas there to better engage something like this.

Yes, if you can fire them do it. Otherwise it is none of your concern.

Thats pretty depressing, a large part of open source development is learning to work with a wide range of other people without being able to fall back to corporate politics bullshit (not that OSS is exempt)

This is exactly how Linus deals with things; being as anti-corporate BS as possible. But note, Linus deals with things, not anyone else. If they have a problem, they can go to him first, but in the end, he's the one who deals with it.

Any other developer who's having problems should go through the leadership first or has no alternative but to leave. It sucks to swallow your pride, but taking matters into your own hands (as some of the comments on the SO post suggest) can lead to anarchy. Then everyone loses.

Surprised that this isn't in the thread already.

Brian Fitzpatrick and Ben Collins-Sussman from Google have done a bunch of great talks about exactly this: How Open Source Projects Survive Poisonous People (http://www.youtube.com/watch?v=Q52kFL8zVoM)

They also wrote a book about the topic: http://shop.oreilly.com/product/0636920018025.do

All of their advice comes from their experience running the subversion project. It is also good general advice for dealing with humans/engineers/etc.

Communication with the programmer you have an issue with, and communication with the leadership in the project.

If you have personal issues with the programmer, such as their attitude or behavior, bring them up in a personal setting with the programmer himself.

Your issues regarding the way decisions are made within the project should be raised with the leadership.

If you don't communicate your issues to the responsible parties then you can't expect them to change.

He should watch the show The Borgias. He should get enough inspiration on how to handle the situation after this.

Reply on news.ycombinator.com