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 forI 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.
>>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.
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).
AsI 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)
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 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.
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.
All right. We might just be arguing on terminology here.
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.
I think that you are doing this to some extent, but I think it would help to make it explicit.
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 implementation.The big thing that seems to be missing is the documentation that would fall out of the architecture and design pieces.
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?Even if it's not complete it at least gives a framework into which the overall documentation can be pieced together.
You are not sure that open development can be a killer way to do both research and development if run correctly?>>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.
I hope so, yes.
The number of people
wanting to add functionally it is going to increase by an order of
magnitude.
Hopefully.
Someone has to work to stop Cocoon from becoming a bloatedThe 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)
collection of random functionality.
Adding blocks will help keep things organized, but now, people will look atFrom my side, I'll do everything I can *NOT* to do this :)
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.
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.
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.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... ;-)
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.
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.
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.
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 andYep, I agree. Hopefully we'll be able to scale better when cocoon will not only be modular inside but also from a usability perspective.
someone, such as yourself, is going to have to help keep watch over the masses.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
