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

["R. George Brown" <bob@xxxxxxx>]

>... I'd like to see your explanations as to why Linux is NOT being run
>like a large monolithic organization.  
The short answer is "Because it doesn't need to fall into that trap",
but I suspect that while this is correct, it is not the answer you're
really looking for. Actually, I think the question you've asked isn't
quite the "right" one, in the sense that if answered,  will not reveal
what you really want to know. With that rather arrogant assertion, I'll
answer a slightly different question, and by way of doing so, provide a
bit of background.

ALL large organizations face several challenges which vary with size,
number of interacting employees, and complexity of mission. A traditional
hierarchic organization hits real limits on productivity as each of the
above factors grow. How these factors are handled (or ignored) will
greatly effect the productvity and net impact of each member of the
organization, and the over profitability of the group. If you have a team
of 4 programmers, for example, bringing a 5th person on board will NOT 
increase productivity by 20%... EVER, since some time is taken up by
group activities... nessessary  communication among team members, for
example. Eventually, the percentage increase in product flow is outweighed
by this overhead, at which point the ability of the group to support
additional members has vanished. Managers who do not realize this are
simply have unrealistically high expectations, and will continually
make mistakes in estimating projects and the effects of adding resources
to projects. Organizations that collectively don't understand these 
effects are very prone to serious error in these areas.

A great of this has been covered very well, and has been known for
decades, if people care to look. In particular, I'd like to point everyone
reading this to "The Mythical Man-Month" by Fred Brooks, who made many of
these observations nearly a half century ago and wrote about them at
length. I consider this book a "must read" for ANYONE who is interested in
discussing any aspect of workflow or project management in the software
business.

One of the influences behind a lot of group reorganizations is an effort
to get around the productivity limitations mentioned above, (and written
about better by Brooks). However, it may well be that the very nature of
the organizations goals, culture, or workstyle may impose limitations that
will be very difficult to overcome. This is one reason why a lot of these
efforts fail.

For several reasons, The "bazaar model" of workflow does NOT suffer from
the pitfalls waiting for any traditional hierarchic organization. First of
all, there are very few requirements for joining most of these organiza-
tions, which may be as much cultural byproduct as anything. Since many of
these projects are run over the Internet, largely via e-mail, people do
not need to relocate or commute, and they generally don't need to share
office space or working hours. Since the reporting relationship are loose
and the size of each team fairly small, a lot of communication is kept
rather local, and does not take up a lot of the time of participants, at
least not down in the trenches, where things tend to get coded. Since many
participants are there to pursue their own agendae, fairly little time is
spent politicking and concensus-building, and more time is spent cranking
out product, the merits of which are decided, mostly on merit, later on.
Also, less time is spent covering one's own derriere (aka "managing risk")
and more time and effort is focussed on producing good product.

I claim that the conventional business world has a good deal to learn from
this kind of project management and execution. That said, there are a lot
of aspects of these methods that may not survive transplantation to a
commercial environment. 


>Eric Raymond points out that the bazzar/Open Source 
>movement flourishes ....no standards...
Chris, please move off this notion that all this software is evolving with
no standards. Perhaps projects start without them (especially when the
whole project consists of 2, maybe 3 people), but as it grows in size and
importance, standards will inevitably emerge. The difference between these
standards and the sorts of standards that we see in conventional
organizations is that the members of the group have developed the
standards and perform the compliance work themselves, and the standard is
maintained and debated (and amended) as needed by project members. There
are no EXTERNAL standards imposed by the software police; the group is
self-policing. As the project yields a stable product, this aspect of the 
system will inevitably become a stronger factor in submitting patches and 
making changes, and are embodied in different forms, such as FAQs,
submission specifications, requirements for patches and bug reports, and
so on. 

It is easier, in this kind of organization, to object to standards that no
longer facilitate understanding, or hold back the project or it's
members. Other project members are a lot more receptive to changing the
standards than is true of many conventional organizations, where the
reasoning behind the adoption of particular standards is not subject to
the same kind of review.

More a bit later....

                                                       Regards,
                                                       ---> RGB <---