Slashdot Mirror

I know that young-earth creationists like to do things like apply carbon-14 dating to things that are older than 6000 years or so. Or they might apply it to things like ancient sealife which are known not to participate in quite the same carbon cycle as land based life. Basically, let's use the test in a way no trained biologist would and then claim that proves the test doesn't work. Other forms of radioisotope dating can also be selectively misapplied. I suspect young-earthers don't like uranium-lead dating much either since it covers even larger timescales. Pick the wrong type of rock anyone?

Old-earth creationism might...just MIGHT...have a leg to stand on. Young-earth Bibilical literalism just isn't worth taking seriously. For the young-earth point of view to prevail, extreme violence must be done to more than just the life sciences. Chemistry, physics, geology, cosmology and others must all be severely twisted if literalism is to be viable. ALL of those disciplines show that the earth and the universe in general is much older than young-earthers can tolerate. What's funny is that even though literalists would destroy science in their triumph, they love to sound scientific.

In reality, young-earthers admit their literalist beliefs must be paramount in any discussion. Their take on the Bible is said to be "inerrant". If any scientific finding counterdicts that interpretation of the Bible then something must be wrong with it. It also follows that biological evolution is what offends them the most but it isn't the only thing that offends them. A political triumph by young-earthers would result in Lysenko style scientific absurdities.

"Openness means dirty laundry IS aired in public." This is strictly a bad thing. We don't need to have CIOs potentially exposed to Richard M. Stallman and his self-aggrandizement. We don't want to have our critical customers exposed to the egos that rewrite dictionaries and spam mailing lists with idiotic rants about "anti-idiotarianism."

Frankly, I think the Open Source movement's greatest enemy is its own membership. When a professional software developer lets his ego get the best of him, he gets fired. When an open source developer starts ranting, he starts public embarrassing flame wars that only undermine investors' confidence in the viability of Linux tools.

Sincerely,
Seth Finklestein
Flaming For Peace

Googled up some more info.

A lot of folks in Silicon Valley are so drunk on their own bath water that they simply don't get Linus. Take Steve Jobs. After Linus moved to the States in 1997, the acting Apple Computer CEO got in touch with him. Jobs wanted to persuade Linus to get involved in making the MacOS an open source code project. "He tried to get the Linux movement going more into the Apple area. I think he was surprised that his arguments, which were the Apple market share arguments--which would have made an impression on people who did this for commercial reasons--had absolutely no impact on me,'' Linus says.

According to Torvalds, Jobs assumed that he would be interested in joining Apple's mission to capture more of the personal computer market from Microsoft, rather than continue concentrating on Linux. "I don't think Jobs realized that Linux would potentially have more users than Apple, although it's a very different user base."

Why don't you stop posting this crap and educate yourself instead twitter?

Thanks. My impression is that if such a stament exists it would be quoted here, whereas we only get this:

M: What is your opinion of 386BSD?

L: Actually, I have never even checked 386BSD out; when I started on Linux it wasn't available (...), and when 386BSD finally came out, Linux was already in a state where it was so usable that I never really thought about switching. If 386BSD had been available when I started on Linux, Linux would probably never had happened.

Perhaps you should read to find out why the GPL is such a stunningly bad idea - I've read quite extensively on the subject. I suggest starting with Nikolai Bezroukov's excellent and very thorough treatment of the subject at SoftPanorama.org (Warning - reading this through thoughtfully and checking references will take a considerable amount of time, which is why most GPL proponents are so badly informed - they are generally unwilling to be anything other than shallow cheerleaders for RMS - actually thinking is way too much like work...)

The GPL was never a good idea, but the free/open source software community has gleaned what it can from that mess, and it's time to move on. Any suggestions I have for changing the BSD license do NOT turn it into the GPL, but rather are explicitly designed to *prevent* BSD licensed software from being GPL'ed. That was obvious if you were paying attention.

Don't bother to reply unless you've spent the time to read Bezroukov, as I no longer engage in flame wars with those that refuse to do thier homework...

Be careful how you speak of Linus' daughter's godfather.

I didn't believe it until I found another page that made the same claim.

I think the FSF's definitions are good and hope a court will uphold them. But note (emphasis mine):

RMS: We have no say in what is considered a derivative work. That is a matter of copyright law, decided by courts (...) we cannot tell the courts to treat a certain kind of work as if it were derivative, if the courts think it is not. (...) I think we have a pretty good argument that nontrivial dynamic linking creates a combined (i.e. derivative) work.

That's good news -- that means SCO couldn't arrange to lose on their own preposterous "derivative" claims and take down the FSF's definition in the process. I hope this is true, but my fear is that's what they set out to do.

People should also read this, well, and this.

All I'm trying to say is, all your heros have some skills, but they are also full of hot air and say and do stupid things. They are only human after all.

I have great respect for Linus, because is good sides outweight the bad, I can't say the same thing about ESR, RMS and Bruce Perens.

People should also read this, well, and this.

All I'm trying to say is, all your heros have some skills, but they are also full of hot air and say and do stupid things. They are only human after all.

I have great respect for Linus, because is good sides outweight the bad, I can't say the same thing about ESR, RMS and Bruce Perens.

"In other words, the needs of '"infrastructure components" and of business software modeling are sufficiently different that the best techniques for one may not apply to the other. The longer-term patterns of change are just different for each."

The pre-OO thinking was that a system should be a series of black boxes with clearly defined inputs and outputs ("wires"). These wires carried relatively simple signals between the various black boxes of the system. The complexity was in the black boxes, not in the wires. However, OO thinking tends to complicate the wires. In fact in OO the wires themselves tend to become black boxes. In pre-OO thinking the wires were usually simple data like numbers, strings, and occasionally arrays and tables (or handles/pointers to them). In OO the inputs and outputs are often complex OO classes which often have complex behavior attached to them. Thus, the wires in OO are actually no different from black boxes themselves. But why is a bunch of tightly interconnected boxes bad? Mostly because it is tougher to comprehend each black box in isolation. A given black box will often depend on the behavior of one or more of it's inputs and outputs (parameters) in OO thinking. Although OOP's version of black boxes may still be black to the user of them (programmer), they are essentially gray boxes to *other* boxes, and thus the programmer is forced to consider the *combined* behavior. You may have to even follow a long chain of classes to sufficiently understand the original module or method. It is perhaps possible that you may have to understand an entire OO system just to fully comprehend the behavior (or results) of a single piece of code. OO may give the illusion of simple, independent pieces; but is actually building one or a few very large, complicated black boxes instead.

"In other words, the needs of '"infrastructure components" and of business software modeling are sufficiently different that the best techniques for one may not apply to the other. The longer-term patterns of change are just different for each."

The pre-OO thinking was that a system should be a series of black boxes with clearly defined inputs and outputs ("wires"). These wires carried relatively simple signals between the various black boxes of the system. The complexity was in the black boxes, not in the wires. However, OO thinking tends to complicate the wires. In fact in OO the wires themselves tend to become black boxes. In pre-OO thinking the wires were usually simple data like numbers, strings, and occasionally arrays and tables (or handles/pointers to them). In OO the inputs and outputs are often complex OO classes which often have complex behavior attached to them. Thus, the wires in OO are actually no different from black boxes themselves. But why is a bunch of tightly interconnected boxes bad? Mostly because it is tougher to comprehend each black box in isolation. A given black box will often depend on the behavior of one or more of it's inputs and outputs (parameters) in OO thinking. Although OOP's version of black boxes may still be black to the user of them (programmer), they are essentially gray boxes to *other* boxes, and thus the programmer is forced to consider the *combined* behavior. You may have to even follow a long chain of classes to sufficiently understand the original module or method. It is perhaps possible that you may have to understand an entire OO system just to fully comprehend the behavior (or results) of a single piece of code. OO may give the illusion of simple, independent pieces; but is actually building one or a few very large, complicated black boxes instead.

from here:

The University's suit claimed that USL had failed in their obligation to provide due credit to the University for the use of BSD code in System V as required by the license that they had signed with the University. If the claim were found to be valid, the University asked that USL be forced to reprint all their documentation with the appropriate due credit added, to notify all their licensees of their oversight, and to run full-page advertisements in major publications such as The Wall Street Journal and Fortune magazine notifying the business world of their inadvertent oversight. Soon after the filing in state court, USL was bought from AT&T by Novell. The CEO of Novell, Ray Noorda, stated publicly that he would rather compete in the marketplace than in court. By the summer of 1993, settlement talks had started. Unfortunately, the two sides had dug in so deep that the talks proceed slowly. With some further prodding by Ray Noorda on the USL side, many of the sticking points were removed and a settlement was finally reached in January 1994. The result was that three files were removed from the 18,000 that made up Networking Release 2, and a number of minor changes were made to other files. In addition, the University agreed to add USL copyrights to about 70 files, although those files continued to be freely redistributed.

Noorda isn't the CEO of Sco, but he founded Caldera, and I think he's involved in this little shananagan.

I imagine it's listed on any number of "Maps of the Stars Homes" which can be acquired about town.

Maps to the skaters homes! Maps to the skaters homes! LOL!!

Natas Kaupas kicked arse! Yeah I know he wasn't in Search for Animal Chin but he still rocked. As did Mike Vallely and Ian Mckaye. Unixpunx.org is a safe haven from the geeky nerdish 34 year old virgin idiocy of slashdot.

Guess what? RMS actually programmed some pretty cool shit. ESR on the other hand is a cum gobbling faggot who needs a bullet in the head.

Fuck ESR

I've still got NC for when I have to boot to DOS and/or from a floppy. Its main drawback these days is that it doesn't understand long file names, so if you move files around with it you get a lot of ~1 names. However, there are many very good apps that mimic it to a greater or lesser extent. I like Far which runs under Win32 (but not DOS). On *.ix there's MC (Midnight Commander) which also has a DOS version, though it's a bit clunky there. A full survey of what the author calls Orthodox File Managers is here. Many seem to from Russia, home of hard core functional hackers.

Any software project larger than "Hello World!" is going to be dependant upon libraries which are liscensed under the GPL. While the LGPL was created to address some of these issues, not every library is liscensed under the LGPL, so the problem still exists. This includes the very prevalant C++ library which includes the cin and cout operators which I'm sure every programmer has used at some point in his or her career.

Please see here, here, or here for documentation supporting my claims. The last link goes to an article written by Stallman himself addressing this problem, so please don't try and tell my that my information is based on Microsoft FUD.

Of course the BSD vs. GPL license debate is not new. Here's a link to a very good article on the subject. The author does lean toward BSD, but there is a lot of good information. Also, here are the author's research notes for the paper.

Neither BSD nor GPL does much for the "end-user" If we're talking about licenses we're talking about coders' and distributors' rights. As a coder, I'll use BSD because I want to give my code away. I want people to use it. I don't care if they make money off of it. If I do care, I'll use GPL. Simple.

My code can't be "exploited" because I said they can do pretty much whatever they hell they want with it (under BSD) I want the code I release to be free in the truest sense. Your code (or modifications) I don't really care about, so do what you want, even if that means re-releasing under GPL.

Of course the BSD vs. GPL license debate is not new. Here's a link to a very good article on the subject. The author does lean toward BSD, but there is a lot of good information. Also, here are the author's research notes for the paper.

Neither BSD nor GPL does much for the "end-user" If we're talking about licenses we're talking about coders' and distributors' rights. As a coder, I'll use BSD because I want to give my code away. I want people to use it. I don't care if they make money off of it. If I do care, I'll use GPL. Simple.

My code can't be "exploited" because I said they can do pretty much whatever they hell they want with it (under BSD) I want the code I release to be free in the truest sense. Your code (or modifications) I don't really care about, so do what you want, even if that means re-releasing under GPL.

Does this remind anybody of Lysenkoism? For a long time, the Soviets under Stalin maintained that science had to support party policy, even if it resulted in horribly distorted science. Scientists who dissented were suppressed and sent to prison camps.The government policies based on the resulting bad science (particularly in agriculture) resulted in countless deaths from starvation, and kept back Russian science in many fields for decades. OK, so we're not sending scientists to prison camps yet; But it's scary to think that we might allow politically-motivated committees to determine what is scientific "truth" based on what the current administration would like to be true. Those who fail to learn from the mistakes of the past are destined to repeat them.

Is there a site or a HOWTO that gives hints on how to start getting the upper management in a company thinking about alternatives like this?

Yup.

Linux Advocacy mini-HOWTO
Bad Linux Advocacy FAQ
Don Marti's "Linuxmanship"

I recommend "Linuxmanship" the most highly.

-Waldo Jaquith

The user has already learned the interface. (The learning curve for command-line interfaces is steeper than for GUIs, especially if the user has first experience with a GUI. With a blank slate computer user, the learning curve is about the same...but how many blank slates who've never used Windows -- or a video game controller -- do you find?

Actually, I think the poster of the parent comment was talking about OFMs. These actually don't have a steep learning curve because A) they're usually at least quasi-GUI, and B) they all use the same keystrokes, so once you've learned one OFM, the others are all pretty much the same (F5 for copy, F6 for move, F7 for mkdir, F8 for delete, yada yada) (this contradicts your second point)

dare I commit a computer junkie sin, and ask what is *truly* the point in running dual processors

If you're developing multi-threaded code (and yes, I know the debate, but for some tasks it is an easier way to make a single-cpu app more responsive) then you haven't really tested for deadlocks and synch problems until you've run it on a multi-cpu machine. Thats my excuse to the wife for buying a dual Athlon machine anyway...

T

"Real multithreading" is really no panacea. See the notes from John Ousterhout's talk, Why Threads Are A Bad Idea (for most purposes).

I hear a deafening silence! It seems to be coming
from... wait... I can't quite... but I can make out
an e-mail address... it's esr@thyrsus.com... and
the source is... http://www.tuxedo.org/~esr/ !!
We
told you so.

"Slightly skeptikal Open Source Software Educational Society
This page is devoted to the research of the Open Source Software (OSS) phenomena without rose-colored glasses. I am convinced that we need to understand both strong and weak points of OSS and the former is impossible without the latter. Both exists. This page neither promotes an OSS euphoria nor the cynical pessimism of some commercial developers."

The main site of the bloke that wrote that reasonably high profile critique of CatB a while ago. There is mountains of stuff here in the same vein, and to my mind it makes interesting reading, if a little over laboured at times. A few spelling mistakes and technical errors but I don't think English is the chaps native tongue.

Kidding aside... Softpanorama has lots of papers, links to papers about open source.

I detail some of the flaws I see with open source software in my paper The Wall Street Performer Protocol.

It's maybe not such a good idea to take stuff such as "The Cathedral and the Bazaar" as a description of how software development, free or otherwise, ought to be handled. Here is some good analysis and criticism of "CatB" et al. .

Collaborative social constructs that enable the accumulation of software capital will become very important for the OSS community to identify and exploit once market subsidies based on false business promise disappear.

You should also read Steven Levy's 'Hackers'. It should be required reading for any fledgling computer geek.

"Once, when Linus was abroad at some conference or another, he modified my shell setup scripts so that when I logged in, it looked as if I was using MS-DOS. That was fun, of course, but it begged for revenge. This happened while we were sharing an office at the university, so once when Linus went out to get something to drink or something, I created an alias for startx for him. My alias first ran the real startx, and then printed out a kernel `Oops' message. The first time Linus noticed this made him a bit worried, but he logged out and cleared the screen too fast to read it, but the second time made him really worried. I'd copied the `Oops' message from linux-kernel, and of course it didn't suit Linus's kernel at all. He had gotten as far as decoding the message by hand, and muttering something like ``Why is it crashing there? It can't crash there!'', when I burst out laughing and told him what I'd done. Linus what quite relieved and never tried any practical jokes on me again."

Helping the learning disabled is a great cause, in that it's harder for them to benefit from technology as easily as, say, verbally skilled blind people. You might also look at work in developing countries.

Hi sulli,

In general i agree with you. And you are a business guy (indicated from your homepage.) It's nice to see someone like you here. I am a techie. I think both types of people are needed. Many slashdotters don't like business people. Why?...

Which makes me wonder: why don't execs like this spend more time trying to drive standardization OF SOME KIND instead of just bitching about Microsoft?

I don't know about other execs. But KDE vs GNOME are a developers' & volunteers' world. No execs could force them to change.

Besides, all linux distros comapanies are still too small. These execs are busy with running their businesses. They couldn't afford to gather for standards, unlike IBM, MS, Sun and AT&T who are big.

As for Bob ... I bet he is well above average. He is as good as B. Gates. But again he could not fight with IBM + Sun + MS combined -- he does not have enough capital. He is also greedy/ambitious that he wanted to create another empire. Linux/GPL empire.

But too late. IBM is no longer the IBM in the early eighties. And Bob, since he is a very clever entrepreneur, now has other plans. BTW i think personally he thinks he is rich enough. So now he merely wants RH to be successful. But not an empire.

He doesn't really care about KDE vs GNOME. Or world domination anymore.

Have you ever read an interview of Bob in, i believe, Linux-World magazine? You might be interested.

And you might also be interested in this

Cheers,
Ricky

Relax. The original poster seems to be a BSD supporter.

Nevertheless, Linux has some advantage that *BSD hasn't.

Linus

*BSD are created by a group of professional developers. Nothing spectacular. It's very,very boring.

Linux is different. 'A free operating systems created by a former Finnish University Student during his free time which almost overthrow the evil Microsoft Empire...'

No disrepect here. Just an observation. (Acutally you could read an interesting perspective from http://www.softpanorama.org/index.shtml)

Ricky

sed -e s/[gG]un/Penis/g \
-e s/[bB]ear/Dangle/g \
-e s/[aA]rms/Phalluses/g \
-e s/[tT]rigger/Glans/g \
< http://www.tuxedo.org/~esr/guns/gun-ethics.html

And then go read the original source: plenty more where that came from.

For more info, see the The Softpanorama University Orthodox File Managers Site.

What, you're ever at a computer without access to TMMM!? :-)

Brooks does mention two mice, but has no pointers to further info. In Chapter 19 (pp. 261--262 in my A-W softcover edition), the section ``Command utterances and the two-cursor problem'' discusses how most commands consist of a verb and a noun---action and object---and how convenient it would be to use two cursors to simultaneously select each. The notes for that chapter are prefaced with ``Material quoted without citation is from personal communications.'' The note from that subsection, says in its entirety:

7. It appears the Apple Desk Top Bus could handle two mice electronically, but the operating system provides no such function.

If you haven't read this book, do so now. If you wonder why, you might check some reviews:

• A collection of reviews at Softpanorama.org. Covers more than just TMMM. Well worth checking out. The general site looks very interesting, too.
• /.'s own review. If anything, understated.
• Ed Yourdon's brief commentary, with an interesting sidelight on how the book got updated.
• Fatbrain.com's sales page $25
• Bookpool.com's sales page $24

What, you're ever at a computer without access to TMMM!? :-)

Brooks does mention two mice, but has no pointers to further info. In Chapter 19 (pp. 261--262 in my A-W softcover edition), the section ``Command utterances and the two-cursor problem'' discusses how most commands consist of a verb and a noun---action and object---and how convenient it would be to use two cursors to simultaneously select each. The notes for that chapter are prefaced with ``Material quoted without citation is from personal communications.'' The note from that subsection, says in its entirety:

7. It appears the Apple Desk Top Bus could handle two mice electronically, but the operating system provides no such function.

If you haven't read this book, do so now. If you wonder why, you might check some reviews:

• A collection of reviews at Softpanorama.org. Covers more than just TMMM. Well worth checking out. The general site looks very interesting, too.
• /.'s own review. If anything, understated.
• Ed Yourdon's brief commentary, with an interesting sidelight on how the book got updated.
• Fatbrain.com's sales page $25
• Bookpool.com's sales page $24

The 'linux community' has a sub-set of voices who have money in Linux-centric stocks and have a vested interest in seeing 'linux succeed'. VA Research^H^H^H^H^H^H^H^HLinux is an example of a voice that won't promote BSD unless they have to. Given money == volume, it is no wonder the BSD message is shouted over.

The voices are fine, it is what the voices *SAY*....$0 OSes/Open Source OSes == Linux (and only linux) that cause the problem.

Taking snippits from here these quotes are WHY there seems to be a division, because there *IS* a division.
The Institute has not yet seen fit to include the only companies which market products and services many in the Third World can actually afford, the Linux companies.
Now, anyone with 1/2 a clue or better knows that the ONLY companies that market products that are at a $0 cost option are NOT just Linux companies. There is BSD in the form of Darwin (the $0 option from Apple), FreeBSD, NetBSD, and OpenBSD.

So here is a 'linux voice' ignoring BSD, even thought the 'goal' of the voice is to help the 3rd world become aware of $0 options. Saying 'only linux' is being un-truthful.

Bruce P has a take on this, and I can understand his modivation:
Re: And BSD isn't affordable, nor corporate?
by Bruce Perens on Monday October 09, @03:31 AM BSD folks should be represented too. Hopefully, they can ask for representation in the same way the Linux folks are. Should the Linux folks fight their battles? I'd have no problem speaking out for them as a free software spokesperson. But I doubt that every Linux proponent should have to fight on the behalf of BSD.

Here is the source of a division.

If you are talking about 'open source alternatives to Micro$oft', then you should not be starting and ending with Linux. BSD is there, and you could always use HURD or even Minix. (if others have $0 options for personal/business use, please list em.) WRT HURD and Minix, there isn't alot of usefulness, so you are left with BSD.

When you talk about 'shrink-wrapped Linux binaries', do they even consider Solaris/SCO/BSD's Linux compatibility layer? If you don't think of BSD/SCO/Solaris, then you are adding to the division.

And, when someone approaches you and says: "Tell me about Linux", are they wanting to know about Linux, or are they "interested in knowing what they could run instead of Microsoft software" with Linux being the name on the tip of the tounge of the press.
(And Linus is in agreement with the POV that Choices to Microsoft should be varied.
That same attitude helps explain why Torvalds is so eager to counterbalance Microsoft's dominance. He wants computer users to have a choice among several operating systems, not just one from Microsoft. "I'm not rabid anti-Microsoft," he says. "But they make it so hard to compete.")

If *YOU* don't like the rift, what are you doing to bridge the gap? Do you say 'linux' as a shorthand for Open Source OS? When you ask vendors to create a 'linux binary', do you ask them to support BSD/SCO/Solaris with that linux binary?

And think about this:
Is it OK to go to a Windows technology roll-out to hand out Linux CD's, in the interest of letting ppl know about 'an option'?
Is it OK to go to a Linux Meeting and hand out BSD CD's, in the interest in expanding knowledge?

>Linux is better than BSD on almost all fronts.

Here Mr. Cox calls FreeBSD
"really technically excellent Operating System. "

Looks like Alan is not dismissive like you.

Richard talks about licensing, yet he is willing to take from others, and not honor the licensing desires of others.

If you are going to take the moral high ground and play the purist, then you had better be sure you are on the pure, high ground. A violation is a violation, and the GCC did violate another's licence.

The source page for this clipped /. article.

When will the FSF apologise?
by Pseudonym on Wednesday September 06, @01:11AM EDT (#100)
(User #62607 Info)
I have a copy of the source of glibc-2.0.105 sitting on my hard drive. In inet/rexec.c (amongst other files) what do I see but a file under the BSD licence including the advertising clause. Clearly I have no rights to this code since it cannot be distributed under the GPL.

Thankfully, in 2.1, the advertising clause has been removed. But nonetheless, I expect a full apology from the FSF for breaking the terms of the original BSD licence and forgiveness from the Regents of the University of California so that I can be assured that I may use glibc2 without let or hinderance.

I await my apology.

The way I read what he said was that the lack of affordable Unix systems, combined with Microsoft's shittiness, lead to Linux starting Linux. Here's a quote from Linus which seems to explain it:

It kind of evolved through luck and happenstance into an OS, simply because there was very much a void where there wasn't much choice for someone like me. I couldn't afford some of the commercial OSes and I didn't want to run DOS or Windows -- I don't even know, did Windows really exist then? source

The same page talks about how delays to BSD gave Linux early momentum. I think you could throw in there Microsoft's and IBM's inablility to ship a consumer 386-based OS in the late 80s as something that generally ticked PC users off. And UNIX solutions (from say SCO) were ungodly expensive for an individual.

I think it's fair to say that if someone was selling a 386-based UNIX for $100 in 1990, Linus at least wouldn't have invented Linux. FreeBSD would still be around though.

Maybe some other OFM for Unix has similar features available...

--

Raymondism FAQ

I came across this the other day when I was trying to differentiate between some of the licenses. It's not what you mention but it is definitely helpful.

------
IanO

would be PERFECT if source would be available

There are many good decompil ers available for Java .class files. Because of the way javac and the JVM work, it's very easy to get human-readable Java source out of (unobfuscated) .class files.

"The axiom 'An honest man has nothing to fear from the police'

From A Second Look at the Cathedral and Bazaar by Nikolai Bezroukov, First Monday, volume 4, number 12 (December 1999) http://firstmonday.org/issues/issue4_12/bezroukov/ index.html

Brooks' Law does not apply to Internet-based distributed development.

"The most common lie is that with which one lies to oneself; lying to others is relatively an exception."
- Fredrich Nietzsche

One of the most indefensible ideas of CatB is that Brooks' Law is non-applicable in the Internet-based distributed development environment as exemplified by Linux. From CatB (Italics in quotes are mine; original italics, if any, are bold italics):

"In The Mythical Man-Month, Fred Brooks observed that programmer time is not fungible; adding developers to a late software project makes it later. He argued that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly. This claim has since become known as "Brooks's Law" and is widely regarded as a truism. But if Brooks's Law were the whole picture, Linux would be impossible."

This belief that programmer time scales differently as soon as programmers are connected to the Internet and are working on open source projects is repeated elsewhere in a different form:

"Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software "hoarding" is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem."

First I would like to stress that the famous book The Mythical Man-Month has acquired the status of a classic in the software engineering field. The book is definitely, by several orders of magnitude, more important than CatB; this critique will not harm the book. Many other concepts, phrases and even chapter titles from that famous book have become part of software engineering terminology. I can mention "the second-system effect", "ten pounds in a five-pound sack", "plan to throw one away", "How does a project get to be a year late?...one day at a time". In the early 60s while working as a project manager of Operating System/360 (OS/360), Frederick Brooks observed the diminishing output of multiple developers and that the man-month concept is but a myth. It is as true in 1999 as it was in 1975 when the book was first published.

The real problem with the CatB statement is that due to the popularity of CatB this statement could discourage OSS community from reading and studying The Mythical Man-Month, one of the few computer science books that has remained current decades after its initial publication. Actually the term "Brooks' Law" is usually formulated as "Adding manpower to a late software project makes it later". The term "mythical man-month" (or "mythical man-month concept") is usually used to identify the concept of diminishing output of multiple developers even if all work on a given project from the very start. One of the best explanations of this concept was given by Ray Duncan in his Dr. Dobbs review of The Mythical Man-Month:

"What is a mythical man-month anyway? Consider a moderately complex software application from the early microcomputer era, such as the primordial version of Lotus 1-2-3, Ashton-Tate dBASE, or Wordstar. Assume that such a program might take one very smart, highly-motivated, expert programmer approximately a year to design, code, debug, and document. In other words, 12 man-months. Imagine that market pressures are such that we want to get the program finished in a month, rather than a year. What is the solution? You might say, "get 12 experienced coders, divide up the work, let them all flog away for one month, and the problem will be solved. It's still 12 man-months, right?

Alas, time cannot be warped so easily. Dr. Brooks observed that man-months are not - so to speak - factorable, associative, or commutative. 1 programmer * 12 months does not equal 12 programmers * 1 month. The performance of programming teams, in other words, does not "scale" in a linear fashion any more than the performance of multi-processor computer systems. He found, in fact, that when you throw additional programmers at a project that is late, you are only likely to make it more late. The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees.

When you stop to think about it, this phenomenon is easy to understand. There is inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be devoted to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there's at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger."

Most top-level software professionals are more like artists, in spite of the technical nature of their specialty. It is not a coincidence that another classic book on programming is entitled The Art of Computer Programming. Communication, personality and political problems definitely creep into any project, as any manager of a sizable programming project can attest. These problems certainly drag productivity down.

It's simply naive to assume that for the same team Internet connectivity can improve performance in comparison with, say, LAN connectivity or using the same mainframe. Moreover, if we are assume the same level of developers, geographically compact teams will always have an edge over distributed Internet-connected teams. Open source uses the Internet to connect a geographically distributed pool of talent. In turn, it potentially raises the quality of that pool in the absence of geographical barriers. Reducing the effects of distance does not eliminate other constraints under which such projects operate, but can dramatically increase the quality of the pool of developers. That's the only advantage that I see.

I believe that the illusion of the non-applicability of "mythical man-month postulate" and Brooks' law is limited only to projects for which a fully functional prototype already exists and most or all architectural problems are solved. This may have been the case for Linux, which is essentially an open source re-implementation of Unix. With some reservations, it is probably applicable for all systems for which both the specification (Posix in case of Linux) and reference implementation (say FreeBSD or Solaris) already exist and are available to all developers. As was pointed out in the Halloween-I document:

"The easiest way to get coordinated behavior from a large, semi-organized mob is to point them at a known target. Having the taillights provides concreteness to a fuzzy vision. In such situations, having a taillight to follow is a proxy for having strong central leadership. Of course, once this implicit organizing principle is no longer available (once a project has achieved "parity" with the state-of-the-art), the level of management necessary to push towards new frontiers becomes massive. This is possibly the single most interesting hurdle to face the Linux community now that they've achieved parity with the state of the art in UNIX in any respects."

From A Second Look at the Cathedral and Bazaar by Nikolai Bezroukov, First Monday, volume 4, number 12 (December 1999) http://firstmonday.org/issues/issue4_12/bezroukov/ index.html

Brooks' Law does not apply to Internet-based distributed development.

"The most common lie is that with which one lies to oneself; lying to others is relatively an exception."
- Fredrich Nietzsche

One of the most indefensible ideas of CatB is that Brooks' Law is non-applicable in the Internet-based distributed development environment as exemplified by Linux. From CatB (Italics in quotes are mine; original italics, if any, are bold italics):

"In The Mythical Man-Month, Fred Brooks observed that programmer time is not fungible; adding developers to a late software project makes it later. He argued that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly. This claim has since become known as "Brooks's Law" and is widely regarded as a truism. But if Brooks's Law were the whole picture, Linux would be impossible."

This belief that programmer time scales differently as soon as programmers are connected to the Internet and are working on open source projects is repeated elsewhere in a different form:

"Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software "hoarding" is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem."

First I would like to stress that the famous book The Mythical Man-Month has acquired the status of a classic in the software engineering field. The book is definitely, by several orders of magnitude, more important than CatB; this critique will not harm the book. Many other concepts, phrases and even chapter titles from that famous book have become part of software engineering terminology. I can mention "the second-system effect", "ten pounds in a five-pound sack", "plan to throw one away", "How does a project get to be a year late?...one day at a time". In the early 60s while working as a project manager of Operating System/360 (OS/360), Frederick Brooks observed the diminishing output of multiple developers and that the man-month concept is but a myth. It is as true in 1999 as it was in 1975 when the book was first published.

The real problem with the CatB statement is that due to the popularity of CatB this statement could discourage OSS community from reading and studying The Mythical Man-Month, one of the few computer science books that has remained current decades after its initial publication. Actually the term "Brooks' Law" is usually formulated as "Adding manpower to a late software project makes it later". The term "mythical man-month" (or "mythical man-month concept") is usually used to identify the concept of diminishing output of multiple developers even if all work on a given project from the very start. One of the best explanations of this concept was given by Ray Duncan in his Dr. Dobbs review of The Mythical Man-Month:

"What is a mythical man-month anyway? Consider a moderately complex software application from the early microcomputer era, such as the primordial version of Lotus 1-2-3, Ashton-Tate dBASE, or Wordstar. Assume that such a program might take one very smart, highly-motivated, expert programmer approximately a year to design, code, debug, and document. In other words, 12 man-months. Imagine that market pressures are such that we want to get the program finished in a month, rather than a year. What is the solution? You might say, "get 12 experienced coders, divide up the work, let them all flog away for one month, and the problem will be solved. It's still 12 man-months, right?

Alas, time cannot be warped so easily. Dr. Brooks observed that man-months are not - so to speak - factorable, associative, or commutative. 1 programmer * 12 months does not equal 12 programmers * 1 month. The performance of programming teams, in other words, does not "scale" in a linear fashion any more than the performance of multi-processor computer systems. He found, in fact, that when you throw additional programmers at a project that is late, you are only likely to make it more late. The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees.

When you stop to think about it, this phenomenon is easy to understand. There is inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be devoted to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there's at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger."

Most top-level software professionals are more like artists, in spite of the technical nature of their specialty. It is not a coincidence that another classic book on programming is entitled The Art of Computer Programming. Communication, personality and political problems definitely creep into any project, as any manager of a sizable programming project can attest. These problems certainly drag productivity down.

It's simply naive to assume that for the same team Internet connectivity can improve performance in comparison with, say, LAN connectivity or using the same mainframe. Moreover, if we are assume the same level of developers, geographically compact teams will always have an edge over distributed Internet-connected teams. Open source uses the Internet to connect a geographically distributed pool of talent. In turn, it potentially raises the quality of that pool in the absence of geographical barriers. Reducing the effects of distance does not eliminate other constraints under which such projects operate, but can dramatically increase the quality of the pool of developers. That's the only advantage that I see.

I believe that the illusion of the non-applicability of "mythical man-month postulate" and Brooks' law is limited only to projects for which a fully functional prototype already exists and most or all architectural problems are solved. This may have been the case for Linux, which is essentially an open source re-implementation of Unix. With some reservations, it is probably applicable for all systems for which both the specification (Posix in case of Linux) and reference implementation (say FreeBSD or Solaris) already exist and are available to all developers. As was pointed out in the Halloween-I document:

"The easiest way to get coordinated behavior from a large, semi-organized mob is to point them at a known target. Having the taillights provides concreteness to a fuzzy vision. In such situations, having a taillight to follow is a proxy for having strong central leadership. Of course, once this implicit organizing principle is no longer available (once a project has achieved "parity" with the state-of-the-art), the level of management necessary to push towards new frontiers becomes massive. This is possibly the single most interesting hurdle to face the Linux community now that they've achieved parity with the state of the art in UNIX in any respects."

Do not be fooled by the "vulgar raymondism". Brooks's law is about software engineering, not coding.

Read the first chapter of "The Mythical Man-Month: Essays on Software Engineering" to understand the differences among a program, a system, a product and a product-system.

"Judging from the real lack of true "Bazaar" applications of any size or significance that started as GPL'd projects with broad developer input (as opposed to projects that are released to GPL after a considerable amount of time is spent on them by the small group of developers who start the project) the GNU Virus will always need to "infect" healthy hosts much the same."

In fact, it seems that once "Opened" development slows down radically in any project. Witness the complete dismal failure that is Mozilla.

A little more heretical info can be found here.