cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Back from Germany
Date Fri, 01 Nov 2002 15:06:31 GMT
>> 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.  
> Hmmm, have you ever read some of thouse random thoughs flying around? 
> Several times I had ideas but they were foggy and the community helped 
> clearing up the fog. I think this is part of the brainstorming that 
> helps collaborative design.

Yes, and I'm still advocating the brainstorming.  What I'm suggesting is
that only one person can really "design" something.  

> Sure, I agree with you that there must be some 'leadership', in sense of 
> 'leading the effort' (not ruling it), but I think it *IS* possible to 
> design architectures in the open and I think the value of Cocoon proves 
> this pretty evidently.

If I was to ask a random Cocoon developer to tell me the architecture of
Cocoon I'm not sure I could get a coherent picture.  There's a lot of pieces
to Cocoon, many of them overlap and some run counter to each other.  As
such, it's not clear that Cocoon currently has a complete architecture (some
of that seems due to V1 compatibility issues).  Certainly the work that you
are doing now seems to be helping to rectify that.  

I guess as the counter example to what you are suggesting I would point at
the Linux effort.  There, it's pretty clear where the overall architectural
direction is coming from and there is a lot of strategy discussion on what
the long term architectural goals are.  Pieces of that strategy come from
many people, but one person (more or less) coordinates the effort.

>> 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.
> These are the stages we have been using so far
>  - random thoughts
>  - proposal
>  - discussion
>  - implementation
>  - test
> and only 'proposal' is a single-person effort.

I guess what I would changes is that I would add  "architecture", "more
discussion" and "design" steps between discussion and implementation, and
architecture and design would also be single person efforts.  Not for
everything, but for the large pieces.  

I think that you are doing this to some extent, but I think it would help to
make it explicit.  The big thing that seems to be missing is the
documentation that would fall out of the architecture and design pieces.
Even if it's not complete it at least gives a framework into which the
overall documentation can be pieced together.

>> 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)...
> No, I think Cocoon proves that open development can be a killer way to 
> do both research and development and, if run correctly, is not an ideal 
> but a practical solution.

Again, I'm not so sure.  If Cocoon goes to the Apache level you're going to
see a lot more people jump into the developer boat.  The number of people
wanting to add functionally it is going to increase by an order of
magnitude.  Someone has to work to stop Cocoon from becoming a bloated
collection of random functionality. 

Adding blocks will help keep things organized, but now, people will look at
the default configuration and think "hmm, I would like to also have this
function" and throw something out, not realizing that it is already
implemented (perhaps in a completely different way than they imagined) in
some other block.  I'd really like to see people such as yourself try and
keep a firm control of the overall architecture.  I guess that also implies
going to the effort of documenting it, and I can understand why that might
not be as attractive of option as having the "list" (so to speak) be the
documentation... ;-) 

Just in case I haven't made it explicit, I do admire the work that you and
all the rest of the Cocoon developers have done to date.  I also believe you
haven't seen anything yet in the terms of the size the Cocoon community
could grow to.  There's a fine line between collaboration and anarchy and
someone, such as yourself, is going to have to help keep watch over the

To unsubscribe, e-mail:
For additional commands, email:

View raw message