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.
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.
Goodbye, XFree86.
Karma: bad (mostly unaffected by funny mods)
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.
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 downside is that when a project forks, there is much less opportunity for the public (non slashdot readers) to ever catch onto a good thing. 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.
So, in turn forks make Microsoft happy.
Do we want to do this?
Way back in the day, the two headed monster on Sesame street would say "two heads are better than one." No matter how creative a developer may think she is, someone else can look at an idea, and may come up with an improvement or suggestion. Isn't that the whole point of open source? Nothing gets hidden behind copyright laws, or (hopefully) obfuscation of code. Even if the leader is a total dunderhead, sufficiently skilled people can take over and move the project in another direction, or back in the original direction.
;)
Now, if we could get our country going the same way
You have a constitutionally protected right to be wrong, and I the right to ignore you.
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).
This is preserving the right that if you go under, they can fork your project.
It's so funny to hear commercial companies arguing against forks, when they so commonly demand them.
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.
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!
-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.