Slashdot Mirror
Flame Wars, Forks and Freedom
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."
Differing ideas compete, and the strong ones survive. Forks are just a different way of getting there.
This story is just STUPID!! That's it, I'm starting my own slashdot!
So Flamebait gets karma point now?
Rock that crushes, Paper & Scissors that don't matter.
...is here.
Nice history lesson on EGCS. I wondered how that got sorted out...
The Army reading list
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!
Preserved by Google:
Famous debate between Andy Tanenbaum and Linus Torvalds
What OS would I be running now if Linus had just given up and said, "You're right"?
Visit the Game Programming Wiki!
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.
Crazy.
Oh, wait, you meant "in the last ten years". My bad.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
Goodbye, XFree86.
Karma: bad (mostly unaffected by funny mods)
So they're saying we should drop an asteroid on the XFree86 developers?
So we can vote articles like this one:
Argument leads to better ideas.
Obvious -1
-- $G
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.
In the FOSS market, flamewars and forks generate different variations from a current path of development for software. These variations are then offered to the public and to computer-savy people. If they like it and there is interest in one variation over the others, then that variation wins in the FOSS market. More programmers will then sign on-board to develop winning the variation.
Thus, the FOSS market is a version of the commercial market.
I think that, in the FOSS market for people (like myself) with slow memory-limited computers, K-meleon has a good chance to dislodge Firefox. K-meleon is a fork from Firefox, and both are based on the same Gecko engine.
Forks also = shared devlopment time = apps that support one fork but not other = fragmentation = bad thing. This is one of the advantages and one of the problems of Open source vs. closed source. Consequently Windows has a benefit here. Say what you will but the windows development base is fairly unified and a concentration of efforts is easier; though admittedly less innovative than Linux granted forking produces new ideas. Not meant to be Linux bashing in favor of windows but this goes to show how windows isn't dying any time soon...
...in bed
When forks are brought about by personality conflicts and useless cruft, they're destined for failure... when they're brought about because something is impeding the progress of a motivated group of coders, they succeed.
That said, I think this article certainly was rather meaningless, and not really "News for Nerds. Stuff that matters."
500GB of disk, 5TB of transfer, $5.95/mo
The Emacs/XEmacs fork is given passing mention in the article, but is actually one of the more interesting ones. At the time XEmacs really did represent a step forward, mostly in its embrace of an X based GUI using modern toolkits. Consequently XEmacs tended to romp along and be the feature leader. Most recently, however, the situation has reversed. It is now XEmacs that is unwilling to use modern toolkits, and GNU Emacs is starting to push back.
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.
Craft Beer Programming T-shirts
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
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
This article is awful. Surely every slashdot reader knows about all the events in TFA, and the author doesn't make any new points.
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.
#define struct union
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).
fork = genetic diversity
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Imagine the effect that it would have if Firefox forked, its current maintainers left the project b/c all the devs went to the forked project. You would have a bunch of people still using Firefox that would never switch to the new one (hell it took them long enough to trust something without the little "e" already). Firefox would go to shit because no one would maintain it. The fork would grow in popularity among the educated. Once Firefox broke the people that switched would slowly migrate back to IE.
You would think that that's how it would happen, but that's the point - forks often don't pan out like you would expect. ECGS forked from GCC and eventually the GCC people accepted ECGS as the new GCC. XEmacs forked from Emacs, but Emacs development continued, and these days it is Emacs that has the more vibrant and creative dev team (AFAIAC - I used to be an XEmacs fan, but comparatively it has stagnated). Often enough things haven't gone as expected and people sticking with the "original line" get the benefits (eventually), whether it be from the fork being folded back in (GCC) or from the spurred competition arising from the fork (Emacs). Don't expect to be able to predict what will happen when a fork occurs. It's a lot more complicated than you might imagine.
Jedidiah.
Craft Beer Programming T-shirts
One of the more interesting questions in economics is why decentralized forms of economic management like cooperatives or the old Syndicalist ideas never become widespread.
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
Even in debian/unstable, we're still stuck without x.org - doesn't make a lot of sense to me as many other packages are generally up-to-the-day updated (most that I use seem to be within the week).
...
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!
Flame Wars
More often than not flame wars are precursor to forks
Right. That's why emacs forked from vi. I see that now.
In Soviet Russia, articles before post read *you*!
-I think that the author has been using too much PowerPoint
-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.
is it any suprise that software developement is starting to closely mimic nature? that parallel development leads to specializiation and survivalism? Weaker products either find a survival niche (something that they are really good at, akin to giraffes) or become overall a stronger competitor than everything else, not neccessarily the strongest, fastest, or anything but the most flexible (Linux is, Windows trys, kind of like the early stages of human development). Remember, there were two branches of development in our evolution too. Homo-Erectus killed off it's competitors, by being more aggressive (effective). So... do you think that Windows-E-Rectus will manage to kill off Linux-Superiorus?? Really though this shouldn't be any huge suprise to anyone, as software is a direct descendant of our own creativity, so it will mimic those patterns in life as we understand them. It is hard-coded into our BIOS you might say. Anyone watch the movie Pi?
Everybody is repeating the same nugget of obvious information that the article was based on. A piece of information that everybody here knows. This is a nothing conversation about the painfully obvious that's not going anywhere fast.
Although the article lightly touches on OpenBSD in reference, I'm surprised an article that concentrates so much on flame wars and distribution forkings would omit talking about the origins of OpenBSD altogether. Though the details are sketchy to me after all these years, I remember distinctly Theo was a core NetBSD developer who's vitriolic and (at least I thought) humorous flames against people in the USENET community caused him to be ejected as a core developer, it was at least one major step that turned him into the direction of OpenBSD--that and the fact that he was prevelent at finding security holes in code that nobody had before him.
Though his fellow developers in the other BSD camps may (or may not) have liked him personally, you can be damned well sure they previewed his source control check-ins to see what he was patching.
It's true no man is an island, but if you take a bunch of dead guys and tie 'em together, they make a good raft.