cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Back from Germany
Date Sat, 02 Nov 2002 20:52:03 GMT
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 strongly disagree with this : although there must be a design leader, 
discussing it in the open is key to a strong design. I've been doing it 
in my work for years, and found several points that make it really 
efficient :
- the designer may have chosen a wrong way, or made wrong initial 
assumptions,
- gathering ideas from several people ensures that several points of 
view have been taken into account and that the designer didn't missed 
something important,
- designers often have an abstract way of thinking. Discussing the 
design in the open ensures it can be understood by other people, and 
those people are often the ones what will have to use and live with this 
design for a long time.

And last, but not least, open design strengthens the community : 
exchanging ideas helps people to better know each other (especially 
important if we don't kwow each other IRL), and there is a lot to learn 
by simply watching the process that leads to a strong architecture.

Open design is IMO one of the reasons the Cocoon architecture is so 
strong (other reasons are great minds like Stefano, and the Avalon 
framework).

But open design doesn't mean low signal/noise ratio, as most often, only 
people that have good reasons to speak participate in the discussion. At 
least this is what happens on cocoon-dev.

What we also see is the design leader changes with the thing to be 
designed. Yes, Stefano is often the leader for high-level Cocoon 
architecture and new features, but there are many lower-level design 
discussions that are led by people that had the initial idea and want to 
push it because they think it is good (e.g. flowscript, modules, forms 
handling, tree processor, etc).

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

Mmmh... I can't speak for Stefano, but I can tell you by personal 
experience that being a good architect doesn't imply being a good 
documentation writer, nor that an architect has the same motivation for 
architecting than for writing docs ;-)

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

Look at cocoon-apps : this was set up when we realized that Cocoon's CVS 
repository contained specialized applications and not only 
general-purpose components. No dictatorship, but a place where people 
can place their work. And if these apps contain general-purpose 
components, the door is open for them to be integrated in the core.

Also, remember that committers are "filtering" what comes in : some 
contributions are rejected because they're either duplicate with 
existing features or don't fit with in the 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
>masses.
>  
>

Dictatorship isn't IMO a good way to manage a lot of newcomers, as they 
will simply go away if a single person pisses them off when they propose 
something.

Manageability of a large group comes with segmentation. When we will see 
a lot of posts on cocoon-dev whose subject is prefixed with a [theme], 
then we will ask ourselves if it's time for a separate mailing-list for 
the [theme]. Not everybody is interested in the same parts of Cocoon, 
and forming different discussion areas is the way to ensure efficiency. 
But not dictatorship.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



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


Mime
View raw message