Slashdot Mirror
How Open Source Projects Survive Poisonous People
CoolVibe writes "Two Subversion developers talk at Google about how to keep pests and malcontents out of your open source projects. From the abstract: 'Every open source project runs into people who are selfish, uncooperative, and disrespectful. These people can silently poison the atmosphere of a happy developer community. Come learn how to identify these people and peacefully de-fuse them before they derail your project. Told through a series of (often amusing) real-life anecdotes and experiences.'"
Every open source project runs into people who are selfish, uncooperative, and disrespectful.
Those are easy to deal with. The problem is with people who, under the cover of "doing good to the project", make everybody hate everybody else. Those usually spread rumors around, go tell John that Jack, frankly, doesn't work enough, while at the same time telling Jack that John, really, isn't leading the project in the right direction, etc...
We've had plenty of those at the company. More often than not, those are what we usually called "software diva", people whom management think are indispensable, and therefore should be more or less allowed to do or say anything.
My way of dealing with these folks was usually simple: single them out at the weekley meeting, sum up the shit they've been spewing around, and tell them they're allowed to run free with whatever they thought was best on a local fork of the project for a week and prove they're right and/or better and/or more efficient than Jack or John. Failing to prove it, they'd be relegated to the line-pisser pool, otherwise they could take my place as team lead. Usually the result was the software diva leaving the meeting all offended, and half of the time resigning after a couple of days. Public shame and the threat of putting their supposed programming skills where their mouth is is a very efficient method of putting these people in their place.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
...assassination in the journals. Quick, clean, and ensures they can't just be transferred to another department to create headaches for someone else.
GetOuttaMySpace - The Anti-Social Network
Eric S Raymond poisons the whole movement, not any particular project. To do that, he would actually have to participate in one of them.
The final type of person, the one that bothers me perhaps the most, is the coder or contributor who simply doesn't answer bug reports or emails (whatever the appropriate method may be) at all, even after several weeks of waiting. Are you guys *trying* to turn your users away!?
People really do see those buggy programs, folks. They show up in lists of stuff at places like FM and SF. If you think your code is good and you want to release it, great! But if you won't consider bug fixes, keep the damn thing to yourself and/or contribute your code to an already-existing project instead.
I've been a programmer since 1986 on another platform, but stopped in around 2000 and haven't come back since (outdated platform anyway, so my "skillz" don't exactly translate to modern programming methods), and I have never once considered telling someone off like these examples. What went wrong? When did the F/OSS community start to gain this elitist attitude?
Mod me down if you want, I don't care. I've got the karma to burn.
To do that, he would actually have to participate in one of them.
Can you name a single Linux distribution that doesn't include at least two programs to which Eric S. Raymond has contributed code, EXCLUDING fetchmail?
698 packages on my Ubuntu system depend on libncurses5, which has Raymond code in it, for example.
Did you really watch the talk? Regarding the date-parser contributor, we talked diplomacy quite a lot, but the simple fact was that adding your name to the source code was not negotiable in our community. We never kicked the guy out--he left on his own accord when he realized that our rules weren't going to change to accommodate him.
The whole point of that anecdote was to illustrate the importance of not compromising your community ideals for one person, even if they come bearing code. Stand your ground, and if someone is not willing to play by your rules, then they'll leave.
Oh, and the whole point of the "Poisonous People" title was to a) get your attention and b) address a perceived shortcoming in many open source communities. If we had talked for an hour about "How to have a loving and happy community", everyone would have been asleep ten minutes in. ZZZzzzzzzzzzzzzzzzzzz.