Flame Wars, Forks and Freedom 211
Eugenia Loli-Queru writes "In the news media, it is generally shown that flame wars and forks are detrimental to the growth of FOSS (Free/Open Source Software) But if we see the history of FOSS, both flame wars and forks have played a crucial role in determining both growth and direction of important projects. There are also arguments that this leads to fragmentation and marginalization. There is some truth in these arguments but there are a lot of benefits which are often overlooked. This article looks at some of the benefits of forking and flame wars through history."
It's like capitalism (Score:3, Insightful)
Re:It's like capitalism (Score:3, Interesting)
Re:It's like capitalism (Score:2)
In the current run-amok situation, with patents and copyrights is probably producing something much closer to a centraly-organized communist system than anything that the FOSS community can generate. (i.e. only members of the central elite will be allowed to
Re:It's like capitalism (Score:2)
Yes and no. There are fewer external factors in most FOSS projects that will kill it (like making money) - basically, as long as the developers are having a good time, projects continue to exist. It also means ego is more of a component, relatively, since profit doesn't play. As such, it's much more likely that a viable product will fork over personal difference, which in the corporate world is rare.
T
Re:It's like capitalism (Score:2)
If you don't add any significant functionality - or even remake a less functional more buggy program than those available - I call it reinventing. A successful fork, perhaps, would deserve the term "refinement."
Noone makes a similar product without giving it a couple of extra features. Exept when there is a marketing departement to back up the shoddy product of course.
Then you're not familiar with many FOSS projects. First, a couple of e
Re:It's like capitalism (Score:2)
You expect us to believe that critical peer review produces good solutions?! Come on!
Re:It's like capitalism (Score:3, Insightful)
Compare this to the OpenBSD/NetBSD/FreeBSD fork. Each of the forks has a very different design goal: OpenBSD concentrates on security, NetBSD goes for maximum cross-p
Re:It's like capitalism (Score:3, Informative)
Re:It's like capitalism (Score:2)
bah (Score:5, Funny)
Re:bah (Score:2)
Re:bah (Score:5, Funny)
Re:bah (Score:2, Funny)
i pwn u.
Re:bah (Score:3, Funny)
Re:bah (Score:2)
Re:bah (Score:2)
Let's host it (Score:2)
Theo
Theo
Theo
THEO
!!!
Flamebait +1 (Score:2, Funny)
Yes. (Score:2)
All-in-one-page version.... (Score:3, Informative)
Nice history lesson on EGCS. I wondered how that got sorted out...
try this =) (Score:4, Informative)
Forks spur competition. It is a bit like evolution. In nature, a new species survives if the differentiation from the dominant group gives it an advantage for survival in a hostile world. That is why the dinosaurs died out and the mammals survived. Being big and powerful is not as important as being able to adapt to changing conditions. Most of the time open source software succeeds, it is because the end users are included in the process of building the software and making decisions. It is inevitable then at some point there will be a divergence of views and a decision has to be made. Sometimes it is not possible to make the right decision as one does not have all the information and/or one's past experiences have led to a certain opinion (which may not be necessarily right according to others). This is fertile ground for a flame war and a fork.
Usually, it is possible that the fork will survive if it solves a pressing need which was overlooked or addressed insufficiently by the core group. Also in open source, after forks if one group is innovating more than the other and taking the right decisions, it will also attract the userbase over a period of time. The source code being freely available means one group can borrow ideas from another. So the best ideas get replicated across the forks. Often it is also seen that a particular developer is part of one or more projects (forks). As many forks want to retain their own identity, there is more innovation for differentiation from the other forks. Innovation is also due to the demands of a specialized userbase (example - cryptographic implementations in OpenBSD and implementation of ssh - OpenSSH). Now this leads to a positive feedback cycle - all the good stuff gets picked up by everyone and everyone is free to experiment more. An example in case are BSD variants - FreeBSD, NetBSD and OpenBSD. FreeBSD and NetBSD use OpenSSH that has been developed by the OpenBSD team. The NetBSD Packages collection pkgsrc has been ported to both FreeBSD and OpenBSD. Forks also bring to notice some pressing need of the community when the lead programmers/core team ignore them. Even Richard Stallman agreed to pursue the egcs fork of gcc as the main branch for further development. Forks can sometimes be "healed" and the codebases merged. The GCC/EGCS example above is a case in point. Forks provide an opportunity for them to serve a specialised purpose while being able to incorporate changes from the new branch.
It is possible that forks may hurt large corporations which like to be able to control the direction of the product. This is the reason Sun will not release Solaris 10 and Java under a OSS license. If at all they release the source it will have some kind on a non-forking clause. Forks are always beneficial to the end user in the long run, though they might cause a bit of pain initially. Imposed control rather than concensus is central to the way big corporations operate but not the way a good team of hackers operate. This is due to the cathedral and bazaar model of development as described by Eric S Raymond.
Flame Wars
More often than not flame wars are precursor to forks - an indication that all is not well within the project. Flame wars can also happen if a radical new design or a drastic change to the project such as a license change or replacing a subsystem with a better one. Flaring opinions and bruised egos can damage the project but also enhance the project by hammering out new ideas in a public discussion (because the discussion is public also means the stakes are high). Bureaucracy and forced conformism is detrimental to the growth of a project. But this is the way order has been established in traditional companies. Flame wars and discussions are central to the development of OSS to explore different design issues, but they also harbor the potential to destroy the camaraderie in a project. It is important that they be taken in the right spirit or the whole project suffers. The reason why flame wars have go
Re:All-in-one-page version.... (Score:2)
Not quite: Maintainers can check in their own patches (within the code they maintain) without waiting for approval. Other patches only need to be approved by a single maintainer.
Well, wait a minute... (Score:5, Funny)
Well, WHOSE SIDE ARE YOU ON, bud? Huh?
You can't post a juicy title like "Flame Wars, Forks and Freedom" without taking a side.
What are you, some kind of GNU/Commie? ESR-Capitalist? Microsoft Nazi? (Or a paid OS X shill?)
And if you're just trying to present both sides of the argument in a fair and balanced fashion (sorry, I know a friend who worked at FOX, but since his facts are licensed FreeBSD-style, it's OK if I use them on Slashdot), then what are you doing whining about it on Slashdot? For chrissakes, man, just do a CVS branch and start coding your own facts, dammit!
Re:Well, wait a minute... (Score:2)
The Meow Empire is gonna be pissed you left them off the list.
Re:Well, wait a minute... (Score:2)
p
Re:Well, wait a minute... (Score:2)
How can you forget the Gentoo zealots ?!
Like the "Linux is Obsolete" flame war of 1992? (Score:5, Insightful)
Famous debate between Andy Tanenbaum and Linus Torvalds [google.com]
What OS would I be running now if Linus had just given up and said, "You're right"?
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:3, Insightful)
I think the real reason it's famous is that it's a professor criticizing a student, and the student ultimately was proven right to an extent. A lot of geeks feel this way about their teachers (often rightly so).
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
A good one (for my values of good =)
Re:Which? (Score:2)
they all suffer from design flaws, such as root/administrator
filesystems tied to the hardware
non-abstraction of simple things
didn't go with "everything is a file"
they all base their existence on one Computer / one OS thinking rather than being network centric
I'm sure you can think of other things
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
Has this impacted the success of Linux? If you go into a business meeting, interview, etc., and communicate in the way that I see on that thread, you won't go far. Good geeks don't always make good businesspeople.
Just an observ
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
Andy's Current Take (Score:5, Informative)
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
A choice quote, referring to the 80386: "I think it is a gross error to design an OS for any specific architecture, since that is not going to be around all that long."
True in theory, but practice has a nasty habit of wrecking theories. That said, his concerns about portability turned out
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
That's because, in my feeble understanding of the Linux architecture, it wasn't actually designed for the 80386. The 80386 has a pretty unique paged-segmentation architecture, which means that addresses are organized first by arbitrary-size (up to 32-bit) segments which t
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
BSD (Score:2)
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:3, Insightful)
Don't get me wrong, I like linux, and I sure as hell couldn't write it myself - yet, anyway. But the more I look at it, the more it looks like the amature kludge it originally was. And although I admire how well he's led it, some of Linus' design decisions have been decidedly odd, and, well, wrong. It works - but I can't help feeling it would work better if a bit more experience had gone into the overall design.
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
Re:Like the "Linux is Obsolete" flame war of 1992? (Score:2)
I am looking at NetBSD right now.
I am a former FreeBSD user and agree with what you are saying. Linux use to be trim and stable during the 2.0 days. But now, I find the userland programs less tested and more buggy than the BSD vers
More goodness (Score:2)
It has things like Linus' first post about Linux, some funny Microsoft posts, the first known Usenet spam, etc.
Re:More goodness (Score:2)
Say what now? (Score:4, Insightful)
In the news media, it is generally shown that flame wars and forks are detrimental to the growth of FOSS (Free/Open Source Software)
No, it's claimed that flame wars and forks are detrimental. To show that something is detrimental would involve coming up with a bit of evidence.
Re:Say what now? (Score:3, Insightful)
Volunteer coding time is a strange commodity - you can't just shift it around like man-hours in commercial software. If a volunteer is doing something they don't enjoy, their productivity will drop to zero rapidly.
Re:Say what now? (Score:2)
Note that I'm not arguing that it doe
Flame Wars through history (Score:5, Funny)
Crazy.
Oh, wait, you meant "in the last ten years". My bad.
Re:Flame Wars through history (Score:2)
I think I speak for all of us when I say... (Score:5, Insightful)
Re:I think I speak for all of us when I say... (Score:2, Funny)
No kidding! (Score:5, Insightful)
But still, we're stuck with Xfree4.3
I use to have an unofficial deb site which offered x.org, but that one died sometime ago as well... so I've been without x.org updates for awhile. I suppose one could use alien to debianize a bunch of RPM's but what a royal pain in the butt.
Come on debian package admins, the people want X.org!
Re:No kidding! (Score:2, Informative)
deb http://archive.ubuntu.com/ubuntu/ hoary main
iirc thats the repository
to stay on topic for a while , Forks ussualy cause problems but in this bussiness Egos are going to emerge . Creative people have Egos and Egos can destroy projects , a good project leader knows how to stroke the conflicting egos properly to keep us all in line
Re:No kidding! (Score:2)
Analogy Police (Score:5, Funny)
So they're saying we should drop an asteroid on the XFree86 developers?
Re:Analogy Police (Score:2)
So they're saying we should drop an asteroid on the XFree86 developers?
Heh. The analogy gets even worse when you consider that at least 6 dinosaur species survived, and they've expanded to about 8000 species now, about twice the number of mammal species. Of course, the dinosaur survivors were the critters we now call "birds", and they were the small, opportunistic "generalist" kind that you'd expect, as were the surviving mammals.
So if yo
We need a way to score articles (Score:5, Interesting)
Argument leads to better ideas.
Obvious -1
Re:We need a way to score articles (Score:2, Informative)
Re:We need a way to score articles (Score:2)
Forks == the power of Open Source (Score:4, Insightful)
With proprietary software, even if your vendor is successful (Peoplesoft) you're likely to be trapped in a sucky end-of-life situation.
If your vendor isn't successful, the software just vanishes.
Forks protect against both of these.
from the article... (Score:2)
Heh, what about Theo's fork from NetBSD to create OpenBSD?
Re:from the article... (Score:2)
Flamewars&Forks=FOSS Version of Commercial Mar (Score:2, Interesting)
In the FOSS market, flamewars and forks generate different variations from a current path of devel
Forks = new ideas = good thing (Score:3, Interesting)
Re:Forks = new ideas = good thing (Score:2)
Motivation is key to successful forking (Score:4, Insightful)
That said, I think this article certainly was rather meaningless, and not really "News for Nerds. Stuff that matters."
The XEmacs/GNU Emacs fork (Score:5, Interesting)
Let's be frank, these days when we say "modern GUI toolkit" for X we mean wither GTK or QT. XEmacs does have GTK support, but the developers are not interested in it, and mostly it is just slow, and bug ridden, even in CVS. Compare that to Emacs, which has finally decided that GTK might not be such a bad idea. The current CVS versions of Emacs have excellent GTK support, making full use of the latest versions of GTK. It looks and behaves very nicely indeed, and integrates quite well into a GNOME desktop. The new GNU Emacs will also sport excellent Unicode support. It will be interesting to see how the GNU Emacs/XEmacs debate stands once XEmacs 22 and Emacs 22 come out. I expect to see GNU Emacs get a real boost in popularity.
Jedidiah.
Re:The XEmacs/GNU Emacs fork (Score:2)
GNU Emacs would have represented an even bigger step forward had the XEmacs developers not gone it alone. The Emacs developers had come up with an elegant design for Emacs that would work on both X and a TTY terminal. The commercial company that was pushing for X support decided that this ambitious project was going to take too long and went
Mule (Score:2)
Re:The XEmacs/GNU Emacs fork (Score:2)
Emacs *should* make gtk integration a priority, since gtk is the toolkit of Gnome, which is the official GNU desktop. It is embarrasing that the flagship GNU application (Eamcs) does not integrate smoothly into the GNU desktop.
Today both XEmacs has Emacs have big problems with their release process, the last feature release of GNU Emacs is three year old, and the XEmacs situation is confusing. Lots of cool stuff is in CVS in both projects, getting nowhere.
Re:The XEmacs/GNU Emacs fork (Score:2)
i don't think the word "debate" applies these days, but anyway...
xemacs folks basically said "we don't like lawyers; we don't need to talk to them" whereas (that most hoary programmer ;-) rms knew to stop w/ the first
clause and furthermore acted to overcome his dislike to secure top-flight
legal advice. the result is a situation that is fundamentally (at the
foundation at the base, upon which all other problems and/or solutions must
rest) irreconcilable.
in a world where the big nasties are just wai
Re:The XEmacs/GNU Emacs fork (Score:2)
I just would like xemacs to support gnome-session. I don't want to have to use vector fonts in xemacs. I like my bitmaped -misc-fixed-*-*-semicondensed-*-*-120-*-*-c-*-iso 8 859-15. It's the perfect size to allow three 80 col windows to be placed side by side in 1600x1200 resolution. All my vector fonts seem
Re:The XEmacs/GNU Emacs fork (Score:2)
emacs.font: -misc-fixed-*-*-semicondensed-*-*-120-*-*-c-*-iso
Re:The XEmacs/GNU Emacs fork (Score:2)
Re:The XEmacs/GNU Emacs fork (Score:2)
The cl package (with some Common Lisp extensions)works for both, but is pre-loaded in XEmacs. There is also a CLO
Article right, AC wrong (Score:2)
Lucid *did* sign all the necessary paperworks, later contributers to the fork, in particular Sun, didn't. This loack of paperwork is a contributing factor that the two branches haven't been merged.
Fork (Score:2, Funny)
All the slashdot editors are big dummies!!
I'm gonna start my own slashdot!
Futurama quotation (Score:2)
[No reaction.]
Bender: Eh, screw the whole thing.
[Bender turns and walks away.]
Huh. (Score:3, Informative)
Of course, ability to fork is a vital part of software freedom, but in a world of scarce developer time, it is vital not to let politics and personalities interfere with development of the best software.
Re:Huh. (Score:2)
My time may be scarce, but I am the one who gets to choose where it is spent. If you don't like it, for enough of your cash I might be persuaded to change my mind. But until I see the contents of your wallet I'm coding on what *I* want to code.
Frankly, I'm getting tired of whiny users arguing that politic
Re:Huh. (Score:2)
Brandybuck, I salute you for your contribution to open source and home brewing
The point is was trying to make was more like, if you want to contribute to an open-source project, you shouldn't have to fork it because the current maintainers are dicks.
Forks are like branch prediction. (Score:3, Insightful)
Some designs guess which way the branch will go, and continue accordingly. When the branch condition becomes known, and it guessed wrong, it throws away all the work on that branch and starts over causing a pipeline stall. Often, extra bits are available in the branch instruction to provide hints on which branch decision is more likely. The processor may even keep stats on hot branches in a branch prediction cache.
Other designs work on both forks of a branch simultaneously. When the branch condition becomes known, the execution tree is pruned. A fork in an open source project effectively pursues both branches simultaneously. One difference is that while often one branch is discarded (e.g. what will probably happen with the XFree86 fork), but sometimes both become viable options (e.g. Gnome and KDE).
OSS vs Human analogy (Score:3, Insightful)
flame war = territorial battles
The point is that both of these are needed in a progressive system. For a proper society to move forward, people's feelings need to get hurt here and there. People need to be able to go off and explore new ideas on their own, and I think thats the whole point of OSS, as opposed to a company which classically has very strict production goals.
Re:OSS vs Human analogy (Score:2)
That's the clicncher to your biological comparison.
Re:OSS vs Human analogy (Score:2)
I'm involved in one of several branches of a program (which one isn't material here) that happened simply because different groups of users needed different features added. Most groups didn't see any need for the others' extensions, so we couldn't get everyone working on a single branch.
FOSS, Co-ops and Syndicalism (Score:3, Insightful)
It would seem at first that an employee owned and managed business would easily out compete more proprietary ones. For example, employee owned businesses don't have to fire people when times get thin. Everybody just takes a pay cut and keeps working. The co-op can maintain the same output as before at a lower price.
Yet employee owned firms are very rare despite numerous attempts to create them over many years and in many different legal and economic environments. Studies have shown that such forms of organization fail due to phenomenon which we would call flamewars and forking. In short, politics either paralyzes the firm or causes factions to leave.
FOSS succeeds to the degree it does largely due the non-zero sum nature of its products. Forking causes only a dilution of developer time not the division of physical assets. Even so, excessive forking kills products. FOSS can stave off, but not eliminate, the inherent threats poised by decentralized management.
There is some tip point where creative give-and-take gives way to flamewars and where forking leads not to greater diversity and innovation but to a fatal dilution of effort and brand.
Might be a PH.d thesis in that for somebody
To paraphrase Thomas Jefferson (Score:2)
Flame Wars (from the article) (Score:2, Funny)
More often than not flame wars are precursor to forks
Right. That's why emacs forked from vi. I see that now.
Re:Flame Wars (from the article) (Score:2)
Re:Flame Wars (from the article) (Score:2)
Funny thing is, I don't remember ever reading about the reasons for all these clones. In my experience, they all seem to be quite usable, though sometimes I'm surprised by their small differences. Most often, I'm just disappointed by a vi that can't undo more than one change.
(And the main reason for wanting that is that one of our cute little cockatiels just ran across the keyboard. Oh, the perils of working from home
History (Score:2)
Flaming or real disputes? (Score:2)
The jargon file defines flaming as, "To post an email message intended to insult and provoke." The high profile disputes the article discusses don't really have that the element of pettiness and spite that is the hallmark of fine flaming.
Methinks someone used too much Powerpoint (Score:3, Insightful)
-There are alot of good examples presented
-However, the tendency to make everything a bulletpoint, a la Powerpoint, can be overwhelming
-Case in point, Page 1
-Are you still reading this?
-This bullet is important, but I chose to put it down here because it doesn't seem "sexy" enough.
-At least he didn't choose an obnoxious background
-CONCLUSION: the author been using too much PowerPoint.
evolution (Score:2, Insightful)
Fork Manners (Score:2)
WOW! (Score:3, Insightful)
Theo De Raadt, the birth of OpenBSD (Score:2, Interesting)
OT: Dinosaurs and Mammals (Score:2)
1) The dinosaurs dominated the large animal niches for far longer than mammals have. It is a few hundred million years too early to start gloating.
2) The dinosaurs did survive - I can see their ancestors swimming around in the duckpond outside my window.
Re:Forks can be bad . . . (Score:3, Interesting)
You
Re:Forks can be bad . . . (Score:2)
Mozilla was just too slow and memory intensive to become popular. Firefox changed that for the non techie users.
Re:Screw This (Score:2)
Not even close. Fark is "weird/funny news, photo manipulation contests, political flamewars, and maybe pictures of women without their clothes." Slashdot is "Free software, tech-geek news." Both sites are worthwhile, but Fark's appeal is broader and the average Fark user may be stupider than the average Slashdot user. I need a larger statistical sample of both sites to draw real conclusions, though. Or the lack of +/- mode