Slashdot Mirror
Feature: Conflicting Open Source Developers
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
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.
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...
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).
Hi,
... it sucks waiting for something that will never come).
:)
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!
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.
,hacker Perl another Just)'
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(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
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.
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.
How's my programming? Call 1-800-DEV-NULL
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.
Have you compiled your kernel today??
About my only contribution to open source software has been adding Solaris support to XMMS; 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, 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.
--
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.
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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
The Future of Human Evolution: Autonomy
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.
send all spam to theotherwhitemeat@ropine.com
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?
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
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.
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.
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.
Steven Rostedt
-- Nevermind
...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.
****
"I'd never want to join a club that would have me as a member" - G. Marx
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.