Jim Starkey wrote:

>
>Claudio Valderrama C. wrote:
> ...
>>> 2. An individual produce a design. Or maybe two or three
>>> individual produce independent designs. I don't like design by
>>>committee
>>>
>>>
>>Doesn't this model fit a private corporation more than an open source
>>project? It assumes one or two gifted people are the ones with the

exclusive

>>right to show the path to the rest. Also, if we agree to your vision,

then I

>>see nothing bad with people doing a prospective implementation of

something

>>and then offering it to the project, as Alex did some days ago in devel.

I already followed many sucessful Open Source projects and know quite well
the history of many others (especially at Apacha but not only). NONE was
designed by committee.

And there are many successful projects that get bloated and fade away when
the core (usually no more than 3) group of developers moves away or loses
interest on the project just because, without the consistency and
enforcement
of their vision, too many people start applying to many different and
dissonant
features to the project's product. Then the product gets bloated and common
interest on it often fades away.

On my experience with many Open Source projects and only a few large
companies, I am sure that design by committee heppens much more often on
the large companies.

>There is a huge problem when somebody presented something he or she has
>already implemented. The issue becomes protecting an investment in code
>rather than ideas. Ideas are cheap; implementation is expensive.

Still, that is also quite common on Open Source. In Apache that is called a
Revolution at least since the current generation of Jakarta-Tomcat servlet
containers was presented by Craig McClanahan as "Catalina". Catalina
probably used many bits of code from the main branch but its structure
was rebuilt from scratch by Craig.

Of course that Revolutions are always a big risk: some times the community
supports them and sometimes they don't.

>Another way to look at it is that it is *always* better to take the risk
>up front. In any project, open source or (think carefully, Jim), uh,
>other, the biggest risk is that you've overlooked a problem or a
>potential shortcut. Discovering that after the fact makes everyone one
>-- implementor, critic, and maintainer -- unhappy in the short, medium,
>and long term.
>
>Talk is cheap and email is free.

I couldn't agree more about the cost issues.

>>> 3. Prospective designs are weighed against the requirements. This
>>> often leads to a restatement of the requirements and an
>>> iteration (this is a very good thing). Problems are found,
>>> imaginations are kick-started, alternatives proposed.
>>>
>>>
>>This is a luxury for an open source project. The marketing dept at a
>>commercial entity won't allow this to go further, as the number of
>>iterations may be big.
>>
>Marketing at Interbase reported to me.

It is no luxury. It is always much cheaper to agree on a design and them
implement it than to go on trough trial and error.

And the end product too is almost always much cleaner and consistent
when following the "design first" approach.

Jim's is not a very productive example, since it does not apply here. But
I have seen designs often being discussed a long time before action is
taken and the process often works quite well.

When a group of people is well tuned to the same mind frame, very
complex and sophisticated designs can be produced by a group even if
they only cooperate via email.

But it helps a lot when they believe in the same design principles, which
is what I miss here.

>DEC developed a low end graphic terminal called GIGI. Among a number of
>serious problems, the microcode didn't implement Vt100 split screen
>scrolling, so it couldn't run the VMS EDT editor. I argued with the
>project manager long and hard that if it couldn't run the editor, it was
>useless. He said it would take 6 months to remask the ROMs and they
>would lose $6,000,000 in sales. They made a couple of hundred thousand
>and sold maybe a hundred. The computer museum got the rest.
>
>It is better to get it right than to get it wrong sooner.

Although Open Source project do not have a price, they still have a cost
of adoption and rejection happens just the same way.

>>This is where heat is produced, but we can't change the second law on
>>thermodynamics... ultimately everything degenerates into heat amd

heat flows

>>trying to produce an uniform, inert state. This explains also why some
>>proposals stall.
>>
>There more inertial in Firebird than any place I have ever worked. Ann
>and I talk constantly about the sociology of open source. I haven't a
>clue. I am bewildered at my dual role as inventory and chief enemy of
>pools.

The basis of the sociology of an Open Source project is quite simple:
EVERYBODY IS SCRATCHING HIS OWN ITCH.

If enough people have the same itch it works. Sometimes you can even
induce the same itch on enough other people. Sometimes you just gather
enough people with the same itch to fork into another project.

In the end, Open Source is all about a selfish interest achieved trough
cooperation, just as so many other human activities.

And I have seen much WORSE inertia: the now EXTINCT Avalon
project.
http://avalon.apache.org/closed.html

But please notice that it was closed!

Actually it forked in a few projects listed on tha above web page. Sometimes
that is the only way to stop inertia.


Have fun,
Paulo Gaspar