incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Proposal for Lenya
Date Thu, 20 Feb 2003 17:11:05 GMT
Steven Noels wrote:
> Michael Wechner wrote:
>> Dear Incubator List
>> Here's our proposal for _Lenya_ (plz see below), a Content Management 
>> System based on Cocoon. The proposal can also be viewed as HTML at:
> [cc'ed to cocoon-dev where Cocoon PMC lives, which will ultimatelly 
> decide whether Lenya can become a Cocoon sub-project - read 
> for background info]
> Some remarks and initial thoughts, mostly based on [BT] (belly 
> thoughts), so please don't take too serious or feel offended:
> * IMHO, the ASF as a whole has a focus on generic 'lower-level' 
> frameworks created to build a variety of applications or serve as a 
> deployment container. I've been 'quite interested' (= understatement) in 
> CMS frameworks for a long time already, but find it a domain where _one_ 
> design doesn't necessarily fit _many_ use cases. I'm not saying the 
> meta-generic framework which will address all use cases exists (or could 
> be created), I'm just afraid the early design of Lenya might be based on 
> a set of assumptions which will be hard to reverse/refactor when fresh 
> blood comes into the project and new ideas arise. When I see 
> "disentangle cms & publications", I get worried.

I agree with your general assumption that a content management system is 
pure marketing bullshit since there is no one size that fits all.

In fact, in my personal view, Lenya is an effort to build a community 
around the various problems of content management and that will probably 
generate a "Content Management Framework" rather than a 
ready-to-be-deployed solution.

Things like workflows, repository integration, integration with 
semi-structured editors will probably be components (cocoon blocks?)

> * A sh*tload of (even Cocoon-based) (half-baked) CMS solutions exist 
> already, which might or might not be willing to join ASF in the future. 
> What will happen if Lenya (nice name BTW) comes and claims that area? 

"claims that area"? how can it possibly happen? Apache is not something 
that you go and homestead. Here we are talking about incubating a 
community around problems that affict many people (and you as well).

If you have a better proposal or codebase to start from, I'm happy to 
hear about it.

> Will it be the reference ASF CMS tool?

There is no *reference* anything inside apache. It's software darwinism, 
the community success decides what lives and what not. Tomcat might be 
the 'official' servlet engine, yet Cocoon ships Jetty and everybody is 
happier than ever.

The system works, it's adaptive, impartial and meritocratic.

> Can CMS be considered an area 
> where the ASF wants to operate in, like Zope (CMF) is...?

The ASF is for the evolution of web technologies. Would you state that 
making structured content production and management easier is a goal the 
ASF shouldn't deal with?

> Or do we stick 
> to supporting technology like servlet containers, http stacks, build 
> tools ... I know there is no policy at ASF that states only one CMS 
> project can exist under the ASF umbrella, but still there is only one 
> JetSpeed, one Tomcat, one Cocoon, etc etc - I hope my point is clear.

It's clear that you don't understand what we are trying to do.

We don't want to *homestead* the CMS niche of the ASF (whatever that 
means in OSS terms!), we want to build a community that will focus on 
serious content management and, so far, there is no such community in 
the ASF since Slide is repository-oriented (no publishing nor editing 
layer) and Forrest is publishing-oriented (no repository nor editing layer).

We believe that the best architecture for CMS is the one described by 
Lenya where there is a clear separation between 'content editing', 
'content repository' and 'content publishing', all of them left as 
'framework' for developers to build customized CMS services upon.

We have most of the technology we need, we just need a community with a 
more detailed focus on these problems and so far the ASf doesn't have it.

> * from what I read here [], there 
> is extensive refactoring planned _before_ reaching 1.0, yet this is 
> envisioned to be done as an incubating ASF (Cocoon sub-) project. I am 
> wondering whether it wouldn't be better if this high-impact stuff is 
> done before being moved to Apache (it also sounds a bit like the Lenya 
> people take the move to ASF as a given, which might perhaps be a bit too 
> premature).

This is a good point.

At the same time, I'd love to see refactoring done *after* entering 
apache because that would allow the community to steer the project 
before it's carved in stone (as it happened for xindice and it's now 
much harder to refactor)

> * reviewing the archived commit messages, I wonder whether the proposed 
> list of initial committers reflects reality, or that the list has been 
> expanded so that we won't have the suspicion it is mainly one 
> company/group working on the codebase (as is the case with 
> right now).

Wow, that's very close to be insulting, Steven. Careful.

Anyway, I agree that the wyona community is not very diverse, yet, if 
Wyona had a successful and diverse community, we wouldn't pass thru

But I wouldn't say "expanded" since all the people listed *did* in fact, 
work on the codebase and are interested in keep an eye on it (which is 
as good as you can get these days), the incubation stage will decide 
what happen.

> * Xopus has recently had some troubles w.r.t. its licensing policy 
> (open, not open, etc...) Are these things effectively solved right now? 

q42 has troubles understanding the oss business model. we are helping 
them privately. so far with very positive responses and some friction 
points we are trying to solve.

> What part of Xopus will be inside Lenya CVS?

None. If we reach an agreement with q42, Xopus will be submitted as 
another incubation proposal, apache licensed and they will be part of 
the community.

In any case, lenya will keep the editing layer totally separated, yet 
design the proper hooks for them.

> As I said, these are 'just remarks'. The fact I'm posting them means I 
> actually care about this proposal, in a positive sense.

Hopefully my comments give you more insights.

Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

View raw message