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."
But it's unlike modern capitalism, where you use patents and copyrights to hold on to your "intellectual property". According to Bill Gates, we're all some kind of communists.
#!/usr/bin/english
So we can vote articles like this one:
Argument leads to better ideas.
Obvious -1
-- $G
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
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
Forking is generally a bad idea, however there are exceptions. Usually it dilutes development efforts and progress, leads to fragmentation, confusion of the common user, and possibly lower quality software. If OSS was just a bit more fragmented it would probably not have become mainstream. Lets stick together, focus our potentials, and produce concentrated masterpieces of software that are here to stay!
This article doesn't list my favorate (or really least favorate) reason for forks. Greed. The owner of the copyright for an open source project suddenly decide they aren't getting enough and goes nuts trying to make an open source copyright work like a standard copyright. Two examples are cdrecord and Sveasoft's Alchemy. Two great open source projects gone bad. I'd say more, but I don't need those guys going after me like they've attacked others.
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
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.