Steven Noels wrote:
On 06 Dec 2005, at 12:04, Sylvain Wallez wrote:
Steven Noels wrote:
On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
Struts has Shale
Meeep. Buzzzz. Wrong.
Struts has Craig.
And Tapestry has Howard and Spring has Rod. What do you mean?
I meant to say that Struts is a bad example since it has a benevolent,
dedicated person that is cheered upon by a league of grateful
groupies, who will follow him anywhere (up to their own imagination's
limits). Ditto with Tapestry and Spring and RoR. With Cocoon, there's
as much direction as there's developers, and users even: it's big and
bloated and lacks direction. And I honestly believe it's the community
and consensus tax which make it virtually impossible to create such a
unified direction. So so far, I believe we're about to say the same
thing, except that I'm pessimistic (as usual).
Ok. Got it. Also, after hitting "send", I realized that I should have
added "and Daisy has Bruno".
But you sniped away what I really meant to say, actually. That blocks
and interfaces, however they come to into existence, are needed - not
only for technical but mostly for community reasons: to provide
non-community-shepherded code with its own release and life cycle. To
provide users with something they can rely upon. Not the next cool
thing down the road, or an experimentation platform for non-enduring
geeks. Or a code graveyard for a bunch of consultants.
I wholeheartedly agree. The purpose of layering Cocoon is about ensuring
strength of contracts. Someone that knows a piece of software inside out
doesn't need contracts. But others do.
This is the well-known architecture of participation ([1] -- funny to
see who's quoted) that says that successful communities keep a center
cathedral around which the bazaar can develop. Lately, Cocoon has failed
to maintain this cathedral which has been slowly invaded by the bazaar.
Defining contracts in separate modules, and defending them fiercely
through human oversight and automated tools is a way to help the very
decentralized Cocoon community to preserve the central cathedral. The
document I added to Daisy has a chapter dedicated do development rules,
which is new here.
I fail to see how giving something fancy names will change that model.
Fancy names are meant to show that something different is going on.
Technically different, but also more importantly culturally different.
And that last point is certainly a more difficult change. Some will like
it, others won't.
So consequentially, maybe it's the community that needs to change.
It a least must change the way it handles what it produces and how it
behaves.
I'm surprised to finally see evidence of an anti-OSGI camp in Cocoon.
Not that this surprises me, but it's just sad that this hasn't been
clarified much earlier.
It's not an anti-OSGi camp, but a "are blocks really the solution?"
camp. OSGi was brought to the picture because no one could agree on the
kernel/container to use. So we fetched a great ready-made container outside.
That damned community tax again, I guess. Waste of time and energy for
everyone.
Maybe. But that community also has been able to produce many great
things. Let's try to build this cathedral so that the community bazaar
can builds even greater things around it.
Sylvain
[1] http://weblogs.oreilly.com/lpt/wlg/3017
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
