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.
This pseudoscience about organizational dynamics is what is referred to as curve fitting - using your results to frame your hypothesis.
"Loosely decentralized virtual organizations" could just as soon describe a bowling team. Its gibberish folks.
I don't know about everyone else here, but personally after 2000 I've been a bit skeptical of claims that something "is breaking new ground and traditional structures and theory don't fully apply to it."
Tarsnap: Online backups for the truly paranoid
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.
Confessing up front that I've only read the parts relating to free/open source and Linux, and skimmed the rest of that HUGE opus ...
At some level the observations here are completely predictable. It's old hat to anyone who's tried to get something large under way; the buzzwords aren't news. The interesting bits are when the author talks about how the Linux model might work in other industries.
What I've found interesting about the Linux community is best observed as a contrast between how Linux works, and how most other software projects I've been on have worked. Briefly, it's the central planning thing. Microsoft is just a big and current example, not the only one.
Traditional OS software orgs insist on being able to control lots and lots of things, just so that they can present plans justifying themselves to folk who finance their work. And many of those financers are actually trying to sell hardware; look at Sun, DEC, HP, IBM, or most folk now working in OS software without Linux. OS decisions that don't immediately sell hardware tend to get under-rewarded, compared to Linux. And because of management overheads, there is no way to incorporate very much work that's not a current "top" priority since such efforts detract from the process of collecting fat bonuses (issued for short term goals far more than long term ones).
A lot of the "parallelism" of Linux is just the fact that developers have finally started to be able to escape from such straitjackets, and don't need to tie themselves so exclusively to short sighted bottom line issues. It's those short planning horizons that have hobbled most software organizations without the benefit of a monopoly over most of a large industry.
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
It defies Brook's Law because of its parallel release structure, extreme modularity, "trusted lieutenants" structure and as a consequence, co-ordination costs are almost negligible.
IIRC, Brook's law applies for networked communication. Hierarchical communication is therefore created to reduce this overhead. Extreme modularity doesn't prevent the merging cost. The interesting note here is that this paper doesn't address who is behind the scene to put all of this together.
I am not a Linux developer, but I believe Linus is the ruler of all of them. If he doesn't like the way things integrated, he just demote the component. Thus the maintainer does the job to comply. Recall on how many "new" components, such as ext3 and others must wait and comply to this rule? The rule is pretty rigid and widely accepted by all developers. All his "lieutenants", such as Alan Cox, also applies the same rule.
Moreover, Linux developers are all dedicated people, not just people that wants money to do their work. They want recognition. So, they will try very hard to push their "product" into the development line.
It's not just the Brook's Law, I suppose... Anyway, that's my 2c.
--
Error 500: Internal sig error
Maybe I'm just picky, but the author lost my respect by the third paragraph of the section on Linux, when he started talking about "trademarked" software. It seems like someone who is writing about the effects of different ways of creating intellectual products should have a basic, layman's understanding of Intellectual Property law, at least.
Software can be (and almost always is) copyrighted. It can also be kept as a trade secret and, in some cases and in some countries, software algorithms can be patented. But "trademarking" is something done to names and logos, not pieces of software.
Annoying.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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".
Things like this can really distract a reader, ya know?
I don't know why, 'cause it IS actually true...
also, the official name for the Debian Linux distribution is Debian GNU/Linux.
Advanced users are users too!
People in our business can talk and often write lucidly, but not one of us can draw worth a damn. Because of the pictures and tables, this is a great resource to show PHBs who need pictures and tables to draw their short attention spans back to the text.
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
"The Cathedral and the Bazaar" and the "Halloween Memo" have covered this ground, and better.
There are major unanswered questions to ask about "open source" as a process, but this paper doesn't ask them.
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.
Those diagrams in the paper really get the point across. I mean, take a look at them; especially Figures 8, 10 and 14. Now if they don't clear things up I don't know what will. How succint!
Are the graphs in this document completley screwey and arbitrary? One looked like a bowl of bambo chutes, but most of them looked like things I've seen in a microscope.
Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
But you are talking about anarchism, so let me switch gears.
Yeah, wouldn't it be great to be able to do whatever you want/need to survive. And just think, if you kill the guy across the street for his schweet new gaming rig, there's no Big Bad Police to come after you. Oh, SURE, the neighbors might be pissed and show up at your doorstep with pitchforks, but don't worry, it's an anarchist country. They can kill you if they want to as well!!!
So of course people in general will want/need at least a little structure, right?? Just a smidge. Fine, we'll give our neighborhood a person to help with disputes/crime/emergencies. We'll call him the "Shaman."
Well, pretty soon, there's too many people for the Shaman to take care of. We'll need more structure... let's call our new leader the "Chief."
The chief, of course will have an inner circle to dispatch his orders... lets call them the "Tribal Council"
Now that we've elevated ourselves to Tribe, I don't think we need any more order. We can develop and live in peace. All among us and abroad can see our progression (and our source code, of course.) But what's this? The tribe over yonder is jealous?? They want a piece of OUR prosperity? So they invade... that's when we have (what may we call it?) a WAR!
So tribes fight and kill, some merge and form alliances, to the pont where in order for one alliance to protect themselves, they form regualar NATIONS!!! Time passes, nations evolve through progressions of leadership, growth, insurrection, merger, division... and eventually we have an EMPIRE.
So the far flung nation states start getting pissed... the frikken EMPIRE is too damn opressive, they whine... but didn't this START OUT as an ANARCHY?? Oh, NOW I REMEMBER... people simply didn't like getting KILLED by their next door neighbors. Boo-hoo, they thought it was a PAIN IN THE ASS.
So, we'll do it right this time... We'll attempt a REPUBLIC (yeah, the greeks tried true DEMOCRACIES, they got their asses kicked by nations that had smarter leaders and could make decisions faster)
So here we are, on top of the world... and other nations are STILL TRYING TO KILL US!
It makes you think (I hope)... without a government, they'd STILL be flying planes into our buildings... (Though I'm sure other countries would have beat them to it with better weapons than that.) Government or not, HUMAN BEINGS ARE VIOLENT MOTHERFUCKERS.
Oh, yeah. Getting back to the topic...
The author clearly does not believe that Open Source operates as an anarchy... rather it is specifically an unstructured medium from which profit-making organizations can arise. Of course, in order for the profit-makers to maintain a competitive edge they necessarily have to recreate some of the open-source environment. Overall, in order to succeed these companies need to do two things:
Another side benefit pointed out in the paper(well, not explicitly) is that if you use an open source management model to cater to your potiential developer/employee base your job training becomes minimal, thus saving you $$. And isn't that what it all comes down to for those filthy Americans? eh, comrade?
IMHO, I think every company has TWO customers. The END USER (The guy who buys the hamburger), and the EMPLOYEE (The guy who cooks the hamburger). Keep the employee happy, and the customer will get fewer burgers with boogers in the sauce, or less software with bugs in the code.
BTW, I understand you're not much of a rational thinker; your post reeks of it. But don't cry, just about everybody on slashdot is like that.
And if you wanna make some commentary on politics sometime POST SOMEWHERE THAT WANTS YOUR NAIVE HIPPIE ANARCHIST OPINION.
To change the world all at once is certainly a great dream for children and mental patients but give it a good long try with just ONE person at a time and you'll see why the world is like it is.
I'm done with sigs. Sigs are lame.
Many of these ideas are covered better in "The Hacker Ethic". It does a much better job than this article, and takes a more studious approach. It also includes a secton written by Linus Torvalds.
Software sucks. Open Source sucks less.
Of course, the author meant to refer to An Open Letter to Hobbyists. One wonders if this mistake was made by the original author, or by well-meaning but ignorant editors.
This piece is typical first-MBA-thesis quality, and I agree it casts doubt on the quality of the peer review and the site that publishes it.
Funny, but the diagram doesn't appear to show Conxion, which is the hosting company that has "virtually all" of Microsoft's download servers. . .
Any sufficiently well-organized community is indistinguishable from Government.