Slashdot Mirror
Virtual Decentralized Networks: Linux's Organization
barries writes: "Here is an interesting take on the Linux Project which tries to put it in a historical perspective and explain why traditional structures and theory don't fully apply to it. It overlooks a few things but gets most of the basics right." You might want to skip ahead a bit in the paper to get to the Linux-specific sections.
Do people honestly think big egos are limited to MS?
Go to any company where a portion of the employees became very wealthy from stock options and you can watch the snobbery ensue.
There is nothing in this paper to convince me that such a model would work for a capitalist enterprise. The comparison between the Linux Project and Microsoft is absurd, as the first is a volunteer-based non profit project, while the second is a company. Models that work for a class of projects don't necessarily work for others.
Moreover, statements like:
If the automobile industry started taking on an open source development model with sharing across companies and countries, the cost and prices would eventually drop, innovation and development would speed up and exceptional features would be shared across many makers and models. The auto industry could finally come up with the safe, clean energy car.
are simply hallucinogenic.
Remember, the difference between communism and capitalism is that sharing is mandatory in the first and optional in the second.
The Raven.
The Raven
For example:
The Linux kernel is 'copylefted' software, patented under the GNU GPL, and thus, nobody actually owns it.
In fact, the relevant law is copyright not patent and most portions of the kernel are owned by the programmer who wrote them.
For example:
Similarly important was Linus's decision to create a highly portable [their emphasis] system.
In fact, the original kernel was very i386 specific and non-portable . The portability only came later. (Torvalds did aim for POSIX compatibility to make it easier to port codes to his kernel.)
There are many other errors in the article. Admittedly, mostly minor details but they do make me wonder about the quality of the "peer-review".
Next week version 2 of this doc will be put on the Net after the author has a chance to read Slashdot and incorporate all of the corrections (read: criticisms) we are posting here.
:)
Maybe I'll just save some time and frustration by skipping this one and reading the next version.
----- rL
The piece is lucid and interesting. However, it is intended to advocate rather than to critically examine the principles of the open source/free software movement. It admits that this movement is a kind of "religion," and like a religious propagandist, the author shies away from asking hard questions about central points of doctrine.
/. crowd.
E. Raymond describes this phenomenon in this way - "Given enough eyeballs, all bugs are shallow" - pointing out that security is an aspect of reliability. And such reliability can only be achieved through massive and parallel peer review.
A clear principle, to be sure, but is it a valid one? When bugs are tracked on major open source projects, such as Debian and Mozilla, the number of outstanding bugs only increases as a trend. When ESR turned up recently on the Linux kernel mailing list, he was jeered for the above maxim and told that it was demonstrably false. Robert Dewar of Ada Core Technologies -- a small business frequently cited as an open source success story -- has said that his organization is not particularly interested in outside bug fixes, since they are usually incorrect or incomplete. These anomalies and disagreements are not mentioned in the paper. A false picture of doctrinal consensus is painted instead.
Linux is synonymous to decentralisation since the project is developed by thousands of dispersed people who collaborate under no central planning.
Is it really true that Linux employs a decentralized network structure supported by volunteers? In fact it appears that hierarchical control is maintained, and maintained primarily by people who are paid to perform that job.
Nowadays, increasingly more 'big players' are joining the web: IBM, Dell, Oracle, Intel, HP, SAP and others have been tantalised by Linux and its Open Source development model, that have started investing heavily in the 'Linux platform'.
Tantalized? Oracle and SAP are proprietary par excellence. At a recent meeting with SAP in Frankfurt, I was told directly that the use of free software development tools would thwart SAP participation due to the lack of a liability structure. Dell offers Linux on its servers but that's the extent of its open source software development. This company list appears to be fabricated -- only IBM is clearly an open source backer, and even there, this year's open source campaign may have been a flash in the pan.
The management of this web depends heavily on the fact that every member of the web does not place any restrictions or rules on the other participants.
This is not at all true. In fact the large projects are tightly controlled by their inner circle, who place many restrictions on would-be volunteers. This is not news to the
Calling Emacs editor an editor is like calling the Earth a nice hunk of dirt. Emacs is an editor, a web browser, news reader, mail reader, personal information manager, typesetting program, programming editor, hex editor, word processor, and a number of video games. Many programmers use a kitchen sink as an icon for their copy of Emacs. There are many programmers who enter Emacs and don't leave to do anything else on the computer. Emacs, you'll find, isn't just a program, but a religion, and RMS is its saint.
This final passage is plainly ideological and even hero-worshipping. It is where the author drops all pretense at objectivity. In fact emacs is a design nightmare. It is wholly unsuitable for the use of non-engineers. If emacs is the free software ideal, that demonstrates why free software may never break out of its engineering niche. Strangely for a business-targeted paper, virtually nothing is said about customer satisfaction issues under the open source model. There are a few comments on the topic before the author gets to Linux, but once he's there, there's nothing from a process perspective on how open source development can enhance customer satisfaction. The reason may be that it can't. Programmers left to themselves create software for themselves, and programmers are strange people whose software requirements are very different from those of the public. Unless they are placed under hierarchical discipline by others more attuned to real-world requirements, they are incapable of producing software for end users. Unfortunately, there seems to be little place for that accountability to the customer in the open source development model.
Tim
This person is imagining the development and process management structures and practices at Microsoft. For that matter, the same conclusions apply to everything done at Oracle, Symantec, CA and IBM and everywhere else, and therefore only Linus Torvalds knows how to lead a project successfully and everyone else (that is not an open source company or project) is completely clueless and doomed to failure. Sheesh.
It's a good analysis of how one of the few really successful Open Source project models work but I can see no evidence there that Microsoft is doing something wrong (except perhaps, in the eye of the author, not giving away the code for Windows).
It's really surprising when one finds out that the enemy really doesn't breathe fire or smell of sulfur, but it's also hard to accept.
The software development process sucks more or less depending on who dreams it up and puts it to practice, but the quality of its end results have nothing to do with whether or not the source is being given away.
That is what our researcher friend is missing here.