cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject evolution [was Re: Back from Germany]
Date Fri, 01 Nov 2002 18:23:46 GMT
You touch important points, Peter, I'll try to answer them at my very best.

Hunsberger, Peter wrote:

> >>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.

I think I have been involved in 90% of the design of what is inside 
Cocoon (not talking about modules), but I don't think I could have done 
the same without this incredible community.

So, even if I pushed most of its design, was it me that designed cocoon 
or the community?

Since I know I wouldn't have been able to do it alone (Cocoon1 was done 
by myself alone and we saw where that went :), I think it's the entire 
dev community that did the cocoon design.

Sure, I did most of the leading effort and I did most of the anti-FS 
measurements, but I think many others learned to play the exact same role.

> >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.  

Hmmm, have you ever tried?

> There's a lot of pieces to Cocoon, many of them overlap and some run 
> counter to each other.

Really? like what? Yes, there is some amount of overlap, but I think 
this is natural in an architecture designed with a darwinistic 
metodology (as we do).

>   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 really can't resonate with your vision on this, but I respect it. May 
I ask you how long have you been experiencing how we do software design 
around here? (I'm not being ironic, just curious)

> 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.
I have never participated in any linux development or mail list where 
that development took place so I prefer not to talk about something I 
don't know.

> >>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.

All right. We might just be arguing on terminology here.

> I think that you are doing this to some extent, but I think it would 
> help to make it explicit.  

what do you want me to make more explicit? the process or the 
discussions? sorry, it's not clear and I don't want to get you wrong.

> The big thing that seems to be missing is the
> documentation that would fall out of the architecture and design pieces.

Holy cow. I remember spending several *days* writing these sum-up docs 
and sending them to the list. Yeah, some of them are still named [RT] to 
begin with, but they were later used as references for writing the 

> Even if it's not complete it at least gives a framework into which the
> overall documentation can be pieced together.

Hmmm, I don't think that linux has this architectural documentation (or 
at least, I never saw one) yet you seem to implying that linux' design 
model is better than cocoon's. Or am I misunderstanding you here?

> >>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.

You are not sure that open development can be a killer way to do both 
research and development if run correctly?

>   If Cocoon goes to the Apache level you're going to  see a lot more 
> people jump into the developer boat. 

I hope so, yes.

>  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. 

The developper community has already increased by roughly 1.5 orders of 
magnitude (from 1 to 40 people) and we managed to keep FS very low. 
(yes, there are still architectural issues, but not that many)

> 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.

 From my side, I'll do everything I can *NOT* to do this :)

Why? simple, I think this community is way smarter than I can possibly be.

My leadership role will be just that of 'coordinating' the effort and 
pushing in those circumstances where the energy gap to cross is maybe 
too high (the transition between reaction and sitemap was one, the 
caching was another one, the flow concept, now the blocks)

So, I'll push when things cannot happen by themselves and I expect all 
other developers to do the very same.

Overall, we'll try to apply the metric of SoC and anti-FS feelings to 
keep the overall architecture 'manageable' and in line with our 
colalborative taste for software design.

Will it be perfect? no, it can't be. But at least it will be 
'evolutionary healthy' and this is what really makes a difference when 
you have to survive out there.

>   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... ;-)

Any effort to take those emailed sum-up documents and tranform them into 
XML stuff that we can add to the documentation will be well accepted.

but keep in mind that if you are not able to do software design on a 
mail list, you won't be helpful for this project. Community autofiltering.

And I think this is a *great* feature, not a bug.

> 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.  

Yeah, hopefully so. That's why blocks will make it possible to 
parallelize development on top of cocoon completely, reducing the 
development pressure on top of the cocoon core.

For example, PHP has several hundred committers, but only a few of them 
work on the language engine, the others work on the libraries, API and such.

> There's a fine line between collaboration and anarchy and
> someone, such as yourself, is going to have to help keep watch over 
> the masses.

Yep, I agree. Hopefully we'll be able to scale better when cocoon will 
not only be modular inside but also from a usability perspective.

Stefano Mazzocchi                               <>

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

View raw message