Feature: Conflicting Open Source Developers 119
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 conflictswith 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
Unmask them, I say! (Score:1)
Pass the buck (Score:1)
An ex-OSS developer comments (Score:1)
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'.
Re:Curious as to what real event (if any) this was (Score:2)
You can find 2 homepages for it now, but do a search for 'portslave cistron radius'
and find it.
Re:because... (Score:1)
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.
Re:Why not work together? (Score:1)
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
Why not work together? (Score:4)
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...
Re:Free Software!!! [was: Re:OS Development issues (Score:1)
Re:/. Moderation gone awry (Score:1)
What are your reasons for thinking BOTH parties were acting childishly?
I'm going to face this soon myself (Score:1)
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!)
Re:Shut up and show them the code... (Score:1)
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.
Conflicts and the like (Score:1)
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
because... (Score:1)
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
Re:Same problem that comes with "freedom of speech (Score:2)
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).
Re:Why not work together? (Score:1)
Re:Gracefully handling toxic people ... (Score:1)
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.
Gracefully handling toxic people ... (Score:2)
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
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!
Freedom requires responsibility (Score:1)
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.
Re:/. Moderation gone awry (Score:1)
JQH made wrong initial move IMHO (Score:2)
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(\)-:
Unmask Anonymous Cowards (Score:1)
Happens a lot (Score:2)
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.
Re:Moderate the last post up... (Score:1)
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.
Shut up and show them the code... (Score:2)
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.
Common? yes. but it's not common. . . (Score:1)
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
Netetiquette for OSS projects? (Score:2)
"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.
Re:OS Development issues (Score:1)
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...
Re:qmail (Score:1)
--
A plea (Score:5)
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.
--
Curious as to what real event (if any) this was (Score:1)
How things work? [Was: Re:Why not work together? (Score:1)
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.
Re:Ironic but this is a great strength of Open Sou (Score:2)
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.
N leaders on M variations, for small N >= M, M > 0 (Score:1)
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--
Re:OS Development issues (Score:1)
Simon
Re:Shut up and show them the code... (Score:2)
Re:Not as sad as it seems (Score:2)
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.
Re:What's more... (Score:1)
Ironic but this is a great strength of Open Source (Score:3)
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.
the coin of ego-gratification... (Score:2)
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.
Re:Free Software!!! [was: Re:OS Development issues (Score:1)
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.
Re:A plea (Score:1)
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]
Moderate the last post up... (Score:1)
- 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...Shit happens (Score:1)
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.
Re:/. Moderation gone awry (Score:1)
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).
Management (Score:5)
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?
Re:Free Software!!! [was: Re:OS Development issues (Score:1)
-cpd
Re:Free Software!!! [was: Re:OS Development issues (Score:1)
-cpd
Isn't what the GPL says? (Score:1)
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.
What about Open Software Design? (Score:1)
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.
What do you think?
Answers the poster's question (Score:1)
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?
Re:Happens a lot (Score:1)
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.
It's just another "flavor". (Score:2)
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
Par for the course (Score:3)
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.
Re:Gracefully handling toxic people ... (Score:1)
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
Re:Why not work together? (Score:2)
Tim
Anybody rememver FvK and the IP stack? (Score:1)
-russ
Re:girls (Score:1)
nah... (Score:1)
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.
Re:What's more... (Score:1)
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.
Re:Unmask them, I say! (Score:2)
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.
Same problem that comes with "freedom of speech" (Score:1)
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.
How about "Darwin Awards" (Score:2)
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.
Re:Free Software!!! [was: Re:OS Development issues (Score:1)
> 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.
Re:Free Software!!! [was: Re:OS Development issues (Score:1)
> 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.
What you should have done.... (Score:2)
ABC = ? (Score: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.
Re:Moderate the last post up... (Score:1)
http://www.psychosis.com/~dcinege/
then View Source.
Sometimes (sadly) this *has* to happen. (Score:1)
What's more... (Score:1)
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
Re:/. Moderation gone awry (Score:1)
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
Re:What's more... (Score:1)
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
Just like science really... (Score:1)
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.
Let the "market" decide (Score:1)
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.
Conflicting Open Source Developers (Score:1)
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"
ESR's HtN (Score:1)
Re:Same problem that comes with "freedom of speech (Score:1)
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.
Conflicting Open Source Developers (Score:1)
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
"Bad Apple" in the basket..... (Score:1)
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.