Post a Comment
Excellent essay; easily one of the best on osnews in some time. Very interesting points brought up here, and very valid ones.
I don't condemn forks that lead to fragmentation. Actually, inspiring myself in one of the evolution's theories (Darwin's one) I got to realize how important these are to select who are the best evolving the product, according to users needs. Take, for instance, the XFree86 project and the fork that lead to X.org. Now, the one that will survive (considering no one more will come) is, most probably, the best.
No doubt, especially considering Tanenbaum has an OS that is only useful for educational purposes to show for his efforts and teaches at the University of Whosawhatyamacallit. If he was at M.I.T. or Berkeley, he might have some ground to stand on while he's talking down at people.
From what i read Linus hadn't relaized that linux had grown bigger then himself and that in order for it to be sucessful he would have to ease up on the reigns or lose it all.
You guys are dissing Tanenbaum but you have no idea what you're talking about.
Without Tanenbaum, Linux probably wouldn't even have existed in the first place. Secondly, the University he worked/works for happened to be my univerisity as well-- It's the Free University Of Amsterdam. Amsterdam has been around waahaay before any brick was put on its side in the US, so show a bit more respect please. Afaik, Linus never worked at a University at all so I don't know why you are bringing it up.
Anyhow, the discussion between Andy and Linus is quite interesting; I read it from A to Z for my article on QNX, and I must say it was a learning experience. I, myself, am a strong supporter of muK(-based) designs-- No wonder my fav. OS's are all either true muK (QNX) or muK based (BeOS/OSX).
Oh and lastly, if you would've actually read the whole Andy-Linus thing, you would've noticed that Linus himself also makes gruesome errors in judgement. Find in that discusion what he thinks about the future of the Intel platform...
Now, kids, please don't comment on matters you know nothing about.
I like both emacs and xemacs, (fork)
have respect for both the creator of
minux and linux, (flameware)
yet I never looked deep into the way
of thought that you pointed out,
one of the best reads!!!
#3 Linus produced an OS that not only has a variety of uses and is available to the whole world for free, but which even Microsoft has said they consider a threat.
Linux did produce a kernel, not an OS.
...and teaches at the University of Whosawhatyamacallit. If he was at M.I.T. or Berkeley, he might have some ground to stand on...
whoa, now that's a retarded statement. learn some geography, then some history, and a little respect, ok?
@thom holwerda:
linus actually did work at a university, back in finland, in helsinki. he did that around 1994-97, then moved to california to work for transmeta.
christian
This quote from the article concerning the Linux kernel doesn't sound like an endorsement of forking- "Fortunately, the differences were sorted out amicably when the threat of a fork was looming large."
It's the Free University Of Amsterdam.
Minor nitpick here Thom but its the Vrije Universiteit of Amsterdam (aka VU) whereas 'vrije universiteit' is Dutch for 'free university'. Its a name.
Tanenbaum did an interesting analysis on the 2004 presidential election btw. Available at http://www.electoral-vote.com
Vaporwear apparently has reasons to believe Tanenbaum runs a bad class or something. Where's your proof 'Vaporwear', other than you allege MIT or Berkeley having a 'better name' than VU? Stallman worked at IBM and MIT (on AI related projects). You must admire him as well, huh? *g*
As for microkernel versus monolithic kernel... here we go again! At least Hurd are slowly switching to L4
.
#3 Linus produced an OS
Ohhh... you're the reason RMS whines about GNU/Linux
Torvalds started developing Linux, a kernel. He got help from thousands of other developers hence he didn't do the kernel development alone. However, as noted before, he started it.
Stallman -also with help from others- basically developed 'the basis for Linux' which is aka GNU but, was missing a kernel. Stallman had compilers (fortran, c, c++, asm, etcetera), a text editor, a shell, and many other utilities ready but they were still busy with a microkernel called HURD. However, history turned out it wasn't finished yet whereas Linux was -- and Linux took off. GNU, without HURD but with the Linux kernel, was used in the first Linux distributions such as e.g. Slackware.
Linus Torvalds never 'produced an OS' and Richard Stallman never developed 'Linux distributions' -- which are what we nowadays use as OS when we refer to "I run Linux". What both arguably made is valuable contributions to Linux distributions as we know it -- not only code-wise. Nowadays neither of the 2 icons 'produce an OS'. They're both trying to contribute to the F/OSS community though. Stallman with maintaining Emacs and advocacy; Torvalds with maintaining Linux 2.6 vanilla tree and developing for it.
PS: If you're in the 'microkernel is slow' camp try something else than MACH. 
A couple of points - Linus, whilst disagreeing with Andy, and the way he thinks that a kernel should be developed/operate, has a LOT of respect for Andy. And that respect is vice versa as well. Secondly, Andy has been a very very very well respected voice in kernel design for many years, and has taught many classes on the subject. So, vapourware, a bit of respect please. Thirdly, the US isn't the only country in the world that has universities, or has really good universities, as others have pointed out there are European universities that pre date colonisation of the North America continent by Europeans.
Microkernel vs monolithic kernel - each to their own. Andy favours micros, Linus favours mono. Both have negatives and positives, but the important thing is that they both work, and can work very well. There are many ways to skin a cat.
Forking - it's a solid form of evolution. Look at sendmail. x.org is doing it now, and doing it very well, we're getting real improvements to X. The beauty of open source is that the src code is open, so anyone can fork a project if they have the technical know how and desire. If it's a job well done they'll be successful. Closed src does not allow this forking. It's so heavily controlled and rigid it isn't funny - and that is not the way that nature works.
Dave
Great comment Dave!
One of the most informative articles in a while. Given the poor writing often found in this site, your article really is a refreshing read.
It is clear that forks or the possibility of one are part of the democratic decision making process that is inherent to open source development. While the discussions can be tense and frivolous forks are not to be welcomed, good forks often do more good than harm.
Let's not forget the ultimate reason to fork: your vision for the software is different to the current developers. I'm interested in starting a fork of an open source project. Planeshift (www.planeshift.it) is an open source MMORPG engine that is currently being deployed with proprietary art. The result? Only the Planeshift team can run a Planeshift server. Improvement of the Planeshift "world" is also strictly controlled. My vision for Planeshift is a world where trusted users are free to add new objects and extend the world easily. Of course, there's also the little issue of Planeshift requiring all contributors to assign their copyright to the Planeshift legal entity -- something very few open source projects require and most open source developers find distasteful. I wrote a rant about that: http://rtfm.insomnia.org/~qg/planeshift.html
I and some others are slowly gathering a free art package. If you're interested in contributing, please drop me an email.
Forks happen frequently in major projects. The Linux kernel currently has 3 major forks - 2.6, 2.4 and 2.2. Apache httpd has 1.3, 2.0 and arguably 2.1. MySQL has 4.0, 4.1 and the upcoming 5.0. Php is maintaining both 5.0 and 4.3. Etc. These forks are maintained separately for the very good reason that the current userbase need stability.
At the same time developers need the space to temporarily de-stabilise the codebase, leaving a local maximum of stability vs functionality with the expectation that they will deliver better functionality (or better design that will allow them to later provide better functionality) and eventually reach the same level or better of stability.
Hostile forks are usually similar but with a flamewar accompanying the decision to fork.
THIS is the kind of article I read OSNews.com for! Excellent!
> Nobody will ever show you respect with comments like that. Don't even try to compare
> your little school...
why don't you get even more arrogant?
This is a well written article. Good job Vinayak Hegde.
However flamewars are not only a precurser to forks, depending on the way the forking happened, they can be a common occurance afterwards.
The particular OSS project I work on (aMule) seemed to fork without flamewars beforehand, instead only a simple disagrement between the lead developer and a new developer, however the relationship between the two projects quickly became rather sour. There is still pie-throwing from both sides even now around a year after the fork was made.
It is however interesting to note that even though there wern't any flamewars before the fork happened, the relations within the project were definetly bad, as the fork resulted in almost every single developer from the old project migrating to the new project, with the exception of the lead-developer.
Let's not forget the ultimate reason to fork: your vision for the software is different to the current developers.
That might be the ultimate reason, but ego clashes and refusal to compromise are right up there near the top of the list.
***
Nice of some folks to completely overlook places like India and Japan when they start discussing computing R&D.
What has more impact on your life? *nix or Tron?
Hint: It ain't *nix.
Using evolutionary analogies may seem helpful, but are actually limited. Open source projects don't reproduce, nor do they have genes - the projects are run by humans not genetic code.
Sometimes it seems that competition helps projects such as having a few different window managers to choose from (KDE, Gnome, XFCE), but sometimes cooperation is much more helpful: using the same X11 system, standardizing Openoffice.org and KOffice on the same file specification, or using a standardized x86 architecture (Intel, AMD). Sometimes forking is helpful if the original project leaders are incompetent, but it isn't always helpful that the fork stays forked as we saw that the gcc fork was absorbed again.
I think the real lesson here is that having FOSS licensing makes both forking and cooperation much easier.
re: universities... pen-is mightier
re: the article. Solid stuff. The other posters were right, this is a good read.
"Nice of some folks to completely overlook places like India and Japan when they start discussing computing R&D. "
Funny how that is. I call it cultural myopia.
rember that both genetic code and computer code in the end are just strings of signals (zeros and ones in the case of computer code). all the sicence are where they are today tanks to people putting to paper their theorys and formulas, without being protected by copyrights and patents that stay in effect long after they themselfs are gone. its a share and share alike enviroment. but allso a enviroment where people compete for the glory of being the first person to figure something out. while glory dont put food on your table, it will most likely land you a nice job somewhere as people know what your capable of
yes standards are important, but forks help with transfering new blood into what at the moment is a evolutional dead end. if the old branch still have life it most likely will be absorbed. if not it will die of and the younger branch will continue to grow. this is why people keep compareing it to biology. standards create a enviroment for this to happen, a enviroment of common ground. what would happen if say the sheep held a tradesecret on the concept of eating grass? or maybe a copyright or patent?
If the reason for Sun not making Java and Solaris open source is, it can lead to forking, can QT be forked and what are consequences for Trolltech?
The Linux kernel currently has 3 major forks - 2.6, 2.4 and 2.2.
I would not consider these forks Linus and friends moved on other took up maintaining older kernels. The logical upgrade path is 2.4 -> 2.6 in comparison of a true fork you would not upgrade from FreeBSD -> NetBSD (although some might consider it an upgrade =P )
What has more impact on your life? *nix or Tron?
Hint: It ain't *nix.
Its not so simple. You compare a mass implemented, embedded architecture with *NIX; that's apples with oranges. Besides what does that have to do with the subject?




