cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: Back from Germany
Date Thu, 31 Oct 2002 16:16:50 GMT
>> 
>> I've been calling this way of doing software "open development" since 
>> "open source" refers to the distribution of software, not the way the 
>> development community is run.
>> 
>> I don't want anybody (so myself included) to do anything behind the back 
>>   of anybody. Nor to make it appear that when (unfortunately rarely) 
>> people get together in real life to talk, this appears as doing hidden 
>> things or secret plans.
>> 
> I must confess that perhaps my email, telling that I discussed blocks
> with Stefano, had exactly the message that we two are doing something
> behind the back of the community. But believe me, this is not the case!
> I totally agree with Stefano that "open development" is the way to go,
> otherwise sooner or later we would create friction in the community.

<pontification mode="ramble">

Oh boy, I don't want to start a religious war or anything, but it's been my
experience that a broad community/collaborative process rarely results in
good software design. (PLEASE NOTE; I am NOT saying that the open source
process doesn't produce good software!)  The difficulty in doing good design
by committee could be perceived as a problem for the open source community
but I think the way to proceed is to put some trust in the people doing the
architecture and design and allow them to proceed somewhat privately.  For
*large* scale changes and concepts, I basically think the cycle should run
as follows:

1) Someone has an idea and explains the basic concept to the community and
gets feedback on the idea.  Essentially at this point you gather
requirements for a conceptual architecture.

2) If the idea has a positive response the same individual formalizes the
conceptual architecture and posts it for feedback. Now we are getting
requirements/use-case for a logical architecture.  There may be prototype
mockups, but if so it is expected that it will most likely be thrown away.

3) If the idea continues to move forward the individual formalizes the
logical architecture.  At this point you have class relationships, process
flow, entity relationships, or whatever design models you want to use.  You
have not yet specified an implementation (though you probably have one in
mind).  This design is again posted for comments.  Again, there may be a
prototype, it may or may not have a longer life past this point.

4) If the idea continues to move forward you formalize a physical
architecture and/or a high level design spec. Again this is floated to the
community for comments.  When this stage is done you should have a pretty
solid API spec and the documentation produced up to this point should be
enough to form the basis for pretty good developer documentation.  It should
be possible to take any prototype that makes it through this stage on to
alpha and beta stages if one wishes to spend the time doing so.

It is possible that any one of the above steps could be repeated several
times.  In the interests of time some of the steps might not really be fully
fleshed out (remember software development metrics show that best efficiency
is achieved when 1/3 of the time is spent on each of design, develop and
test). Better would be to at least do each step in private, even if it is
not fully presented to the general public. If you're going to skip a step it
would probably be step 3, perhaps presenting some of it with step 2 and some
with step 4. It also makes sense that the person doing any one of these
steps might privately gather feedback and input on the documentation being
produced at each point. What I don't think should happen is that a dozen
people openly discuss on public mailing lists a design.

I don't think that any of this is really any different than what is
happening today.  My real point is that I think that it's really hard for
multiple people to write an architecture together.  I trust that anyone
proposing a major change to an architecture is experienced enough or smart
enough to know how to get to the end point.  As such, I trust Carsten,
Stefano and whom-ever to figure most of this stuff out without necessarily
involving the general Cocoon developer community at each point that there is
some design decision to be made.

Open development sounds like a nice ideal, but perhaps it might be more
effective to work for benign dictator led development (with the
understanding that at any point there may be a revolution that gets rid of
the dictator)...

</pontification>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message