Hunsberger, Peter wrote:
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 :Yes, and I'm still advocating the brainstorming. What I'm suggesting isMy real point is that I think that it's really hard forHmmm, 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.
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.
that only one person can really "design" something.
- 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).
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 ;-)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.
I guess what I would changes is that I would add "architecture", "moreAs 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.
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.
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.Again, I'm not so sure. If Cocoon goes to the Apache level you're going toOpen development sounds like a nice ideal, but perhaps it might be more effective to work for benign dictator led development (with theNo, 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.
understanding that at any point there may be a revolution that gets rid of the dictator)...
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.
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 impliesDictatorship 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.
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.
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
