Antonio: I'm impressed me by your candor and sense of community. Your comments are absolutely relevant.
I agree.
It has taken me years to understand why and how open source is more than just code and technology. I tended to think stricly in terms of genericity, elegance, or economy of terms. The notion that <<bad code and good ideas create communities>> was alien to me. Paraphrasing the Matrix Architect, I found it unacceptable to release what appeared to me as incomplete or imperfect code "for what was otherwise a harmony of mathematical precision." Uff! Definitely, worse is better.
XP design goals are derived from a mixture of corporate repeatability and observations of many open source projects. The key is that it is better to have something working now, and make it better over time than it is to polish it to perfection only to find that the software completely misses the mark. The mark is usability--will this software be used, and does it fit the current need. By allowing a release-early-release-often internal development cycle, we can adapt to changing needs as we move on.
IOW, XP embraces change and resists rigidity. This is a good thing.
The "ugly, non-sense" discussions mentioned by Antonio are generally characterized by over-focusing on technical arguments in disregard for community goals. I dislike harsh language and irony, but in this one case I agree with the "balkanization" part of this thread's title. Should we make core abstractions pluggable just because it's possible, even if it can confuse users and fragment the community? The �ber-Avalon syndrome? Definitely, less is more.
Ok, now I have to say something about this negative Avalon image. It is not Avalon's fault that Cocoon has overused modularity. Avalon is a tool, much like anything else, tools often get misused. If you use a flat-head screwdriver to open a paint can, is it the screwdriver manufacturer's fault if the screwdriver slips and cuts your hand? No. The tool was misused.
That said, Avalon and COP in general provides tools to try new evolutionary paths and revert quickly and easily. In that sense you have some incredible flexibility at your disposal to attempt different abstractions and merge things that should be merged and separate things that should be separated-- all without throwing away the underlying work that has been done.
Consider the Facade pattern (AKA the bridge pattern, the adapter pattern, etc. etc. etc.). It is trivial to create a new component interface that overlaps one or two existing concerns, and an implementation that demonstrates how those concerns (and components) are to be encapsulated. When you are done fiddling with the interface, you can then begin the process of migrating. THe cool thing is that the adapter allows your existing components under the old interface to continue working as they always have.
Now with such a powerful tool, should we over-use it and split up the community over several implementations? Probably not. However, until you "show me the money" (for the movie buffs) most ideas will be rejected. What is the answer? My suggestion is to provide one abstraction and allow work to move forward on roughly three solutions. If one of the evolutionary branches dies due to lack of interest, then you have eliminated one of the approaches because it doesn't solve people's needs. If there are two remaining that seem to have equal mind- share, then we can look at merging them together borrowing the strengths of each one.
Is *ALL* abstraction bad? Absolutely not. Good abstractions help us understand the system better. Bad abstractions make things less clear. Use this rule of thumb.
The community needs to agree on what is the *core* functionality. That does not mean that alternatives cannot exist--but they should not be positioned as a core part of Avalon or something that might one day replace the core functionality of Avalon. It is a plugin, an alternative. I believe that this is the major point that Stefano would like to make. We agree on the _one_ _official_ way instead of fragmenting the core of Cocoon.
Eventually, Cocoon will find the happy medium between over-componentization (which IMO is where it is now) and rigidity. In my experience, you need to find the proper balance for contracts. They should be strict enough to provide predictability and interoperability, but lax enough to allow for widely variant implementations. You also need to find the proper places where rigid contracts make sense, and where they don't.
That takes time.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin