How Open Source Projects Survive Poisonous People 241
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.'"
Video link (Score:5, Insightful)
Re:Link is a video (Score:2, Insightful)
Re:Video link (Score:1, Insightful)
Re:Video link (Score:3, Insightful)
However, your behavior in that thread does illustrate exactly the sort of thing that drives a lot of very intelligent people away from those types of mailing lists. It's not easy trying to help people, with no compensation, when you get that kind of abuse for your trouble.
Re:What I learned working on NetBSD (Score:4, Insightful)
pick your poison (Score:5, Insightful)
On the other hand, malcontents are often malcontent for good reason--look at the dispute over the Xfree86/X.org split. Sometimes,someone who is an effective leader on one project is making a nuisance of himself on another, like when Torvalds was interfering with the Gnome project.
So, it's OK for open source project leaders to dismiss "malcontents" and focus. On the other hand, those "malcontents" are often going to be right and justified, and they may fork your project and make you irrelevant.
Re:Video link (Score:5, Insightful)
Even if the ultimate answer to the problem was "Ubuntu is hopelessly broken," you STILL would not have been justified in acting the way you did. Even if you were paying for the support, that sort of abuse is unnecessary and usually (and definitely in this case) counter-productive.
Re:pick your poison (Score:2, Insightful)
It doesn't take any arrogance, all it takes is the ability to say "No" and not feel like you need to justify your answer to every code monkey who thinks it is his job to challenge you rather then implement the functionality you requested of them.
Having spearheaded many company wide custom software projects one of the few things I have learned is that the three most powerful words you can say to are "I don't know" and that "No." is a complete answer.
Re:Video link (Score:4, Insightful)
You've blown one bad apple entirely out of proportion. Now I'm not saying that we should sweep it under the rug, either, but surely a broader picture, including the myriad uneventful, unnoticed except by those few directly involved, and extremely helpful support threads, would be far more accurate. Yes, the failure to provide reliable support does hurt the image of linux and techies in general. However, your constant rehashing of this single incident hurts those images much much more.
Re:Not every "poisonous" person is easy to spot (Score:3, Insightful)
When I ran a very (very) small project I simply assigned these folk to minor sub-projects away from other people. You either discover that they can work (but don't mix well with people) or that they're incapable.
If it's the second then a public demonstration of that fact will take the wind out of their sails. If it's the first you've solved the problem already.
Seen it... (Score:3, Insightful)
A large part of the video was toned negative. Only the word "poisonous people" is enough to know what they are thinking. Yes, there are mistakes certain people make that can be *called* poisonous, and could indeed destroy your project, but don't label the *person* but the *behaviour*.
Apart from being very undiplomatic, you run the risk of losing good people in your OSS project just because you get anal about someone not 'doing things by the book'.
An example is the "CVS date-parser contributor", where the guy wanted his name on top of the file, but SVN-dev rules stated not to. Instead of talking diplomacy, and getting a solution that satisfies both developer as community - the code was good as they said - they throw out the code *and the person who wrote it*. Maybe this example was bad, and the person was thrown out because of other reasons, but they made it an example in their video so that's the fact right now..
I think I would like a label for OSS projects that handle people this way: cactus-OSS communities - they can grow great software, but press the wrong part and you get hurt so much you don't want anything to do with it.
Seriously, if you're running an OSS project by all means protect it, but try to change the behaviour people portray rather than kick them out. Kicking out a developer should be a last resort, as it on itself could have serious implications for the status of the OSS project imho.
Re:Video link (Score:5, Insightful)
Looking at how much patience and help they showed *you*, I can only imagine at how much they'll help a polite noob!
What really scares me about you though, is that it's been a year since that conversation, and yet you're still this venomous towards them, and still can't see what you did wrong.
Re:pick your poison (Score:3, Insightful)
Well, how do we know that? Most of us only know whats written about them. Sure, they have strong opinions but that doesn't necessarily make them hard to work with.
Re:pick your poison (Score:4, Insightful)
Thank you for illustrating my point.
Re:What I learned working on NetBSD (Score:2, Insightful)
Re:What I learned working on NetBSD (Score:2, Insightful)
Hell, WordPerfect 5.0 ran faster on my old 12 MHz 286 than OpenOffice.org 2.x runs on my 2 GHz Sempron - and had pretty much all the functionality I need in a word processor even now.
-uso.
Re:What I learned working on NetBSD (Score:4, Insightful)
Faster hardware is cheaper than better programmers, and much easier to find, and you know when you got good hardware, but you can think you've got a good programmer and be really wrong.
Commending Subversion (Score:3, Insightful)
If I ask a question on #svn, I almost always get an answer from someone who can point me to where in the manual to look - and that's pretty valuable, since if you aren't intimiately familiar with the product, you might have no idea how to search for what you're actually looking for.
What about usurpers? (Score:5, Insightful)
So I challenged this person's disingenuous claim that he'd created it "from scratch" and asked him to make his source code available, as he should do under the GPL.
Instead he pretended to be indignant, continued to insist he'd "started over," and removed (!) the binary he'd posted (you know, because of his overwhelming indignation). Rather than let him conceal the binary under dispute I reposted it, which caused him to feign even more indignation and call me names. There was some back-and-forth in which I continued to press him for an admission, and in which he continued to stick to his position, and to insult and ridicule me.
After a few exchanges he posted a new build of the driver with various strings hastily replaced. For example, he replaced the word "Magic" with the string "Khash" (same number of letters... odd since he has the source code) and replaced the copyright message with one of his own (again, same number of letters), and he replaced the CVS-generated "Revision" number with a value (0.31) that CVS could never produce. Anyhow, I kept giving him rope, and he kept hanging himself with it.
Eventually, I softened my stance and let things lie, and just asked him to share with me either source code or information to help me get my driver working on TabletPC. He didn't provide either one, and instead he deleted all his posts (smart, because they were very embarrassing) and went on to work on other Hackintosh driver issues. Fortunately, I had been saving his posts all along with the hope of writing an article about "FOSS usurpation" on my website.
I'm happy to say I did manage to get TabletMagic working on TabletPC systems, but even now I could still use some of this madman's insights into ISD-V4 digitizers. Despite his lack of character, this guy is no dummy.
What still astounds me is the striking similarity between this person and other hackers who have done this sort of thing in the past. You might remember a few years ago a hacker had modified a bunch of Mac shareware binaries and was distributing them under different titles, and more recently "CherryOS" was found to be a rip-off of PearPC. What's striking is that whenever these guys are challenged they display very characteristic behavior, producing indecipherable denials that border on the insane, and insulting those who challenge them. In the end they always end up making themselves look bad, and they always give themselves away by the illogic of their denials and their exaggerated bluster.
Now in my case I was lucky. This person had modified my code for use on an unsupported platform and as far as I know he was not planning to sell his work. And when I think about it, it doesn't seem he could do much harm to my project. Nevertheless, it alerted me to one of the more annoying aspects of FOSS software, and my powerlessness against it. To his credit, he did push me to add TabletPC support to my driver which otherwise I might not have done so soon. But overall this experience has been very unpleasant.
Is there really anything an OSS developer can do to combat this kind of annoyance? Are there any smart tools out there for comparing binaries to see if they come from similar source codes? Does the Free Software Foundation or Sourceforge have any kind of policy or resource to help poor saps like me? And in the end, what does it all mean?
Re:Frankly, I'm getting tired of it. (Score:3, Insightful)
That's true to a point, but misses a huge population of contributors: people who release employer projects. I've done this several times. Basically, my boss asks for something, and I can't find anything (even half-finished) that does it. I get a working system up and running and clean it up enough that I'm not embarrassed for my friends to see it, then post it somewhere.
Now, I have no intention whatsoever of maintaining these forever, but that doesn't mean that they don't work, or at least work well enough to be useful. You probably wouldn't want to take my projects and use them as-is, but it might beat starting your own similar project from scratch.
Re:Link is a video (Score:5, Insightful)
Those that may seem to attack open source project in particular without regard to the status of the project are turkeys and probably need to be shunned. On the other had the open source projects that are mavericks that won't listen to user input should also be shunned.
The most important thing about open source that one sees once they use it are the rough edges and incompleteness of the project. Yes, some of them are exquisitely done, others, and there are a lot of them, are poorly organized and implemented as if a firstimer was managing the project. If I were critical of open source it would be the latter and to see the open source project begin to deride the criticism is very damaging.
Amarok, which now is a great project, but with a lot of bugs and some very incomplete areas used to be highly buggy and when people went to their site asking for answers on how to overcome these problems even the administrator would denigrate them for asking questions. In one case the administrators actually attempted to publicly humiliate those asking questions. What they should have done is listen and fix the issues. It is only through some criticism that things get fixed. The windows world is unforgiving, extremely unforgiving. If Amarok plans to move to the windows platform they are going to have to come up with some major changes to their philosophy when dealing with people pointing out problems and asking for help.
An old saying from way back and it is a saying that holds water today is that you never give a programmer a screwdriver because he'll blame everything that's wrong on the computer and try to fix the computer. Another rule is that a programmer should never be charged with testing their own code. Another is that a little observation goes a long way to detecting problems.
If I were to complain about any solid open source project today it would be about gnome. It has some serious foundational issues that need to be resolved. I've laid some of them out for the developers and let others become aware of them. It has at least one major show-stopper that you don't encounter unless you copy mass files over your intranet from a folder to another on a remote drive.
One thing about this guy's article. It won't work. If someone is intent on destroying your project they will and to make them angry by appeasing or using other tactics mostly will backfire. To breed resentment of people giving criticism (that may not be well received by the project) is the most negative thing to happen to their software.
Essentially, you can resolve discontent by listening, fixing the problems, and releasing code that is well tested and relatively bug free. If you want linux on the desktop you need to understand that most programmers in the windows world were forced to improve their quality or die. In open source there's really no competition, especially for those wanting to be just open source projects, so there's little incentive other than personal pride to make a project look and operate beautifully.
Listen to those criticizing your project and correct what they identify. That's the best way to get rid of those that will publicly attack you till you decide to quit.
Re:Video link (Score:3, Insightful)
It's clear from that point that you weren't looking for help, you were "not happy" and just looking to vent your spleen. When you start attacking the people trying to get information about your computer so that they could help you (post #16) while complaining about their chutzpah, that becomes even clearer.
Clearly something with your system is either broken or incompatible with Grub. Sure, someone should have looked up what grub's error code meant which would have gone a long way towards discovering that there was a problem reading from the drive. My personal suspicion is that the drive is fine, and you are (well, were, since this whole episode was over a year ago now) simply the victim of a legacy BIOS that is dragging decades of backwards compatibility with it, including the inability to count harddrives past two.
And yes, since your system is not bootable, you're going to have to find some other way of booting it, whether it's a boot CD or a floppy or a USB key or moving the drive from secondary master to primary slave and reinstalling there. That is the logical next step whether you like it or not.
Re:I'll tell you about this one guy (Score:2, Insightful)
he's right.
Re:Video link (Score:1, Insightful)
Re:Link is a video (Score:5, Insightful)
Why, set up a sourceforge page for $foo-$language-port, and put that person in charge of it, of course.
Seriously, I think this is a common problem, and unfortunately, sometimes those people actually get something released. There's a large number of people who want everything to be written in Python, and get upset if your project is in Java, TCL, or Perl. And should you be crazy enough to admit you wrote a five-line csh script, you'll suffer the kneejerk reaction of a bunch of idiots who shout "CSH considered harmful".
On the other hand, the "let's rewrite everything in my favorite language" is a wonderful driving force in a community. It fosters the us-vs-them attitude, and really motivates people to "show up" the despised opponents. So while the behavior may seem silly, counterproductive, and juvenile, it might well have real-world benefits.
I find it amusing that it's the SVN developers talking about 'poisonous people', as they seem to be one of the most poisonous groups around, as they routinely interrupt conversations about how to do something with CVS with "you shouldn't use that cvs crap, use svn instead".
Point 'em at emacs and aalib, and tell 'em there's an obvious alt-meta-mod4-control-mumble key sequence that will do just what they ask, but you can't right now remember.
Ask for steps on how to replicate it. Folks who know enough to tell you exactly what went wrong don't need your help.
Often, the initial bug report is just to see if someone is there, paying attention. The appropriate response is to ask for information -- you may want a template for this -- and initiate a conversation. "Well, Joe, I don't know enough to answer your question right now, could you tell me some things, like the version of the software, your OS, hardware, and the command-line that failed, along with its output."
All users lie. They omit steps. They forget critical changes they've made to a system, but remember all the trivial changes. They get sequences of events out of order. They fail to follow instructions properly. They are quick to assign blame. They fail to read error messages. They don't know what's important.
Remember, they're frustrated far more than you are; YOU have a modicum of control over the system, because you nominally understand it.