Re: os discuss (http://www.osopinion.com/perl/story/7263.html)

["Robert G. Brown" <bob@xxxxxxx>]

>>>....you can't ignore the invisible hand of the
>>>market place.
>>I don't believe anyone is ignoring the marketplace at all.
>>Quite the contrary. Linux is the only OS making headway in
>>the broad OS marketplace,...
>I didn't say the market place was being ignored.  I said
the invisible hand was, or the forces behind the market.
Hair-splitting, Chris. The marketplace is the sum of the effects
of all of the market forces. The effects of the "invisible hands"
are factored in.

>>>Deadlines ARE important.
>>Please substantiate this claim.
>People will demand more from the OS and expect it to be
>delivered on their timetable, not the developer's time
>table.
I suspect that in many cases, the developers timetable is more aggressive
than that of the users.

>If we wait for the developer to decide when it's ready, it may slow the
>wheel of progress.
If we don't wait for the developers to say it's ready, we get products
of inadequate quality, which is often worse for progress.

>I could diddle at a piece of software for decades and
>never release it because it's not perfect.
Yes, you could, but this theoretical extreme will remove you as a serious
market force. While you're diddling, someone will come up with something
that effectively answers the need, rendering your work effectively
worthless.

>...the end-user doesn't care if it's perfect,...just something close enough.
Which is EXACTLY what open source software is about.... release early, and 
release often. Software that starts out as little more than an idea and a
(perhaps unreliable and unstable) package then rapidly is evolved and often
ends up is very good shape indeed. 

>Perhaps this is one reason for the broad acceptance of Windows.
>We've been down this road before.
Yes, to high prices, proprietary formats for data, buggy software, and
monopoly power, exercised to criminal excess. Not IMHO an acceptable
outcome.

>>>And, as time goes by, software DOES become obsolete.
>>Yes, quite so. However, the RATE at which software becomes
>>"obsolete" is far slower than the producers of proprietary
>>software would have us think.....
>Conceeded.  But the rate slowed by delayed delivery
>dates.  If I want X but can't have it because John Q.
>Developer hasn't released it because...
>   o  He's got other things to do
Then he will be replaced as the leader of the project.

>   o  He works on it when he feels like it
Which is why many really successful OSS projects are supported by
TEAMS of developers.

>   o  It's not "Just Right" yet.
Hey, we already have the last release, we can evolve it ourselves, 
or fork it if we need to.

>That's when I step in with other incentives.  I say,
>"John, give it to me by dd/mm/yyyy and I'll give you
>a dollar."  
But Chris, I may find that the date you set is not reasonable,
or the dollar[s] you give me are not adequate incentive for me
to put in the extra (over 40 hr/week) effort required to make 
that date. In either case (which is common), you LOSE. 


>Now, we have market forces.  Now, it is
>going to be managed like a business.  You see?
Like you motivated me as above? NO SIR! That is NOT how a REAL
BUSINESS manages it's people, particularly not intellectual workers.

>Deadlines are important.
Please substantiate this claim.

>Market forces do come into play.
Of course they do! I have yet to see you put the pieces together.

>Right now, John's incentive is to beat Microsoft.
This is either easy or a fools errand, depending on what it is.

>For non-OS projects, John's incentive maybe to make a
>name for himself.  But, eventually, he's going to have
>to put caviar on the table.  The Open Source world may
>be a spring board that gets him there, but suddenly,
>he won't be in it any more.  Well, not like he was.
"Making a name for yourself" gets more and more important. In the last 16
years, EVERY bit of income I have made came from assignments where my rep-
utation paved the way for me. Things like resume submissions and so on were
largely formalities.

>>>The Open Source model works because there is a David
>>>and Goliath competition going on.
>>This is true, but your thinking of Microsoft as the David
>>seems somewhat at odds with some of the other statements
>>in what you've written. Can you explain?

>>You see, Microsoft is David, since they do not marshal the
>>resources or the effort required to create a really reliable
>>OS. The number and mean skill level of the people who are
>>working on the Linux system simply have them beat, and the
>>Linux team simply cares more. The Linux Goliath does scale
>>quite well, however.

>Microsoft is Goliath.  The big, ranting giant that
>everyone fears to go up against.  It has nothing to do
>with resources.  Goliath's tool was Fear.  When it came
>to hard knocks, he lost.

Oh, I'm pleased that you explained your metaphor so that even
I would be clear about it! :)


David is driven by a need to prove that his way is
better.  Once Goliath is out of the way, David's way is
immediately suspect.

>You see, if the Philistine army had not turned and run, but rushed upon
>David like a pack of wolves, how long do you think David would have
>lasted with his four remaining stones?
I have no idea, Chris, there are a lot of variables there, like the
stoutness of heart of the army, the composition of those stones, and the
courage of the Israelites behind David, to name just three. Maybe I'll 
build a computer model of this situation, but please don't ask me for a
delivery date. I'll let you know when it's ready, though.

The ethos at the time was that when you felled the greatest warrior, all
others would fall before you. My point in reversing your metaphor was in
showing that there are many ways to think about these things, and that
the metaphor is a bit too simplistic, at least for my taste.

>I say that the market forces are far less fearful than the Philistines.
Well, you haven't met a lotta Philistines! :)

>Open Source may be a nice tool for felling a giant, but I'm not so sure
>it's a viable model in the long run.
Well, David went on to become quite an effective King, and even though he
made some mistakes, he was better than many monarchs of the time. I feel
that ALL of the business models we see that survive some fairly basic time
tests have a place in the life cycle of software. The fact is that the
business models that support the free UNIX systems have had quite a run so
far, and there isn't a lot of reason to think they are going to become non-
viable in the future. 

>>>In a more level playing field, where smaller companies are
>>>competing for smaller pieces of the market,...
>>Ah, is this the kind of environment that might exist without
>>monopoly power, such as what Microsoft was convicted of wielding?
>>I'd like to see a world like this, where everyone used the same
>>standards and competed on merit instead of hype, FUD, and
>>misdirection....
>Yes, and you may yet see it.
Good! I hope so! In such a world, the best products will become apparent.

>But, I wonder, who makes and holds the standards?
The computer industry as a whole, via ISO. For networking, the IETF has
been functioning as the body proposing most protocols to ISO for world-
wide recognition.

>Does this person also control the market?  This is probably another thread.
No, and no. The answer is actually quite simple; ISO is in essence a
regulatory body, indirectly an extension of the UN. I certainly agree that 
we need worldwide standards for many things in the computer industry. For
many of these bodies and consortia (like the X consortium, the CORBA
folks, and so on), there is ONE large organization that has consistently 
absented itself from this process (can you guess who?), but the rest of 
the industry pretty much agrees on the above groups as a vehicle for get-
ting standards everyone can use.

>>>it's not as clear that this laid-back approach to deadlines
>>>would work.
>>What "laid back" approach are you referring to? No one made any
>>commitment to a release date for the Linux kernel; no one had
>>to.
>I think you answered your own question.  A "laid back"
>approach is one where there are no commitments to
>deadlines, the customer, self, or anyone.
Ah, so you think that without being pressured, software developers will
sit back in their lounge chairs, pop bon-bons, and watch Bonanza reruns?
No way! These are called RETIRED software developers. Anyone I know and
respect in this business are very highly motivated self-starters. They 
don't wait (or have to be held back) on posed problems; they attack them!

>>Software "engineering" is still largely craft, and it is very
>>very hard to place deadlines on the successful outcome of proto-
>>typical craft, in any industry. The people who are at or near the
>>top of the Linux kernel effort (and other Free Software projects)
>>know better than to commit to a needless deadline.
>I agree with you.  And the technology sector is rife
>with products that have been prematurely released
>because of arbitrary deadlines.

>But, if there are no deadlines, then there is no race.
Nonsense! This is equivalent to saying that if there is no management,
there can be no progress. Deadlines are a simply a way of expressing
the time-frame in which a desired goal must be reached in order to 
achieve more general goals.

The "race" you speak of is not motivated by deadlines, but by developments
in other areas. For example, when a new microprocessor is released, there 
is an implicit "race" to exploit its potential. We don't need deadlines
and a lot of press hype to understand that the first OS (for example) that
exploits the new chip is a gainer, and the others may very well be losers.
Developers working on this (for the joy of it, or for free) don't need to
be told that there's a race on, one is.

>There is no competition.  If there is no competition, technology
>will stagnate.  
See above, and reconsider. The fact is that technology is extended by a
large number of disjoint teams, all working for their own motivations,
and in their own styles. 

>[Promising arbitrary deadlines is a]
>>characteristic defect of companies that fear the marketplace, and will
>>promise anything to keep an audience. Mature workers understand that
>>quality delivery takes time, and the notion that a product is ready
>>ONLY when the product developers say so is a vital part of maintaining
>>the integrity of a product and it's place in the market.
>Modified development processes can speed time to delivery.
Please tell me what a "Modified development process" is. Once I know, I'll
decide if I'm in favor of it, or not.

>If there is no driving deadline, then there is no need to modify or streamline
>development processes.  Ultimately, this leads to slower development times.  
Perhaps I don't like the term "deadline"; it has such finality, the
implication that something will happen if it's violated when, in reality,
nothing usually does happen. It also carries the air of inflexibility,
often unrealistically so. I happen to prefer the term "goal", and of
course, the most effective goals are ones that carry a fairly clear
incentive.

The other thing that I have noticed is that any deadline, if sufficiently
unrealistic, is simply ignored by everyone after a while. The Win2k
release is a good example of this, as was a release of Lotus-123 in the
late 1980's. In both cases, developers inside the organization simply
stopped taking the published dates seriously, and whatever that did, it
didn't help progress any.

One organization I was with set goals for technology projects by consensus
among project leaders, and there were incentives for delivering early, and 
penalties for delivering late (generally year-end-bonus factors), and
everyone knew what they were. These goals were subject to revision on a 
periodic and timely basis, and project leaders were judged on the accuracy
of their goal-making. I have always believed this was a very effective
system, since it required everyone to be accountable, and it kept the 
tension you claim for deadlines, while preserving a sense of reality
through bottom-up consultation on technical problems.

>What the original article points out is that if you have a dictator
>running the show, one who ignores market forces, development slows.
There's a big difference between "ignoring market forces" and making
the choice that product quality, reliability, and stability are simply
more important at a given moment. If you read Linus' posting announcing
2.4.0, you'll see that he felt that the kernel had reached a point where
the balance had been tipped in favor of market forces, and against further
refinement.
                                                        Regards,
                                                         ---> RGB <---