Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming GNU is Not Unix IT Technology

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.'"
This discussion has been archived. No new comments can be posted.

How Open Source Projects Survive Poisonous People

Comments Filter:
  • Tag the story video or videolink to inform.
    • Re: (Score:2, Insightful)

      by HTH NE1 ( 675604 )
      Already doing that, but I also think the links themselves should be marked [slashdot.org] so we won't have to wait for keyword tagging in future.
    • Re:Link is a video (Score:5, Insightful)

      by HermMunster ( 972336 ) on Monday March 12, 2007 @02:35PM (#18321139)
      There are always two sides to a story and I'm sure these guys aren't telling both sides. I think the most important thing is that any open source project needs to be able to take criticism even if sometimes it isn't constructive. If an open source project can't survive criticism then it didn't have the wherewithal to survive anyway.

      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.
      • by gmack ( 197796 )

        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.

        So what do you do when the presented ideas are completely useless? Take for example the suggestion I've seen for every project I've ever been involved with where someone will just stop in and demand the whole project be rewritten in their favorite language. What then?

        What do you do with the person who thinks your text editor needs a vide

        • Re:Link is a video (Score:5, Insightful)

          by SJS ( 1851 ) on Tuesday March 13, 2007 @01:59AM (#18328699) Homepage Journal

          So what do you do when the presented ideas are completely useless? Take for example the suggestion I've seen for every project I've ever been involved with where someone will just stop in and demand the whole project be rewritten in their favorite language. What then?

          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".

          What do you do with the person who thinks your text editor needs a video playback system and demands it's immediate inclusion?

          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.

          What do you do when you just get vague complaints of bugs with absolutely no information about what actually went wrong?

          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.

    • Re: (Score:3, Informative)

      by HermMunster ( 972336 )
      Although some good points those guys were blowing smoke up their own asses. They want to set themselves up as the figureheads to follow for managing open source. Give them 20 more years of dealing with hard to work with people and they'll say everything they said should have been reevaluated. I was troubled throughout the whole thing. They acted like they had all the answers and they had a pool if people and that one project is enough to make someone who has been a solid open source contributor a shunna
  • by __aaclcg7560 ( 824291 ) on Monday March 12, 2007 @11:30AM (#18317757)
    Lock them out and tell them to become Anonymous Cowards on Slashdot.
  • by dmayle ( 200765 ) on Monday March 12, 2007 @11:32AM (#18317781) Homepage Journal

    ...with swamp boots, just like everybody else, right?

    • by DrCode ( 95839 )
      Speaking of Ultima... OSS projects involving that game never have a problem, since Humility is a requirement for every member.
  • Video link (Score:5, Insightful)

    by HTH NE1 ( 675604 ) on Monday March 12, 2007 @11:32AM (#18317785)
    Could we please get video and flash links in stories tagged "(video)" or "(flash)" like is done for PDF links? Especially things that will generate audio which might be disruptive in a work environment and when it isn't necessarily apparent in the URL.
    • >>audio which might be disruptive in a work environment

      Your boss just walked by didn't s/he??

      • Re: (Score:3, Interesting)

        by HTH NE1 ( 675604 )

        audio which might be disruptive in a work environment

        Your boss just walked by didn't s/he??

        No, I don't have speakers on my work machine, flash is disabled, and I can't play any video for that very reason. Well, that and that they're generally a nuisance, so I feel for those that are vulnerable to such things. It would just be nice to be informed a little more prominently than having to check every URI's destination.

        For PDFs at least one has the option of a client-side stylesheet to inspect the ends of t

    • by xeoron ( 639412 )
      I am all for tagging. Just one thing-- am I the only one who looks at the url address before opening a new tab/window?
      • by HTH NE1 ( 675604 )
        I try to look before I click, but it is tiresome to have to do it all the time. I use stylesheet rules to alert me to various issues like javascript: links, PDFs, and goatse so I don't need to run my finger over a link and hope I'll actually see the actual link's address in the status line. Sites like fark.com run off-site links through a redirector to track story popularity; others do the same but use Javascript to rewrite the status line to hide the redirector from you. And who knows when something und
  • SVN Obliterate (Score:2, Interesting)

    Maybe if you would just implement SVN Obliterate [tigris.org], you'd be pestered less. ;)
  • by Rosco P. Coltrane ( 209368 ) on Monday March 12, 2007 @11:43AM (#18317969)
    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.
    • I wish that would work at my company, we are big enough that instead of this working it'd likely backfire into the person doing this causing a hostile work environment and being fired for it... Sounds like it'd be quite effective at getting the point across though.
      I work in a service position, equipment maintenance specifically. I have a problem with my customers giving me overly vague complaints about a piece of equipment being broken (along the lines of the "something broken, something fixed" AF workord
    • Re: (Score:3, Insightful)

      by mutube ( 981006 )

      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.

      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

  • hmm (Score:5, Funny)

    by nomadic ( 141991 ) * <nomadicworld.gmail@com> on Monday March 12, 2007 @11:43AM (#18317983) Homepage
    Every open source project runs into people who are selfish, uncooperative, and disrespectful.

    AKA "coders".
    • >>Every open source project runs into people who are selfish, uncooperative, and disrespectful.

      >AKA "coders".

      But seriously...the slashdot summary made me think of one OSS project in which I participated to a very small extent. On this project, I submitted one patch to deal with a bug that was affecting me. The patch was accepted, and that was it. So my own role was, I hope, a positive one, but extremely minor. I was actually thinking of getting involved more deeply in helping out with this proj

  • by Billosaur ( 927319 ) * <wgrother@optonline . n et> on Monday March 12, 2007 @11:55AM (#18318145) Journal

    ...assassination in the journals. Quick, clean, and ensures they can't just be transferred to another department to create headaches for someone else.

  • by terraformer ( 617565 ) <tpb@pervici.com> on Monday March 12, 2007 @12:03PM (#18318253) Journal
    There was a guy named Ilya who would clash with people regularly on perl5 porters back in the 99-00 days but I tell you, he was a huge contributer to perl and it would not be where it is without him. But he did cause a lot of social issues within the group and we lost other really good developers because of him. Not sure where the net loss/gain fell on that one, but it is an interesting problem to have witnessed first hand.
  • pick your poison (Score:5, Insightful)

    by oohshiny ( 998054 ) on Monday March 12, 2007 @12:15PM (#18318427)
    People like Stallman, Torvalds, or van Rossum are not the nicest or easiest people to get along with. Nor, for that matter, are commercial software leaders like Jobs or Gates. It takes a certain degree of focus and arrogance to lead big software projects and to make the tough decisions that need to be made.

    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: (Score:2, Insightful)

      by Anonymous Coward
      It takes a certain degree of focus and arrogance to lead big software projects and to make the tough decisions that need to be made.

      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 wor
      • by oohshiny ( 998054 ) on Monday March 12, 2007 @12:45PM (#18319023)
        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.

        Thank you for illustrating my point.
    • Re: (Score:3, Insightful)

      by Cee ( 22717 )

      People like Stallman, Torvalds, or van Rossum are not the nicest or easiest people to get along with. Nor, for that matter, are commercial software leaders like Jobs or Gates.

      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.
  • by VanessaE ( 970834 ) on Monday March 12, 2007 @12:30PM (#18318677)
    In the past I've run into a few coders on different projects, some who are just contributors, others who are the "main" coder on some project. More times than I can count, I've had coders tell me, "Oh, it's your hardware, my code works fine, sod off." That's just plain laziness, when the coder won't entertain the idea that maybe, just *maybe*, their program is buggy. Then, there's the other type I've encountered that says, basically, "I wrote this program for myself. You want Feature X, you code it!" All I have to say is that if the program was written for your own use and you didn't want people filing bug reports, why the hell did you release it to the world? All you're doing then is giving open source a black mark.


    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.

    • Re: (Score:3, Insightful)

      by Just Some Guy ( 3352 )

      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.

      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

    • Re: (Score:2, Interesting)

      by netpixie ( 155816 )
      > Oh, it's your hardware, my code works fine, sod off.

      This is usually a synonym for "you have not provided me with enough information to reproduce the problem". Remember, coders hate admitting they don't know something, even if it's because you haven't told it them.

      > why the hell did you release it to the world?

      Altruism. Sometimes code from a new project that doesn't actually work is easier to read/fix/reuse than code from some enormous open source behemoth. q.v. Panda and xpdf.

      > All you're doing t
    • by Rakishi ( 759894 ) on Monday March 12, 2007 @02:42PM (#18321223)
      "I wrote this program for myself. You want Feature X, you code it!"All I have to say is that if the program was written for your own use and you didn't want people filing bug reports, why the hell did you release it to the world?

      I've found lots of such programs useful, if the features in already don't do it for me I can either modify the code nyself and add it.

      All you're doing then is giving open source a black mark.

      Oh, I'd say you were. Open Source isn't about having someone do something for you, its about having the ability to do it yourself (ie: have source code and can modify it). How about instead of telling someone who is likely busy and gains almost NOTHING (save an ego boost) from more users to code something for you for free you instead do it yourself or maybe pay them for it. Hell many of these people are getting paid for the parts they're coding for their own use so you essentially want them to work for free to implement what you do while they'd get paid to implement what they need.

      They're simply being honest about who they're coding the project for, not everyone is unemployed and has 60 hours a week to burn on a hobby.

      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!?

      It's likely that many gain very little from users, they're not a company and have no incentive to reply to you. It's likely, as someone else, mentioned that if your email was more useful then they would answer. Possibly they already know of the issue and are too busy to answer, that's life.
    • if you won't consider bug fixes, keep the damn thing to yourself
      I'd rather everyone released their code. I can sort it out just fine. Somehow, good projects have a habit of floating up. If it's not a good project, then we can perhaps rip stuff out, or see how it's not to be done.
    • Welcome to open source. Finding a 360 degree altruist is a bugger of a problem, finding one who can code is even worse, finding one who can code and can write an intelligible reply and your down to a handful. If those handfull arent so busy as to be able to handle some newbie question, thats a bloody miracle.

      So dont look a gift horse in the mouth, or complain about the color of a free bike shed. If you need something that badly pay for it, or build it yourself. If someone was kind enough to build somet

    • Then, there's the other type I've encountered that says, basically, "I wrote this program for myself. You want Feature X, you code it!" All I have to say is that if the program was written for your own use and you didn't want people filing bug reports, why the hell did you release it to the world? All you're doing then is giving open source a black mark.

      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 th
    • Incidentally there are explanations for some of the behaviour. For example the "you want feature X, you code it" is roughly saying that if it is important to you, then it should be important to you! It is quite likely that the person you are talking to already has way more than enough to work on. What they really meant to say was, "I already have more than enough higher priority items to work on. If you want new feature X sooner because it is a higher priority to you, then you should code it or find som
  • But the project itself is a good idea.

    Fork?
  • Seen it... (Score:3, Insightful)

    by thrill12 ( 711899 ) on Monday March 12, 2007 @12:38PM (#18318857) Journal
    ...and have serious problems with some of the things they are advocating.
    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:Seen it... (Score:5, Informative)

      by slipsuss ( 36760 ) <sussman@@@red-bean...com> on Monday March 12, 2007 @12:59PM (#18319281) Homepage
      I think you misunderstood that part of our talk.

      We didn't boot any person at all, we simply rejected the offered patch. The person wasn't a member of the community, just a drive-by patch contributor.... we didn't "throw him out", because he wasn't "in" to begin with! Patch contributions are great things, but if we can't come to an agreement, then that's the end of things. The person wasn't interested in resubmitting without his name attached to the patch, so we had to reject the patch. Our honest hope was that not only would he contribute his patch properly, but that he'd become a regular committer too. Instead, he was annoyed at us and walked away. C'est la vie, we're not going to change our code submission rules for a single visitor. Twas a shame.

      • by Raenex ( 947668 )
        Oh good, I can get your ear!

        I just got to the part of the talk about limiting your scope. Subversion's stated goal was removing the bad stuff from CVS. One of the things I hate about CVS is that it puts .cvs directories in your code, interfering with tools that scan your source code. Subversion copied this behavior :(

        Sorry for the off-topic rant, but this has been nagging me for some time and I had to get it off my chest.
        • Actually CVS puts a 'CVS' (without dot) folder in your folders. That's annoying because I actually see the folder - I don't want to see it.

          As for the '.svn' folder - is there any other way they could have implemented it? They could put all the information in a single file, but how do you locate that file when you're in a subfolder? I'd say your tools are broken if they can't be configured to ignore .svn folders.
          • by Raenex ( 947668 )

            As for the '.svn' folder - is there any other way they could have implemented it?
            Yes, they could have mirrored the directory structure in a separate directory.

            I'd say your tools are broken if they can't be configured to ignore .svn folders.
            I'd say any tool that imposes itself in ways that interferes with other tools is broken.
            • "Yes, they could have mirrored the directory structure in a separate directory."

              And where is this seperate directory? How is subversion supposed to find it? Would you have to put a config file in every folder pointing to that folder?

              "I'd say any tool that imposes itself in ways that interferes with other tools is broken."

              Suppose my filesystem browser doesn't support hiding dot files, and dot files clutter the screen. KDE makes a bunch of dot files. Is my filesystem browser broken or is KDE broken? According
        • Re: (Score:3, Informative)

          by slipsuss ( 36760 )
          We imitated this CVS behavior because it achieves two feature goals:

          1) severability: you can 'break off' any part of a working copy, and it still functions as a standalone working copy.

          2) portability: you can transport a working copy to different disks or machines, and it still functions.

          That said, we're now re-evaluating the utility of these features... it seems that few people actually use them or care. In svn 2.0, we might just go for the 'all metadata in one place' design, much like svk and other sys
    • Re:Seen it... (Score:4, Interesting)

      by fitz ( 2205 ) on Monday March 12, 2007 @01:10PM (#18319489) Homepage

      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.

  • (Would someone summarize? Don't have time to watch 55 minutes of talking head video.)

    MMORPGs have the same problem, with "griefers". The trick is to design the system so that a griefer can't annoy a disproportionate number of people.

    The classic line is "It takes ten honest people to support one crook". That's very real; when the fraction of troublemakers gets too large, nobody can get anything done. Happens routinely in bad neighborhoods and war zones.

  • by XO ( 250276 ) <blade@eric.gmail@com> on Monday March 12, 2007 @01:16PM (#18319597) Homepage Journal
    I would like to commend the Subversion community for being the one piece of open source software that I have used in several years that had a support community (between their websites, and the #svn channel) that is not just full of arrogant elitists.

    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.

  • by Slur ( 61510 ) on Monday March 12, 2007 @01:34PM (#18319949) Homepage Journal
    I have a related problem that I've been trying to understand and cope with. One day while searching for information to further my OSS project TabletMagic [sourceforge.net] I discovered a discussion board where someone had simply modified an older version of my driver to work on TabletPC computers, and he was claiming that he'd "started from scratch" in creating it. I downloaded the binary and examined it, and it was clearly built from a modified version of my source code. It even had my name and original copyright message in it, and printed these to Terminal when started.

    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?
    • 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.


      And your answer, courtesy of /usr/games/fortune:

      "Insanity is the final defense...it's hard to get a refund when the salesman is sniffing your crotch and baying at the moon."

  • by SpaghettiPattern ( 609814 ) on Monday March 12, 2007 @04:05PM (#18322493)
    First of all, judging from the video I must say Ben and Brian excel at managing projects.

    Now, there seems to be a sort of OSS code of honour which is: "R-E-S-P-E-C-T" (gesticulate idiotically like some rappers do.) How often did Ben and Brian say the word? If you see this as a management training video, why do they bother to educate already educated people? Isn't respect a matter of course?

    In corporate interaction respect is implicit. Disrespect bares consequences.

    Why is it that so many OSS developers require some 'hood protocol to communicate? I sometimes feel like in a movie where it's us against the bad guys in power and that therefore we do funny hand shakes to distinguish ourselves. (OK, I exaggerate a bit but understand what I mean.) It's so tyring and time consuming. In corporate coding you ask for stuff, get an answer and move on.

    I remember one time when it took quite some while to get an answer from a developer for some trivial issue. I made a remark saying that the guy most likely had other more urgent things to attend to than my little issue. This is a compliment; It means I appreciate some horribly busy guy is willing to do some shitty work for me. The guy in question got mad and started to lecturing me. He of course never touched the fact although my issue was minor, he was horribly late in his reply. To set him at ease I had to spend time on explaining the remark. This is so tiring and puts me a bit off OSS coding. I nevertheless continue to contribute.

    Message to the OSS prima-donnas: Read also books on communication and social techniques. They contain usefull stuff you need to know when communicating. See them as manuals on social behaviour.
  • at about 26.20 if you wanna get to the meat of the article.
  • I'm guilty of being a "poisonous person" myself and I often didn't see it within myself. So the discussion is also good not only with regard to identifying poison in others, but also within one's self. We're not inherently poisonous people, but sometimes either through frustrations that need to be vented or even through really good intentions, you can become poisonous.

    It's also a really good discussion in that I agree with the presenters a great deal. This is especially true when it comes to divorcing yo

We must believe that it is the darkest before the dawn of a beautiful new world. We will see it when we believe it. -- Saul Alinsky

Working...