Forgot your password?
typodupeerror
News

Feature: Conflicting Open Source Developers 119

Posted by CmdrTaco
from the its-not-all-fun-and-games dept.
A reader who has asked me to post his feature anonymously has written up the recent events surrounding a Conflict within the development of an Open Source package. It talks about what happens when egos collide over Free Software. Its a true story, but with the names and versions changed to protect those involved. This is a real problem that I'm sure many of us have seen on mailing lists before. What do you think?

The following was written by a Slashdot Reader who wants this posted Anonymously

Conflicting Open Source Developers

I have a question for you, and a point for discussion. What "normally" happens to an open source development project when people writing code for it don't get along? How do open source authors deal with conflicts

with other open source authors? Let me relate the story about my first experience maintaining open source software, as I think it's a pretty good illustration of this. I used to work on a program (for the sake of this discussion, let's call it P, for Program) that I volunteered to take over development work on around two years ago, after the original author produced version 1.0, and had no more time to work on P.

At the time I took over maintenance and development for the package, I had lots of time free at the business where I worked. My boss was understanding enough to allow me to devote a few hours a week of paid time to P, which I believe doesn't happen often for open source authors.

As time passed, our business grew, and I had less and less time to work on P. I managed to release an alpha version with some improvements, but some people weren't pleased with the pace of development. One of them took it upon himself to start work on his own version of P. For brevity, I'll call him Mr. J, for Jerk.

Now, normally I'd cheer this, since it's what open source is all about. However, it seemed what Mr. J really wanted was acclaim. I had released version 2.0 beta of P, based on the 1.0 version from the original author. Mr. J released a version he called P 1.2, also based on the original 1.0 code, with his own modifications. This generated a lot of confusion, at least in my opinion, since he had the same name for his package as mine, and similar version numbers. So, I asked him to please change the name of the package to something else to clear things up.

His response was to publicly declare that he should be named the official maintainer of P, since I was taking too long. I should note that at this point I would have happily turned over development to him, if I'd thought he could do the job well. I didn't think he could (putting it mildly). I'm going to skip over the discussion we had on the subject on the P mailing list (on my mail server) since it includes a lot of childishness on the part of Mr. J. Suffice it to say that things ended up with Mr. J calling me a few names, and vowing to take over P as part of a larger project he was working on.

Mr. J proceeded to take a copy of the names on my mailing list, and create his own list. He declared his version to be the official version of P, and ceased to take part in the original list I had set up. After all the argument on the original list, I was glad he was gone.

That is, until someone posted a question about my version of P to his list (which he had subscribed me to as well).

He took the opportunity to publicly call me a few more names, and make some comments about my lack of progress. I had had enough at this point, and mailed him telling him that I didn't want him to mention my name at all, ever again. I was hoping he'd start completely ignoring me, leaving me free to work on P quietly, without his interruptions.

Boy, was I wrong. Mr. J proceeded to mail me back and tell me that he would do whatever he pleased (again, putting it mildly). He also added a text description offering to let me perform an obscene act on him to his .sig file, which he used publicly on mailing lists and whatnot.

Completely appalled at this point, I e-mailed his providers for web space and connectivity, threatening them and him with lawsuits if he didn't remove my name from his postings. This got another nasty response from Mr. J, but eventually did get him to remove my name from his sig file.

This brings me to present time. I now have such bad feelings associated with the whole affair that I don't like to think about P, much less work on it. I've stopped working publicly on it, in fact, and I only do development on in-house versions that will never see the light of day.

My question for Slashdot readers is this: Is my experience common? How do open source authors deal with this kind of thing? Any suggestions as to what I should have done instead?

Regards,
John Q. Hacker

This discussion has been archived. No new comments can be posted.

Feature: Conflicting Open Source Developers

Comments Filter:
  • by Anonymous Coward
    Does anyone know what project "P" is?
  • by Anonymous Coward
    If you can't find time to work on this program "P", and don't like the way this other guy is continuing development, pass the project on to someone you think will do a good job. Assuming you're correct in that the 1st guy can't handle it, then the new version will eventually succeed.
  • by Anonymous Coward
    Okay, I took part in a 'failed' OSS project as an undergrad (this was about 7 years ago) and since then I've done my time in the industry. I think I can offer some useful perspective.

    These petty turf wars and ego clashes affect OSS projects no more or less than commercial projects. The DIFFERENCES:

    (1) OSS squabbles are on the public record where anyone can read them. Hence it looks like OSS projects, in direct contrast to the pristine world of commercial software development (ha!), are consumed with infighting.

    (2) As you might guess from (1), we commercial programmers have to deal with least as much political bullshit as OSS programmers. But we get paid to put up with this stuff. By contrast, Free Software developers get drained by interactions with abrasive personalities and don't have a carrot (paycheck) at the end of a stick to keep them going.

    Basically, I can understand why someone like Stallman puts his faith in the cathedral model of development. Because opening up the development process puts you at risk of having to deal with a bunch of real assholes, who can suck the life out of a project faster than you can say 'Windows2000'.
  • Yeah it sounds like the development of the portslave project.
    You can find 2 homepages for it now, but do a search for 'portslave cistron radius'
    and find it.
  • Yeah... this is true...

    The best distributed efforts (at least that I've witnessed or been a part of) usually go something like this:

    You have the Maintainer, or Cheif Programmer. This guy acts as the focal point... This guys job is to design the program... (Okay, we need an object that can do X, and a routine to do Y, and a config file with Z) and to hand it out to other people...

    The other programmers email their willingness to participate to the cheif, who in turn sends them an "assignment." The programmer codes it, and sends it back.

    The cheif puts it all together, tests it, and realeses.

    Of course each programmer can help each other, everyone can suggest things, and patchs from the general public should be accepted..


    Well, worked for me. YMMV.
  • Ahahahahahahahahhahhahah....

    Thanks for the laugh, Tim... I needed it....

    Hmm... but if it were NP, would there be peices missing, or would it be complete?

    (btw, uber-gene still rocks :-P )

  • by Zack (44) <{zedoriah} {at} {gmail.com}> on Tuesday July 13, 1999 @05:11AM (#1805632) Journal
    Egos clash... that's why... There's always someone who wants to take more credit than anyone else gets... there's someone who wants to be known as "the guy" who wrote that "kick ass" program.

    The person who owns the code, and hence the title, was the original author, correct? And when he gave it to the 2nd guy, then the 2nd guy owns it. And until such a time that he gives it up, Mr. J can not claim that the code is his.

    Mr. J should have renamed it, (say to NP) and mentioned that it was based on P... He could even mention that he started his own version because he wasn't happy with the other version.. that's fine too...

    Of course, the mature thing to do would be to work together... to put the egos aside or to accept the credit as a team... Open source projects work better when there's more than one person working on it...

  • Free Software and Open Source are synonyms.
  • No.....I think you got moderated down because somebody failed to see (as I do) that BOTH parties were acting childishly (the opinion you voiced).

    What are your reasons for thinking BOTH parties were acting childishly?
  • Posted by 2B||!2B:

    A couple others and I have created something new which, after several revisions, is almost ready to release open source. (I won't say what it is until I have it properly hosted on a new web domain, but it's very cool and nobody has done anything quite like it before ;-)

    To avoid the nightmares that can happen with an open source project, I'm probably giving it its own web domain (so it's always obvious where the real distribution comes from), and I'm going to open it up to threaded discussion by anyone who wants to suggest changes/improved code/etc. I think the problem with program 'P' mentioned above is that there was no mechanism in place to fix/extend it (therefore not really open source at all, right?). My rule #1 on my own project is going to be that if I don't have time to fix it (or if somebody has a really cool idea to extend it or improve it) I'm certainly going to find a way to let others do so. Any changes would have to get past me and anyone else involved in maintaining the project to ensure stability.

    As we've gone through revisions of it, we've found that the best improvements have come through a conscious effort to better its ability to handle unforseen extensions and changes once it's released. Few projects do that (heck, even ActiveX might not have sucked if M$ had let anybody external to the company have input on how to do it right).

    (The open source part of the project is a handful of XML DTD's (fairly complex ones), while I will be creating commercial software that uses them. Open source has shown itself to be an extremely viable way to get improvements in the XML, while still letting me do a commercial project. If someone who adds/fixes something wants credit for it, I'm not too proud to mention their contributions. If somebody else does a better commercial implementation than me using my own framework, they deserve the money!)
  • Wasn't the major sticking point with Xemacs the fact that Lucid did not want to assign copyright over to the FSF?

    Lucid did assign the copyrights of all Lucid-authored code to the FSF. Anyone who tells you otherwise is lying.

    Why don't you stop beating this dead horse already? XEmacs still exists and is still popular because many people find it to be better than Stallmacs in many ways. End of story.

  • I don't do much Open Source programming, but
    this experience reminds me of an incident
    that happened a few years ago.

    'twas the time of BBS's and I was a door programmer, in other words, all those nifty
    games and tools like that. I had created
    a nice door that was actually very popular,
    it can still be found on pcmicro.com I think.

    Anyway, besides the point. What happened is
    that when I was at a convention (we had those :)
    another door programmer saw me working on
    an early beta version of that program. When I
    left my PC alone for about 1 minute (had to get
    a drink) he copied parts of my code without
    me knowing it. After he'd done that, a week
    later he released practically the same thing
    I had been working on for a few weeks, saying
    I was ripping him off and that I should cease
    writing that program.

    Ofcourse that ticked me off because who'd like
    to see their hard work stolen and mauled?
    What I did to resolve that is release the full
    source to that door (version 1.0 too) and
    publicly asked the other programmer to do the
    same so people could compare.

    The other programmer never did and made things
    a little worse by claiming I copied *his* code.
    Then I got really pissed, spent a week writing
    version 2.0, released that and basically
    smacked him upside the head with it. Since
    version 2.0 was a lot different than 1.0 he couldn't possibly claim I stole his code or
    claim it was the same program (I changed the name). He attempted to copy me again, but
    this time without any code he could copy he
    failed miserably.

    I basically turned it into a contest of "may the best program win". Now this kind of solution
    doesn't usually work with Open Source since
    the source is available and everyone can make
    modifications but I think that the general idea
    when people get into a conflict as described in
    this feature is to just turn it into "may the best program win".

    Just my 2 cents :)
  • by TedC (967)
    Open source projects work better when there's more than one person working on it...

    Maybe.

    With one person working on a program, the end result is conceptually pure -- one person's idea of how things should be done. If you can add two other people with similar abilities and goals, things can get better, since you now have ideas bouncing back and forth on how to improve things. If concensus can be reached, this is ideal. Posting "developers needed for project xyz", however, almost always ends up with about a hundred people trying to get their name associated with the project, and about 10% of the people doing all the real work.

    TedC

  • Evolution is a fine analogy. In community development, the ability be a good community member is a strong evolutionary advantage.

    Even agressive animals may see that evolutionary pressure. A wolf that will not be part of a community will end up loosing the advantages of the pack. Simple agression does not make a wolf an alpha. That requires being all around the best at being a wolf.

    In the case of software development, replace agression with desire to lead a project, and the 'alpha' must be good at (and willing) leading a project.

    If J is still leading P, one day, X will come along with really good patches and J will reject them for reasons other than merit. When that happens often enough, the community will likely elect X to lead the development. (X could even be H). J will either contribute patches to X (stay in the gene pool), or will go it alone (and disappear from the gene pool).

  • hmm too much math at school, i thought that was funny...
  • Somebody has been reading the Harvard Business Review!


    I think this situation is a bit easier to handle in a corporate setting. It is true that egos can be just as inflated, but there is always a management structure in place that will eventualy put its foot down (hopefuly with the best interest of the company in mind). I have even seen a company set up two groups to do parallel development of a project with the intention of choosing the best result at the end. Sure the manager of the loosing group will be pissed, but his/her only recourse is to leave the company.
    Heh.. Actually, I've never laid eyes on the Harvard Business Review, but if they're saying similar things, perhaps they've had experiences similar to mine. :) Most of my experiences in this regard have been gained over 3 years since immersing myself into the free software world, and while working at jobs in corporations.

    I think it's worth mentioning that while it may be easier to handle this type of situation in a corporate setting, the outcome is not necessarily (or perhaps even usually) better. In my experience, the winning side tends to be the one with better political connections, period. Of course, occasionally there are good managers who can see through the BS and will make a good decision, but those have been rare in my career.

    A specific example I have is while working at [insert telecom corp here], at a job I got because I was recommended by a friend. I would continually end up in arguments with him over the technical merits of different approaches to coding a given task. Since he had been there longer and was much more politically inclined than I was, the managers always preferred whatever he proposed. After I had gotten a different job elsewhere, he admitted that he had behaved that way just because he felt threatened and wanted to seem more valuable.

    Another was at a startup where one of the guys was in good with the president of the corporation. He was supposed to be a programmer, but rarely wrote any code, and was supposed to be a Unix admin, but would try to admin by IRC to make up for lack of knowledge and troubleshooting skills. In spite of this, whatever he wanted usually ended up being preferred to anyone else's ideas (except those from the president himself).

    A better-known example is the story of the GECOS operating system, which sometimes gets a colorful little footnote in Unix books. It also has an entry in the Jargon file. In a nutshell, its (sarcastic) nickname became "God's Chosen Operating System", because it was chosen over Multics for development at Honeywell for political instead of technical reasons. (And, according to the Jargon file, also ended up flopping and affecting Honeywell in a profoundly negative way in the mainframe market.)

    The point being - the situations were handled, but not to the benefit of the projects involved. In an open environment, brown-nosing and authoritarian mandates of dubious merit such as these just don't tend to happen.. And, if they do, the code is there for anyone who wishes to bypass the problem. :)
  • Hi,

    Sorry to hear you've had to deal with someone of this caliber. First of all, the right thing for Mr. J to do is to either produce an unofficial patch set (or patched version) and designate it as such, or distribute his own software package under a new name crediting the original as the basis.

    This (done the civil way) happens somewhat commonly. Notable examples are NCSA httpd -> Apache, gcc -> egcs / pgcc (which has since come full-circle with egcs being the new GNU-blessed compiler), and GIMP -> Unofficial DevGIMP (at http://members.tripod.de/gimp/ ) Developers sometimes disagree about the best way to go about things, or have differing objectives. One of the reasons there is such much Cool Stuff [tm] in the free software community is just because anyone can go off and work on some killer feature(s) no one else sees the importance of, or wants to include in the original.

    As for what you can do, first, stay calm. Consider the source of any insults hurled your way. Others will, too. In other words, resist the urge to engage in public flaming. And, procmail is a good friend. Likewise, I would shy away from ratting to providers, or involving lawyers. Obviously, you're concerned about how you're being perceived here. Being the one who isn't being petty / confrontational has definite advantages here. Anything perceived as Big Brotherly or litigious is generally looked down upon by most geeks from what I've seen. For a good example, look at the AntiOnline / Packet Storm articles from a few weeks ago and take note of the general opinion of JP.

    For your users' benefit, you should publically detail the situation, on the website, if applicable, or on the mailing list. Make sure that they are aware what your official version is, where to find it, and that his is a colliding version. You may also want to create a task list of contributions that could be made by people interested in speeding th development, or even stating that you're interested in a competent, responsible developer to take over maintainership. If you have decided to completely stop releasing work on this project, you should definitely let people know that you've orphaned it (golden rule applies here ... it sucks waiting for something that will never come).

    Of course, this isn't unique to free software. Backstabbing and attention-grabbing occur behind the closed doors of corporations, too. Be glad this mess isn't affecting your income. :)

    Good luck!
  • If a society wants freedom, they must be responsible, or else it doesn't work, and you get these kinds of fiascos. I know that sounds like a cliché, but it's true. We want free source code, so let's be responsible, courteous, and considerate of each other. Then the code can flourish.

    I can't believe how many people have no sense of courtesy. Especially over the Internet. I know, it's a lot easier to blast someone you will never see in person, but you have to resist the urge.
  • This is entirely off topic, but I agree entirely... I was trying to figure out why your message was marked Flamebait. If posts that aren't popular or that someone doesn't agree with are moderated down, then that's essentially censorship, which, as we all know, is bad (in general). Luckily, we have the option of reading ALL the posts, and ignoring the moderation, which I do. I do my own personal moderation by not reading the posts that I don't want to.
  • Instead of asking him to just outright re-name his package he should have looked carefully at the changes, and talked about integrating the differences into 2.0. After all, there's got to be some good stuff in both packages, right? I'm assuming that given the version no's that 2.0 had some major changes and 1.2 had some minor ones? So work together.

    The hardest part of OSS is the same hardest part of closed projects: People management. If you've got contributors to your project you need to realise that this is as important (if not more so) than your coding ability. That's why Linux is such a success IMHO.

    Matt.

    perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)'
  • Funny an AC should this.
  • That's the rule, in my experience, not the exception.

    I've virtually stopped making any contributions to any opensource projects for that reason. Still bugtest mozilla all the time though.

    Examples of things I've had happen:

    1) Feature X is missing from program Q. Implement it, send implementation to author. Author says no to including it in the source, then the code *verbatim* shows up in the next version sans any mention who wrote it. I no longer use said program.

    2) Program F has a feature, feature sucks the way its written, chewing up processing cycles. For the sake of argument, lets say its an ICQ program blinking its icons, and causing a 1.0+ load while running as written. Recode part of the guts of the program to allow it to not be so crappy. Author rejects code, then puts virtually identical fix in two versions later. No credit given.

    There are a lot of people out there that talk the talk with opensource projects, but certainly don't walk the walk. I hate the concept of forking a codebase, but there's a lot of real pricks out there, and a lot of projects that would be a lot better if someone forked the development.

    No idea what program the author of that essay is talking about, but without knowing that information, and knowing the other side of the story, there's no way of knowing if that same situation didn't happen. There are too many opensource projects that reject contributions and changes for ego reasons rather than technical merit. People like Linus Torvalds are quite the rarity.
  • Indeed. Looking at the mailing list, the blow-up happened in November 1998, with message 1 [linuxrouter.org] and message 2 [linuxrouter.org]. It looks like Mr. J is quite responsive to user questions and has time to actively maintain the code and from the mailing list archives, seems a fairly reasonable guy. (His interactions with Mr. JQH are rather prickly, though.)

    This reminds me of the ESR/TED battle over ncurses; when ESR started taking offense, TED had been issuing weekly patch sets for some months, answering questions on the mailing list and Usenet, and being generally very responsive, while ESR hadn't issued any releases in months and wasn't very visible at the ncurses maintainer. I was surprised when ESR suddenly re-emerged and started complaining about TED hijacking the code. People don't take over control of packages lightly; they do so only when forced to because the original maintainer appears to be inactive.

  • It's open source, dudes. It's all about technical superiority. If Mr. Jerk's changes were worthwhile, they could be merged back in with your source base, provided they weren't too buggy, and weren't totally backwards from the original design.

    Instead of fighting over ownership of the code base, redirect any discussion to the technical matters at hand. Is this good for the program? Is there a better way to do this? The primary purpose as *maintainer* of a free software package is to manage the multitude of modifications that other people generate. You don't have to generate all the changes yourself, you just have to make sure the ones that are submitted are compatible with the code base. Getting other people to do the work is part of the fun. =)

    You may also wish to check into the history behind the Xemacs/GNUemacs split. There were some fundamental design issues (and ego clashes) that resulted in the original split, but both groups borrow code from each other nowadays, and both versions of emacs are better for it.

    Good luck on P.
  • huh?

    Well, yes. Ego clashes are very common. That's part of what open source software development is about. Most of the time a project gets started because the original author has an ego clash with the existing software (Linus with DOS/Windows). They go off and develop their own version.

    But, the true power of open source is that others can develop too! That is, if others want to contribute, they should be able to!

    Now, the hallmark of a GOOD open source maintainer is that he keeps everyone happy. This is done by rolling in changes as they are approved. Linus is a prime example of a great open source maintaining.

    ** Martin
  • I'm wondering if it might be time for the
    "community" to come up with the equivalent
    document for OSS projects.

    Things like - In OSS it's acceptable to fork
    from an original project - but there are
    polite ways and rude ways to do this.

    It also seems like it's getting to be time to
    come up with a "How to manage OSS projects 101"
    text book. There are several successful models
    and a few that have flopped that would make
    great case studies.

    Just a couple thoughts that seemed relevant.

  • It seems that one of the potential pitfalls of open source development is the lack of a truly structured hierarchy that is unavoidable in the corporate world. Openness and freedom are nice, but they can lead to all sorts of unproductivity.

    Well, as Rob of Enlightenment brought to light, this same kind of thing happens in companies or other hierarchies as well.



    I guess I would be really worried about it if both of them ended up on the Jerry Springer Show, yelling, "My KungFu is better than yours! Say it!", throwing their cell phones, pagers, Palm Pilots and reference manuals at each other...



    These things happen all the time...

  • by larien (5608)
    Yup, Bernstein wrote qmail. The fact that his personality is, well, objectionable has put many people off using qmail (I use it here at work, and it isn't too bad). He has his opinions on the 'right' way to do things and doesn't like anyone telling him that his way is 'wrong'. The qmail list archives are full of that sort of argument.
    --
  • by larien (5608) on Tuesday July 13, 1999 @05:16AM (#1805655) Homepage Journal
    Please don't let stories like this put people off developing open source software. Yes, there are jerks out there, but there are some cool people as well.

    About my only contribution to open source software has been adding Solaris support [rgu.ac.uk] to XMMS [xmms.org]; I've put a fair bit of work into it, but others have been forthcoming with patches, modifications and rewrites. Nobody has tried to claim excess credit for work or tried to fork it off, perhaps because I've been willing to accept that (a) I am not a brilliant programmer and (b) others can do it better. Noone has insulted me or called me names (one person said the code was a mess, but I agreed with him; he was one of the coders who supplied fixes). In short, my only experience within open source software has been good.

    Open source projects can be very successful; just look at Apache [apache.org], which has scores (hundreds?) of developers. However, the larger the project, the larger the requirement for a core developer or small core team to coordinate efforts.

    In this case above, the maintainer perhaps couldn't devote as much time as he would have liked to the project (or as much as it deserved?) resulting in Mr J. trying to take over.

    The world is full of jerks, and unfortunately some of them use computers. Try to make the world a better place by not being one of them.
    --

  • It would be nice if things could work this way.

    I know another package which went through something like this. The original author produced several versions. It was heavily used. However, updates occurred less and less frequently. A mailing list set up for the package carried numerous bug fixes and enhancements. The original author seldom posted acknowledgements, etc.
    He did occasionally promise a future release, but
    several years went by without it appearing.
    Eventually some of the mailing list members attempted to gather all the patches and enhancements up and create a new release, with a new name. The author then appeared, pronouncing how by making this release, they just adding months if not years to his work at creating a new formal release. Of course, any attempt to discuss, justify, or even report bugs and enhancements resulting in "more delays".
    As far as I am aware, 8 years later that promised release never occurred. The mailing list members were 'scared off' by all the huffing and puffing (unfortunately, I don't have any of the old mail archives for specific words used, but I seem to recall semi-threats related to copyright language in the original distribution). And so the package continues to languish.

    Another 'freely available source' program had even a bigger nightmare. Though the source was made available, the copyright/license explicitly made it 'illegal' to distribute the source with any modifications. Later, the author commercialized the package, then sold the package and company which I think may have sold it again... anyways
    the original program, which currently bears no resemblance to the final, now likely unsupported applicaiton, still can't be distributed with updates. So people have to distribute sets of patches to be applied against the years old source release.

  • I agree with your last statement, that open source is one of the only (if not the only) development model that would allow the project/application to survive a political/ego induced problem as was detailed above. And that is a good thing... a testament to the power and utility of open source development. I also agree that removes limits on creativity that is found under closed source models.

    But you also seem to indicate that in order to really be considered operating under an open source development model, the project can't have any authority mechanism in place for how the code develops. As if chaos in the cvs tree with little or no direction is the only viable path to follow to be considered open source. This, I think it's important to say, is not true.

    Any successful open source developed application I've seen has followed an implementation of having at least one person at the top of the project who brought it all together. At least one person to filter the chaos and make it into something cohesive. Open source is just what you said - a model - not an implementation. Make sure you don't miss the point.

  • At least one person to filter the chaos and make it into something cohesive.

    Very good point. Let's not forget it.

    Basically, for each of the M versions of P that might exist, there needs to be some amount of leadership leading the development of that version of P. Where open source wins is that there's no corporate structure dictating who the leaders are. Rather, much like ducks do when flying in formation, whoever has the most energy leads the wedge, and as one tires, another from the pack leads. And if one duck is particularly eager, he's welcome to start his own formation, but there's always the existing bias not to which keeps things at least somewhat clustered.

    --Joe

    --
  • Structure hierarchy is nice, but can lead to all kinds of unproductivity. :-)

    Simon
  • Wasn't the major sticking point with Xemacs the fact that Lucid did not want to assign copyright over to the FSF? Personally, I think it's their prerogative, and it's commendable that Xemacs/GNU-Emacs are still highly interoperable. Just that XEmacs is much more highly developed, and it's even smaller now.
  • Best thing that happened to P, perhaps. To civility, no. What sort of rude things WERE in J's .sig, and what right did J have to resort to personal attacks?

    I'm a MOOer, that means I'm an enthusiast of the variety of talk-style MUD (as opposed to combat-style) called LambdaMOO (both a program name and the name of its first installation). When the original maintainer of LambdaMOO (or just MOO, since it totally replaced the original MOO) passed the torch on to another, we saw a bugfix release, and nothing more. It has been years now, and the promised 1.9 version has not arrived, and 2.0 is just not forseeable. Some others have taken it upon themselves to write performance releases, but they let them be known by different lettering for the patch levels ("r" for "rogue" instead of "p" for "patch"). So moo-1.8.0r6 is the sixth "rogue" patchlevel to moo-1.8.0p6 (making a total of 12 patches to 1.8.0).

    There's some hard feelings about being let down by not seeing a 1.9 MOO release with new features. Most have lost faith that one will ever be released. But none of the developers creating extra patchlevels have gone off and childishly denigrated the original author for this. It just hasn't gotten personal.

    Even linux has quasi-official forks, they're called ac kernels.
  • Furthermore, rather mature of him to keep the whole thing anonymous, avoiding the /. effect which would, more than likely, help him feel some sort of revenge....
  • by FreeUser (11483) on Tuesday July 13, 1999 @06:13AM (#1805664)
    You miss the point.

    The very lack of a heiarchy of authority, and the freedom we all enjoy to take existing code and run with it in whatever direction looks promising, is one of the fundamental strengths of the Open Source paradigm. What the author described is one of the worse case scenerios for Open Source software -- two people competing for the same recognition, who loath each other and spend more time slinging mud at one another than they do productively writing code. The result? Two programs (P and P' in this case) which are competing for a user base. Both are improving over time. The following possibilites exist:

    JHQ drops development of P, J drops development of P' -- If P or P' have merit, someone else picks up the project and it moves along, sans the bloody rhetoric.

    JHQ continues development of P, J continues development of P' -- two compteting products exist for users to choose from, a benefit for the community despite the poisonous relations and rhetoric between JHQ and J

    JHQ stops developing P, J continues development of P' -- a viable product continues to exist, and anyone who wishes may continue work on P as a competing product.

    JHQ continues developing P, J drops development of P' -- as above, a viable product continues to be developed, and anyone is free to contribute or take over the development of P' if they wish.

    In a closed source environment, subject to the heirarchy you consider so vital, there is a good chance similar internal bickering and politiking will result in unacceptable compromises in the code or direction of development, or even the scrapping of the entire project. At the very least one can expect delays to result from this kind of animosity in a corporate or closed source environment (I've seen it in both academic and corporate contexts). In that case, however, users loose even the possibility of obtaining a program they might have found useful. This cannot happen with open source.

    In summary, open source removes limits on creativity, allows projects to move in many directions at once, and provides a built-in robustness to projects that allows them to survive some of the ugliest interpersonal conflicts humans are capable of devising. Name one other development model that exhibits such strengths.
  • ...can be sought just as greedily as any other kind of payment.

    ESR compared open-source development to the academic world. Ask any Ph.D. student about how bitterly some people in academia can quibble over their share of credit in collaborative scientific work.

  • Guys, it doesn't matter what you 'think' of the definitions of open source or free software. Look them up!

    http://www.fsf.org

    http://www.opensource.org

    Why bother yapping about what you think? Noone cares what you 'think'. If I told you that in My Opinion benevolent means to be angry all the time, would you care? No. The definition does not change based on what anyone thinks.
  • Indeed, one needs to be a better diplomat than programmer. However, if you extend this too far you'd simply end-up with a PHB controlling a drone of OS-slaves. Perhaps this is the reason Mozilla never took off?

    And to take a tangent, thanks for pointing out that X11amp can be used on Solaris - I've been meaning to find out about this for a while.

    Now, back to work - I'm sure RabTech can't waste a sys-admin on Open Source ;)

    http://newwws.linuxbox.com/ [linuxbox.com]
  • It's portslave for sure. It's interesting to look at the two web-pages:
    • Mr. JQH's page [mnic.net] (Erik Green) is visually pleasing but full of whines and gripes (the above article really) about the situation.
    • Mr. J's page [linuxrouter.org] (Dave Cinege) is short and to the point with important news and source. It has no gripes or whines...
    Clearly only one side of the story has been told, to par it's been told by the most vocal side (going by the web-pages). This looks like a leaving jibe by Erik Green...
  • The open source movement is like any other; it has its share of assholes. As was pointed out, the lack of a heirarchy is to blame for the problems mentioned, but that doesn't mean that a heirarchy is necessary, or even desirable.
    I would like to see the originator of a program decide on his/her successor, should one become necessary. Having said that, if we come up with the ideal solution which everyone agrees on, we'll still have to deal with the assholes of this world. They don't all work in Redmond.
  • It seems that the one who posted the letter should have just ignored the guy (J?) who was being the jerk.
    Ignoring isn't so easy anymore if the other guy just continues to defame (expr?) you in public posts (and if I got it right J even called JHQ names in completely unrelated posts - the thing about the signature).
  • by Mart (19570) on Tuesday July 13, 1999 @05:54AM (#1805671)
    Being the maintainer of an OSS project is not a coding job. It's a management job. The two main tasks are
    1) To determine the strategic direction of the software project.
    2) To manage the personnel in your team.
    The amount of code contributed by the project leader isn't so important. If people trust you to do these two tasks then you should be OK.

    What has happened here is a crisis which is probably symptomatic of some underlying management problems. Here are some diagnostic questions:

    1) How "Open" was the source?

    Was there a cvs tree which could be accessed by others(not necessarly anonymous)?
    Did you encourage submission of and discussion of feature requests by the users?
    Was there a list of tasks to be performed for the next version that could be picked up by any keen developer? If someone is unhappy with the pace of development, all you need to do is point to this list.

    2) How well managed was the list?

    Was intemperate or rude language tolerated on the list, or was it gently discouraged? (I was once told off, privately, for using the word "crap". I am not kidding.)
    How was conflict resolved on the list: by trying to reach consensus or by decree?
    Did the users trust you to make the technically correct decision?
  • Well for one thing you don't know that it was Free Software in any sense of the word. It may have been under any other license not nessecarily GPL. I do presume you meant GPL by Free Software. There are numerous other ways P could have been released. Open Source by general definition covers more than Free (speech) Software. And really I would think one would like to be as descriptive as possible. The problem described doesn't effect Free Software alone, it effects Open Sourced Software. Just a technical difference.
    -cpd
  • The words sprint, run, jog are technically synonyms too. Yet they convey different meanings. And they may mean different things to different people. To me Open Source means I can see and modify the source code. That's it. No other definitions to me. None. Free software - to me - means that it abides by the GPL (or LGPL I think). This means that anything under the BSD or Artistic or the Netscape liceneces is Open Source, yet not Free Software.
    -cpd
  • "Mr. J should have renamed it, (say to NP) and mentioned that it was based on P.."

    It made a long times i haven't read the GPL but isn't there a clause that say that if you fork a project you must change the name or something like that (this part may also be why GPL code is not compatible with the old BSD license with advertising clause).

    Of course we don't know if this project was GPL'd.
  • It seems to me that the bottom-up development does not always scale well. I believe that there have been examples of that, such as the imperfections in Linux kernel, the unstability of GNOME or like. I don't wish to accuse or undermine any work contributed to the community. However, I'd like to point out to the prominence of "design" which is somewhat ignored at times.

    Now, it's clear that there are no absolute rules for managing or directing or x-ing a free software project. Besides, we'd rather not have any strict rules -- all the excitement would end. In particular, I don't see why there should be a single manager or a management team comprised of, say, 3 ppl. It seems that some ego problems are sure to break out if you insist on duplicating the corporate management hierarchy. [Don't flame me at this point ;) ]

    In addition to this, I don't see any reason why the proper credit for good work would not be granted to the participant. Taking credit is part of the motivation.

    A suggestion may form around the following lines: There should be little distinction between the contributors. The design, implementation, testing, documentation and other leading activities should all be equally publicized and freed. It occurs to me that it is not altogether trivial to achieve this, especially for the larger tasks [thinking about the HURD kernel, GNU ppl couldn't really finish that]

    It's all about the welfare of the people who use the software, and of the people who develop it. There should be a mid-way between a top-down and bottom-up development. The MS coding machine doesn't produce quality. Sometimes patches aren't good enough. But if we did design in the "open", "free", whatever way I think it would be a bit different. /. is sometimes very good at developing "ideas", perhaps the same process may recur at the design time. You aim some features, some versions. You decide on the implementation environment, tools, algorithms, languages... You define modules, do analysis (excuse me, do you have an OOA?), have your interfaces sorted out. The usual design stuff, and the best part is: you do it all together. And still, people can get credit for what they've done.

    What do you think?
  • Let's see how many "this sounds like project X" type comments pop up, count them at the end of the day, and compare it to the number of opensource projects in progress...this will give us a nice percentage, and answer the original question.

    By the way, it sounds a lot like the ncurses project...but what the hell do I know?

    jason

    new hampshire motto is live free or die, yet they do neither. what gives?
  • That sucks if your contributions are taken without proper credit. One can only hope that people who do this are shooting themselves in the foot in the long run because contributors will figure out what's going on and abandon the project.

    However, it's not always so cut and dried as when your code shows up verbatim in the next version. (And if it does, could it just be an oversight? Did you politely point the omission of credit out to the author?)

    Put yourself in the author's shoes. Somebody sends you the diffs for a new feature, but you decide for whatever reason that it isn't appropriate to include that now. Perhaps it is buggy, perhaps you don't have the resources to test it, perhaps it conflicts with your future plans, perhaps it makes the feature set inconsistent, or whatever. A few versions down the road, that same feature may now make sense and you put it in. Maybe by now you've forgotten about the code somebody sent you several months ago. Depending on the triviality of the feature, your implementation of it might look similar, even if done independently. It would be nice to credit the other guy at least for the idea, even if you don't use his implementation, but what if it was something you already thought of long before he sent it?

    This is the kind of thing that makes publishers return unsolicited manuscripts unopened. Otherwise they get sued over every blockbuster that bears any resemblance to anything that's ever been in their slush pile.

  • If you're not paying someone, then don't try to tell them what to do. When you catch yourself thinking, "He should do such-and-such" then DO IT YOURSELF.

    Don't tell the other guy to change the name, he has just as much "right" to it as you do: NONE. Take your own advice, change the name of your code (maybe by adding your initials "P-jqh") to prevent confusion. Make the distinction clear and let the users decide.

    This is no new thing. There are "flavors" of lots of different things. Look at "vi" and "emacs" for example.

    Rick.Miller@Linux.org
    http://execpc.com/~rdmiller
  • by KevinRemhof (29738) on Tuesday July 13, 1999 @05:19AM (#1805679)
    One of the freedoms that Open Source gives you is the right to make and maintain your own version of a piece of software. That is what the author of the article did. The petty squabbling between the two was truly unproductive and not the norm.

    The only way to handle this situation was to break off the code base and develop P as a different product. Ignore the original developer. He was being unhelpful and did not want to help with efforts on the now splintered P.

    So, is Open Source flawed because of situations like this? No. Open Source is a viable way to develop. It may take some thick skin to get through development, but Open Source gives us the right to develop a project our way. If anything, this is a prime example of the benefits of Open Source. The author could have simply spun off his version os P and left Mr. J behind. I am not faulting either party. It was a bad situation that could have been handled as adults, but was not.
  • Somebody has been reading the Harvard Business Review!

    I think this situation is a bit easier to handle in a corporate setting. It is true that egos can be just as inflated, but there is always a management structure in place that will eventualy put its foot down (hopefuly with the best interest of the company in mind). I have even seen a company set up two groups to do parallel development of a project with the intention of choosing the best result at the end. Sure the manager of the loosing group will be pissed, but his/her only recourse is to leave the company.

    It seems that the general concensus is that for OSS, the package maintainer should:

    1. have a well publicised (and agresive) strategic plan

    2. have an open development environment

    3. manage with the knowlege that the only "boss" is the loyalty of the developers on the project
  • But until someone can prove it, we will always wonder if maybe P == NP...

    Tim
  • Anybody else remember Fred van Kempen and his rewrite of the Linux IP stack? It didn't happen and didn't happen and didn't happen. People called each other names, and finally Alan Cox just sat down and started improving the existing code.
    -russ
  • by kcin (34043)
    That's trolling? Idiot moderators.
  • by Zurk (37028)
    just do what i do. Post up J's version to your site, putting it something like this :

    Program name , Version , Author , Download , Comments
    P 2.0b You XXXXX Whatever
    P 1.2b(j) J XXXXX Modfified by j (j@j.com)

    Let ppl download whatever they want and leave it at that. Thats what i do..and i never have a problem.
  • ...it seems like both parties in the story are very immature people. Rather than responding with pointed messages, the author of the letter could simply have done what he wished the other party to do--ignored him and gone quietly on with his business.

    As far as I got it, Mr. J just continued his angry rants about P. That's plain childish and IMO it's all too understandable that JQH got fed up with it.

  • Maybe we should first unmask you, Mr. AC.

    Mr. Hacker has decided to stay anonymous, he even anonymized Mr. J and the "P" project. You should learn to accept this, just as we accept you staying anonymous.

  • When we have freedom of speech, there are those who abuse it. But the advantages largely outweigh the disadvantages. Unfortunately, the original P was stopped. I'd recommend Darwinism, since that is what makes Open Source / Free Software great. The arrogance that this Mr. J showed would eventually make his product obsolete. Anytime there is a question about the quality of the original project P. Its a comment of how to make project P better.

    This happens, and we should use it for our advantage. I ask Mr. Hacker to be strong and try your best to ignore Mr. J. He will eventually fall out of existence, and you can become even greater.

  • I understand what you mean, but I somewhat think the "Darwin Awards" are in order here. Mr. J will eventually shoot himself in the head with his arrogant remarks. I can't see how people will support someone that attacks another in such a childish way. Thus, Mr. J will not have the benefits of open source. But Mr. Hacker, if he stays in the game will get the support. I'm assuming that everything is under GPL, so that if Mr. J does actually make some good code, then Mr Hacker can benefit, and vise versa.

    The evolution of Open Source is not really the more aggressive wins, but that the better/more stable product wins.

    KDE and Gnome isn't what I call a fork. They are two tools that do basically the same thing but with different methodologies. But they are not a fork, because they were not a single product at one time. They are two independent products, like parallel lines, no stem of the fork. But what Open Source leads to is that IMHO you will see KDE and GNOME merging to work together more than falling apart. So the flame wars between the two are irrelevant.

    If the two versions of P do fork, time will only merge them back to one.

  • > Open Source means I can see and modify the
    > source code. That's it.

    That makes sense to me. "Open" alone means that one can see the source, even if the software is restricted in use.

    > Free software - to me - means that it abides by
    > the GPL (or LGPL I think). This means that
    > anything under the BSD or Artistic or the
    > Netscape liceneces is Open Source, yet not
    > Free Software.

    Interesting. To me free means free from cost or
    other restrictions on use. In this respect public domain software is the most free, followed by BSD and maybe Mozilla. GPL'd stuff seems less free due to its restrictions on use in combination with software under other licenses (in order to force as much code as possible to be Open.)

    Optimal, of course, is software that is both Open and Free of both cost and restrictions.

    IMHO, of course.
  • > Open Source means I can see and modify the
    > source code. That's it.

    That makes sense to me. "Open" alone means that one can see the source, even if the software is restricted in use.

    > Free software - to me - means that it abides by
    > the GPL (or LGPL I think). This means that
    > anything under the BSD or Artistic or the
    > Netscape liceneces is Open Source, yet not
    > Free Software.

    Interesting. To me free means free from cost or other restrictions on use. In this respect public domain software is the most free, followed by BSD and maybe Mozilla. GPL'd stuff seems less free due to its restrictions on use in combination with software under other licenses (in order to force as much code as possible to be Open.)

    Optimal, of course, is software that is both Open and Free of both cost and restrictions.

    And Open and Free still doesn't prevent a developer from being flamed by some user or other developer. e.g. Free -> free speech also.

    IMHO, of course.
  • ...was to have picked up the phone and call Mr. J. My experience has taught me that talking to a real live human being tends to diffuse issues. When someone hears a voice, they connect on a different level - they know their words can hurt a real person.

  • a) It was GPL'd (version 2).
    b) The original owner practically begged for a while for someone to take it over, as his place of employment would not be using it much in the future.
    c) Few people stepped forward; but the most (IMHO) promising person (JQH) was assigned the code base.
    d) Problem: JQH's available time started to dimish; after what some believe was a great start. I was sorry to see this, but I don't blame JQH for this; we all only have 24 hrs/day
    e) J decided to take over the code without so much as a nod in JQH's direction. I have no doubt looking back at the events that if J had asked to co-author or even to take it over JQH would have said yes. But it didn't happen, J was publicly maligning JQH before he even started his work on it.
    d) J's work on the "code" has been good and at a good pace.
    e) I am glad to see J's work and use it, I think as far as the code goes he is doing a great job.

    Conclusion: It was handled poorly by J, JQH was only defending himself, it's over. I think the biggest loss of this whole affair has been the attitude toward open source projects that JQH and others must feel. I think a couple of guys need to sit down with some beer and make nice. I think we all need to appreciate what work/help/code we do get and not abuse it, as it only makes the next person that much more likely not to contribute. As for the name I (IMHO) don't think J had a right to use the name. But it would never have come to a split if it had been handled properly, they both wanted the same end and didn't even disagree as to how to get there. I guess the lesson to be learned is if you really want to contribute, do so. How many projects turn down worthwhile contributions that don't detract from the projects goal without so much as a reason; none (of any consequence) that I know of.
  • Have a look at

    http://www.psychosis.com/~dcinege/

    then View Source.
  • This sounds like a shame. It should go without saying that it would have been much better if they could've gotten along and found a way to either work together, or fork peacefully. But I've read a lot of naive posts in here insisting that there had to be a happy solution. I would think anyone whose worked as a professional programmer has run into just the sort of irrationally difficult, combative person described in the post. Although these people are frequently *very* talented, they can be impossible to work with, and they REFUSE to be ignored. I worked one company where the entire programming department actually quit over one miserable human being. (They started their own company) I worked in another where one such person had left and then wanted to come back, and all the programmers begged the CEO not to let him return. Sadly, such people exist, and there's plenty of them. No amount of programming skill excuses taking up a personal war against another programmer. JQH should have let Mr. J take the project over, because he had more time and resources to devote to it, as JQH seems to admit. But when JQH refused, Mr. J should have forked like a civilized person.
  • ...it seems like both parties in the story are very immature people. Rather than responding with pointed messages, the author of the letter could simply have done what he wished the other party to do--ignored him and gone quietly on with his business.

    Is it me, or are there a lot of people prone to whining in the OS community? It seems that almost every major controversy degrades into whining about the petty tactics of 'the other side', while the whiners are busy explaining why they are allowed to use those tactics, themselves.

    -awc
  • That makes it deservant of a moderation down? So if you just plain think I'm wrong, my opinion becomes flamebait? Sheesh.

    It seems that the one who posted the letter should have just ignored the guy (J?) who was being the jerk. Moral high ground, etc. Had he simply ignored the jerk and gone on with life, people would have stopped paying attention to J, and all would have resolved itself in the long run. Instead, he chose to send an imflammatory email that served no real purpose other than to provoke the other party. Then, he wrote his letter to whine.

    At least that's the way I saw it. You might see differently.

    -awc
  • You know, that's a pretty damned good point. Open Source/Free Software is a good deal more open than closed source/commercial software (given).

    It does make sense that all of the internal politics and other whatnot is going to much more public in public projects.

    We all know about the silliness that took place in the early days of Apple. For all we know, that sort of thing still happens (perhaps on a smaller scale), but we don't hear about it. When projects fizzle, or otherwise change direction (Mozilla), it becomes a big public stink. But, look at the dozens of cancelled projects that are quietly re-orged out of existance. Sticking with Apple, there is a laundry list: QuickDraw GX, PowerTalk, the Newton, AOCE all come to mind pretty readily.

    Hmm. Is the public nature of the debate--which can be quite hairy at times--a problem or an asset or just a fact of life?

    Again, great point.

    -awc
  • The open source model is a close relative of the scientific development model, with code treated as research, and published for peer review and for the benefit of mankind.

    And the problems are very similar. I've seen equivalent behaviour in the scientific community. Perhaps J was a little younger than many scientists - normally such disputes are played out in a manner more mature, although no less vicious.

    Don't worry about it. Its human nature. The best we can do is remember to laugh at ourselves.
  • A situation like this, as unpleasant as it is, will eventually work itself out when the "market", i.e. the community of users, decide which software they will use.

    One very important factor in that decision is the trust that you are able to place in the author, and that will be effective enough as a brake on miscreant behavior. I know if I read a mailing list full of rantings from the software maintainer, I will be concerned about his ability to responsibly maintain the project; particularly if it leads to something as wasteful as a code fork. If it's bad enough, it'll cost him users and kill the project.

    BTW, J.Q. Hacker's text gives me a strong sense of reading just one side of the story. I wonder how the so-called Mr. Jerk would tell it.
  • I'm appalled that the person who wanted to "take over" the development of "P" did what he did. Is there a way to protect ourselves from this sort of thing, perhaps by a copyright of the program name or even the contents, yet still allowing an individual to modify a program form the source code for his own use?

    I think that the anonymous writer was doing the right thing by not mentioning names and such. It keeps him or her from being lowered to the same level of the other person.

    If a person can't maintain the code for a program in a timely manner, wouldn't that mean that others who can['t wait for new versions would just have to either write their own or choose an alternative, if there were any available, to use.

    It might have been a good idea to try to find another responsible person to take over the code development, but that is not a decision all of us can make for him or her.

    I would not want the code to be maintaned by someone who likes to call others names, find fault, etc. This does not sound like a responsible, mentally sound individual. If this is the case, would it be safe to assume that the software would be free of code that might cause damage to the system or its files and programs? This is not to say that this _would_ happen, just something to think about.

    Donald Hellen
    >>>remove "dot spamproof" from each end of my address to reply"
  • "Homesteading the Noosphere" was what really made me understand why a JQHacker might run into this kind of situation. Prestige *is* important, no matter how much a hacker might say that the code speaks for itself.
  • Well, I hope that things will work out the way you suggest -- that nice guys will win out over not so nice ones in an open-source environment. But I think that the Darwinism example is probably not a good support for such an argument, since evolution in the wild usually favors the more aggressive opponent. To use a somewhat similar metaphor, "bad money drives out good."

    However, it may be that evolution isn't really a very good metaphor for the open-source development community, since it would imply that there are no social rules, and clearly there are lots of social rules in the open source community about what is acceptable and what is not that aren't just based on utility (which is all evolution cares about) but based on values.

    I actually think a more appropriate metaphor would be a small society with "normative values" -- things that everyone accepts as ok or not ok. Clearly, we have a case here where the normative values haven't been established.
  • Facts we can draw from the paper:
    1) The Maintainer is too busy with other work to 'maintain/expand' codebase.
    2) 'J' is very anxious about advancing code (and appears to need some dog training).
    3) A Maintainer's job is to maintain and expand codebase, generally leading from the
    front edge, not the trailing edge.
    4) By his own admissions, the Maintainer appears to be failing.

    Given these circumstances, what should have happened is Mr. J should have asked to
    add his code to v2, working with the Maintainer. Then after gaining some trust from
    the Maintainer and the users, ask to become the defacto maintainer for v2 (Maintainer
    should suggested it). It seems like too much personality gained a foothold in the
    codebase.

    Perhaps if the Maintainer and J would agree on each other's mailing lists to jettison
    the personal baggage, work together on v2.1 (merging v2.0 and v1.2j), the codebase could move smoothly forward again.

    Steven Howe
    Steven.Howe@ElSegundoCA.NCR.COM



  • I would hope, no, I am almost certain that what you are describing is what can only be tentitively explained by the fact that any large body of people will always have a small number of it's members that operate outside of the "spirit" that originally gathered that body together in the first place.

    I have no experience with this in the software authoring arena, but have witnessed it quite some time ago with the various movements that were popularized in the 1960's in Southern California.

    Please, do not allow these few to sway you in a negative way; they're opinions and behavior will eventually isolate them.

Forty two.

Working...