Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

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 
http://www.wyona.org/lenya.html 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.

* 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? 
Will it be the reference ASF CMS tool? Can CMS be considered an area 
where the ASF wants to operate in, like Zope (CMF) is...? 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.

* from what I read here [http://www.wyona.org/roadmap.html#1.0], 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).

* 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 
xreporter.cocoondev.org right now).

* Xopus has recently had some troubles w.r.t. its licensing policy 
(open, not open, etc...) Are these things effectively solved right now? 
What part of Xopus will be inside Lenya CVS?

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

Best regards,

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Proposal for Lenya

[Michael Wechner <mi...@wyona.org>]

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 
> http://www.wyona.org/lenya.html for background info]
> 
> Some remarks and initial thoughts, mostly based on [BT] (belly 
> thoughts), so please don't take too serious or feel offended:

No problem, thanks for starting the discussion.

> 
> * 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.

What does worry you, or better how do read/interpret this sentence?

We mean by this sentence, that we currently have a directory called 
"pubs" where all the (sample) publications are located:

                    pubs
                      |
   ----------------------------------------------- ....
   |             |           |       |
computerworld  oscom       docs    unipublic      .....

and they are mounted "automatically" by */** ,where the first
star is the publication id (e.g. oscom).

The problem is that we have accumulated quite a lot of sample 
publications within this directory and they are all within one
CVS module.

So, all we like to do is to refactor the build process a little bit, 
such that you can declare your pubs path within build.properties for 
instance and that we don't have to ship all sample publications within
one CVS module, but rather have one or two (well maintained) sample 
publications within one CVS module and all the others within a 
scratchpad module for instance, or maybe provided by a third party.
Well, that's it for the moment.


Another reason to do it this way is that:
Let's say you like the publication oscom.org. This means you might 
download it from oscom.org, put it into the directory "pubs", change
the layout et voila you have a publication with the same information 
architecture, the same document types and the same content management
functionalities, but with your own layout.
And you just had to put it into the "pubs" directory

Well, that's one scenario. Another scenario is certainly that
somebody built a website based on Cocoon and wants to make it manageable
by Lenya. That's a bit harder. We have developed some strategies to do
that for instance by defining a Cocoon view "xhtml4lenya", but still 
it's much more work than by customizing an existing instance of a
certain publication type, which is based on the Lenya (framework resp. API).

So, to conclude, I think you could say,that Lenya itself is not a 
ready-to-deployed solution, but really a framework, which is extending 
and based on other frameworks (Cocoon, Slide, ...) (just as Stefano 
decribes it), but the publications can be (but don't have to) 
turn-key-solutions.

In the end you sell it to the customer as a CMS resp. a Box ;-)

> 
> * 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? 
> Will it be the reference ASF CMS tool? Can CMS be considered an area 
> where the ASF wants to operate in, like Zope (CMF) is...? 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.
> 
> * from what I read here [http://www.wyona.org/roadmap.html#1.0], 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

We are currently refactoring a lot of stuff to help developers jump 
start into Lenya (which means dead code removal, simplifying directory 
structures, etc.), but not to set/define a totally ego-centric direction.

Of course we have our ideas, but we really want that others are bringing 
in and are realising their fresh ideas.


  (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).

Please apologize if it sounds like that. But we really don't take it as 
given.


> 
> * 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 
> xreporter.cocoondev.org right now).

No, all of them (http://www.wyona.org/acknowledgements.html) really 
contributed and committed to the CMS, but it's true, that the most 
active committers are currently working at Wyona.

BTW: I just realized that the link to the mailing lists is outdated. The
correct one is http://wyona.org/cgi-bin/mailman/listinfo
(we just changed our mail server the day before yesterday)

The CMS project was never really owned by the company Wyona, but by the
non-profit organization wyona.org (under Swiss Law),which has very 
similar bylaws just as ASF. The reason was to guarantee that the project
is always Open Source and also to guarantee Open Development, no matter 
what could happen to the company Wyona.

Now, we made one mistake (beside others) and that is that we called the
project Wyona. At the very beginning I called it XPS (Extensible 
Publishing System), but the name XPS is registered by Hewlett-Packard 
(and others) and I also thought it was a too technical name. So we 
renamed it to Wyona CMS (I have to admit one reason was also 
cross-branding, just as we learned from Zope did vice versa. Their 
company name used to be Digital Creations).

So, I think the perception of many developers is/was that Wyona CMS is 
owned by the company Wyona, although that is not true
and I think some people didn't join just because of that perception.
But it's perfectly understandable.


> 
> * Xopus has recently had some troubles w.r.t. its licensing policy 
> (open, not open, etc...) Are these things effectively solved right now? 
> What part of Xopus will be inside Lenya CVS?

We are currently using Xopus2.0.0.0 and we will integrate Xopus2.0.0.8,
where both of them are under the Apache License.

It would certainly be great to have the newest version as OS, but it's 
hard to tell at the moment if that will happen.

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

I hope I was able to clarify your remarks/questions.

Thanks

Michael
> 
> Best regards,
> 
> </Steven>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Proposal for Lenya

[Robert Koberg <ro...@koberg.com>]

Good morning folks,

Will Lenya focus solely on 'massively scalable' project needs?

Is there any interest to have it deal with small, static (50-200 pages - not
including print friendlies) projects? If so, would it use something like
Forrest's site.xml?

I would defintitely be interested in following the project, but I personally
have no /current/ need for something focusing only on the 'massively scalable'
at the expense of flexibility for smaller projects.

best,
-Rob

p.s. congrats to the Wyona people for getting their project to this stage in the
Apache infrastructure!

> -----Original Message-----
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
> Sent: Monday, February 24, 2003 5:53 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Proposal for Lenya
>
>
> Stefano Mazzocchi wrote:
>
> >
> > Anybody else with comments, either positive or negative?
> >
>
> Just a few thoughts: I spent this morning browsing the Lenya code from
> CVS and so far I have mixed feelings about the project. Basically I'm
> unable to see an "architecture" in the whole codebase, it seems to me
> more a set of Cocoon components glued together around specific project
> needs than a real CMS framework.
>
> This said, Lenya can be a good starting point to talk about a CMS built
> upon Cocoon, even if I foresee major changes and challenges forthcoming.
> It seems to me anyway that the Wyona guys are more than open for
> discussing it and well aware that this Apache incubation might lead to
> something radically different to what they got until now, and this is
> good news.
>
> In short: they have a codebase, and they have a good community around
> it, so here is my (informal) +1 to this incubation, together with a
> personal commitment to follow closely this project and help wherever I can.
>
> Ciao,
>
> --
> Gianugo Rabellino
> Pro-netics s.r.l.
> http://www.pro-netics.com
>

Re: Proposal for Lenya

[Gianugo Rabellino <gi...@apache.org>]

Stefano Mazzocchi wrote:

> 
> Anybody else with comments, either positive or negative?
> 

Just a few thoughts: I spent this morning browsing the Lenya code from 
CVS and so far I have mixed feelings about the project. Basically I'm 
unable to see an "architecture" in the whole codebase, it seems to me 
more a set of Cocoon components glued together around specific project 
needs than a real CMS framework.

This said, Lenya can be a good starting point to talk about a CMS built 
upon Cocoon, even if I foresee major changes and challenges forthcoming. 
It seems to me anyway that the Wyona guys are more than open for 
discussing it and well aware that this Apache incubation might lead to 
something radically different to what they got until now, and this is 
good news.

In short: they have a codebase, and they have a good community around 
it, so here is my (informal) +1 to this incubation, together with a 
personal commitment to follow closely this project and help wherever I can.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com

Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

Michael Wechner wrote:

> And certainly any help is very welcome, especially on architecture, as 
> long as it doesn't kill us ;-)

We _don't_ want to kill the Lenya community. One of my criteria for 
leaving incubation and becoming a proper Cocoon subproject however would 
be a thriving community. This might be expedited by an attractive 
codebase with a sound architecture.

<aside>
   Gee - there's a certain sense of Ruby-ism in this reply. :-D
</aside>

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: Proposal for Lenya

[Michael Wechner <mi...@wyona.org>]

Nicola Ken Barozzi wrote:

>
> Gregor J. Rothfuss wrote, On 24/02/2003 22.16:
> ...
>
>> what is the next step for us, besides soliciting more comments on the
>> proposal?
>> i guess at some point there will be a vote in the cocoon pmc?
>
>
> If the project wants to be a subproject of the cocoon.apache.org 
> project it can just get a vote over there and we'll be happy to accept it.
> If instead it wants to ask to be standalone, it would be a bit more 
> difficult and the thing would solely reside on us (incubation).
>
> From my experience, I would encourage you to start as a Cocoon 
> subproject, 


I think we are very fine with Cocoon and we actually appreciate the 
pesky resp. benevolent remarks from Steven and Gianugo, because they 
make us think and help to start improving things.

And certainly any help is very welcome, especially on architecture, as 
long as it doesn't kill us ;-)

Thanks

Michael



> and ask to be a Top Level Project later. This will make it easier and 
> faster to get started and ease the burden of the incubation :-)
>
>

Re: Proposal for Lenya

["Gregor J. Rothfuss" <ro...@abstrakt.ch>]

>  From my experience, I would encourage you to start as a Cocoon
> subproject, and ask to be a Top Level Project later. This will make it
> easier and faster to get started and ease the burden of the incubation :-)

+1

it is a bit early for us to have top-level ambitions if i may say
so :)

we would be happy to be voted on on the cocoon list. could you start
the vote for us nicola?

thanks,

-gregor

--
Gregor J. Rothfuss   greg@abstrakt.ch  http://greg.abstrakt.ch

Re: Proposal for Lenya

[Nicola Ken Barozzi <ni...@apache.org>]

Gregor J. Rothfuss wrote, On 24/02/2003 22.16:
...
> what is the next step for us, besides soliciting more comments on the
> proposal?
> i guess at some point there will be a vote in the cocoon pmc?

If the project wants to be a subproject of the cocoon.apache.org project 
it can just get a vote over there and we'll be happy to accept it.
If instead it wants to ask to be standalone, it would be a bit more 
difficult and the thing would solely reside on us (incubation).

 From my experience, I would encourage you to start as a Cocoon 
subproject, and ask to be a Top Level Project later. This will make it 
easier and faster to get started and ease the burden of the incubation :-)


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Proposal for Lenya

["Gregor J. Rothfuss" <ro...@abstrakt.ch>]

> > Just a few thoughts: I spent this morning browsing the Lenya code from
> > CVS and so far I have mixed feelings about the project. Basically I'm
> > unable to see an "architecture" in the whole codebase, it seems to me
> > more a set of Cocoon components glued together around specific project
> > needs than a real CMS framework.
>
> +1, and a major worry to me ATM. My remark on the 'cms features being
> implemented per-publication' was aimed directly at this, and the more I
> look into the collection of sitemaps, the more I see some clean-sheet
> [RT]-ing would be a Good Thing.

we are aware of the fact that the sitemaps could use some cocoon TLC :)
that said, we have started to clean our house, and are certainly very
open to suggestions how this might be best done. i was talking with
michael in the office today, and we now believe that it may make more
sense to postpone this "sitemap cleanup" till after a move to apache
(im hoping we make the vote :).

we planned to submit a cleaned-up 1.0 to apache, but to be honest, the
1.0 label is more a "we are ok with it to go to apache now" rather than
a very specific milestone. therefore we have quite some leeway to
declare a 1.0.

one concrete example: we are looking for a clean way to provide default
functionality via the root sitemap, while still allowing for these
defaults to be overwritten by publications. our current approach is
less than ideal, and im sure there are better ways to do it.

> > This said, Lenya can be a good starting point to talk about a CMS built
> > upon Cocoon, even if I foresee major changes and challenges forthcoming.
> > It seems to me anyway that the Wyona guys are more than open for
> > discussing it and well aware that this Apache incubation might lead to
> > something radically different to what they got until now, and this is
> > good news.
>
> +1, they have already shown good spirit in answering my pesky (but
> benevolent) remarks.

heh :)

> > In short: they have a codebase, and they have a good community around
> > it, so here is my (informal) +1 to this incubation, together with a
> > personal commitment to follow closely this project and help wherever I
can.
>
> I'm glad to see you jump up as well.

what is the next step for us, besides soliciting more comments on the
proposal?
i guess at some point there will be a vote in the cocoon pmc?

-gregor

--
Gregor J. Rothfuss   greg@abstrakt.ch  http://greg.abstrakt.ch

Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

Gianugo Rabellino wrote:

> Stefano Mazzocchi wrote:
> 
>>
>> Anybody else with comments, either positive or negative?
>>
> 
> Just a few thoughts: I spent this morning browsing the Lenya code from
> CVS and so far I have mixed feelings about the project. Basically I'm
> unable to see an "architecture" in the whole codebase, it seems to me
> more a set of Cocoon components glued together around specific project
> needs than a real CMS framework.

+1, and a major worry to me ATM. My remark on the 'cms features being 
implemented per-publication' was aimed directly at this, and the more I 
look into the collection of sitemaps, the more I see some clean-sheet 
[RT]-ing would be a Good Thing.

> This said, Lenya can be a good starting point to talk about a CMS built
> upon Cocoon, even if I foresee major changes and challenges forthcoming.
> It seems to me anyway that the Wyona guys are more than open for
> discussing it and well aware that this Apache incubation might lead to
> something radically different to what they got until now, and this is
> good news.

+1, they have already shown good spirit in answering my pesky (but 
benevolent) remarks.

> In short: they have a codebase, and they have a good community around
> it, so here is my (informal) +1 to this incubation, together with a
> personal commitment to follow closely this project and help wherever I can.

I'm glad to see you jump up as well.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: Proposal for Lenya

[Gianugo Rabellino <gi...@apache.org>]

Stefano Mazzocchi wrote:

> 
> Anybody else with comments, either positive or negative?
> 

Just a few thoughts: I spent this morning browsing the Lenya code from
CVS and so far I have mixed feelings about the project. Basically I'm
unable to see an "architecture" in the whole codebase, it seems to me
more a set of Cocoon components glued together around specific project
needs than a real CMS framework.

This said, Lenya can be a good starting point to talk about a CMS built
upon Cocoon, even if I foresee major changes and challenges forthcoming.
It seems to me anyway that the Wyona guys are more than open for
discussing it and well aware that this Apache incubation might lead to
something radically different to what they got until now, and this is
good news.

In short: they have a codebase, and they have a good community around
it, so here is my (informal) +1 to this incubation, together with a
personal commitment to follow closely this project and help wherever I can.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com

Re: Proposal for Lenya

[Stefano Mazzocchi <st...@apache.org>]

Steven Noels wrote:

>> Well, I can't be sure either. This is why we are going thru 
>> incubation: it should be a period to estimate *IF* this codebase with 
>> these people is the right seed for a potential healthy community.
>>
>> If now, well, at least we tried.
> 
> Yeah. Since Incubation in itself is pretty new and finding its way to 
> operate, we might be living under the (wrong) assumption that incubation 
> succeeds at all times. 

Very few projects around Apache have *DIED*. In my experience, only 3/4 
against some 50 that have various degrees of survival.

We don't have a statistics for incubation, but I would expect it to be 
higher. Yet, this doesn't mean that we can't try.

> I'm the pessimist kind of guy who worries about 
> incubation failures and how a project can survive these.

With my apache hat on, I don't care. With no hat, I would feel sorry 
only if the *incubator* was the problem. If the codebase, or the people, 
were the problem that didn't lead to a healthy community, I would be 
*happy* to know myself if I was them, so that I can dedicate my time to 
something better, or even decide to close-source the thing and go 
commercial.

This is one of the arguments with the q42 people for Xopus: try OSS the 
*good way* and see if it works for you. If it doesn't, well, you know 
that and you move on with that information.

> That is what I 
> was referring to with 'being good for Lenya'. What if they fail to 
> attract new blood? What if they remain an isolated community? But you 
> are right, we should stop worrying about this and see how Darwin helps 
> us here.

Yep.

>>> Of course, I should shut up and get involved (I'll do that). Still, 
>>> the idea behind Incubation Proposals is that people can react upon 
>>> them. I'm only voicing my concerns, and I would love to be proven wrong.
>>
>>
>>
>> I appreciate you voicing your concerns because they allow me to 
>> express my feelings about this.
> 
> 
> Yep. Suggestion to Incubator: add a rationale from the sponsoring 
> Members to a project proposal. You are sometimes referring to a context 
> unbeknown to the list, so it might be good if these things are included 
> in the proposal.

I was expecting negative reactions based on wyona shaky codebase (shaky 
in terms of elegance of use of cocoon solutions, which is not, well, 
outstanding, let's put it this way) so I was prepared to answer them 
(Nicola was probably not expecting them so that's why he reacted more 
defensively)

I said this before but the design pattern for building a community is 
that: "good ideas and bad code build communities, the other three 
combinations do not"

It's very counterintuitive but I think it's the underlying reason for 
Raymond's "release early/release often" suggestion: the more you release 
early, the more your code will have small defects that people will want 
to fix and will force them to learn how the system works internally, 
thus lowering the entry energy gap and allowing them to contribute new 
features more easily.

On the other hand, if you release every 6 months a perfect release, 
you'll get tons of users, but none of them will have the itch to scratch 
to contribute back. Result: you are left doing the work on your own and 
everybody will ask you features and submit bugs, but the entry gap will 
be too high because you can't force them to learn how the internals work.

If wyona was finished and did everything we needed, I wouldn't want it!!!!!

We would have a great product, but no development community. 
Darwinistically speaking, it's like progressing by cloning, instead of 
gene hybridization: clones are *destined* to extintion because they lack 
the ability to evolve with the environment.

A small, dirty codebase is like fast-reproducing small mammals, a 
perfect CMS donated to OSS will be like cloning dinosaurs. You don't 
have to read Crichton to know how this is going to end. :)

>>> Gee - I knew that one was coming ;-)
>>
>>
>>
>> You can't stop an effort with FUD overhere, expecially an incubation 
>> one. It's not fair!
> 
> 
> I hope some of my points are not considered FUD but genuine concerns. I 
> didn't happen to extensively comment on the other proposals going 
> through incubation lately, since they weren't in the domain I'm working 
> in, or have a particular interest in, nor would they eventually lead to 
> sub-project creation inside a project of which I'm part of the PMC.
> 
> I remember, when I was in school, some teachers demanded more of me 
> because they liked me and felt like I was able to answer the extra demand.

Good point :)

>> And if then fails, we might learn stuff that might help future efforts 
>> not to fail.
> 
> 
> I hope, and will try to commit myself, to make sure this experiment will 
> not fail at the cost of the Lenya project itself ([1] for a 
> light-hearted comment on related matters). I'm therefore volunteering to 
> be one of the sponsors.

Very good! thank you and welcome aboard.

>> If you start entering stuff like workflowed revisioning of content, 
>> multi-user annotation, repository abstraction and stuff like that, if 
>> clearly understand that it's not just a matter of assembling existing 
>> stuff, but it's *MUCH* more complex than this.
> 
> 
> Add multi-linguality to that mix, messaging, repository synchronization, 
> and a generic attribution system, and it rapidly becomes much more than 
> what can be handled in a Cocoon sitemap. ;-)

I see that we resonate, very well.

>> Moreover, nobody in the forrest community is interested in making 
>> forrest a full content management system.
> 
> 
> That's a bold and incorrect statement. Why am I here, commenting on 
> Lenya? :-)

nonono, careful: I meant "everybody in forrest will want a full blown 
CMS, but the current focus is to release 1.0 and go slower to that"

On the other hand, Lenya wants to aim to big-time CMS needs from the start.

I expect them to meet in the middle and at that point, we'll see what 
good old Charles suggests us.

>> So, in my vision, forrest starts from making static web sites and 
>> grows up, Lenya start with making supercomplex multi-user environments 
>> and goes down.
>>
>> Will they meet in the middle? I don't know, but I can't see why not.
> 
> 
> I believe there might be some tricks people can learn from Forrest, even 
> if we Forrest committers might not always be happy with all there is to 
> Forrest. It might be in the interest of both communities to seriously 
> look into each other, since they have both extensive Cocoon linkage, and 
> should both try to showcase a set of Cocoon best practices.

Let's put it down crystal clear: if the two communities isolate, I would 
consider my sponsoring completely failed.

> This being said, here is my sincere and empathatic +1 for Lenya joining 
> Incubator with the ambition to become a Cocoon sub-project. I've 
> subscribed to wyona-dev and will see where I can help.

Very nice. Thank you.

Anybody else with comments, either positive or negative?

> </Steven>
> 
> [1] http://blogs.cocoondev.org/stevenn/archives/000550.html

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Proposal for Lenya

[Stefano Mazzocchi <st...@apache.org>]

Steven Noels wrote:

>> Well, I can't be sure either. This is why we are going thru 
>> incubation: it should be a period to estimate *IF* this codebase with 
>> these people is the right seed for a potential healthy community.
>>
>> If now, well, at least we tried.
> 
> Yeah. Since Incubation in itself is pretty new and finding its way to 
> operate, we might be living under the (wrong) assumption that incubation 
> succeeds at all times. 

Very few projects around Apache have *DIED*. In my experience, only 3/4 
against some 50 that have various degrees of survival.

We don't have a statistics for incubation, but I would expect it to be 
higher. Yet, this doesn't mean that we can't try.

> I'm the pessimist kind of guy who worries about 
> incubation failures and how a project can survive these.

With my apache hat on, I don't care. With no hat, I would feel sorry 
only if the *incubator* was the problem. If the codebase, or the people, 
were the problem that didn't lead to a healthy community, I would be 
*happy* to know myself if I was them, so that I can dedicate my time to 
something better, or even decide to close-source the thing and go 
commercial.

This is one of the arguments with the q42 people for Xopus: try OSS the 
*good way* and see if it works for you. If it doesn't, well, you know 
that and you move on with that information.

> That is what I 
> was referring to with 'being good for Lenya'. What if they fail to 
> attract new blood? What if they remain an isolated community? But you 
> are right, we should stop worrying about this and see how Darwin helps 
> us here.

Yep.

>>> Of course, I should shut up and get involved (I'll do that). Still, 
>>> the idea behind Incubation Proposals is that people can react upon 
>>> them. I'm only voicing my concerns, and I would love to be proven wrong.
>>
>>
>>
>> I appreciate you voicing your concerns because they allow me to 
>> express my feelings about this.
> 
> 
> Yep. Suggestion to Incubator: add a rationale from the sponsoring 
> Members to a project proposal. You are sometimes referring to a context 
> unbeknown to the list, so it might be good if these things are included 
> in the proposal.

I was expecting negative reactions based on wyona shaky codebase (shaky 
in terms of elegance of use of cocoon solutions, which is not, well, 
outstanding, let's put it this way) so I was prepared to answer them 
(Nicola was probably not expecting them so that's why he reacted more 
defensively)

I said this before but the design pattern for building a community is 
that: "good ideas and bad code build communities, the other three 
combinations do not"

It's very counterintuitive but I think it's the underlying reason for 
Raymond's "release early/release often" suggestion: the more you release 
early, the more your code will have small defects that people will want 
to fix and will force them to learn how the system works internally, 
thus lowering the entry energy gap and allowing them to contribute new 
features more easily.

On the other hand, if you release every 6 months a perfect release, 
you'll get tons of users, but none of them will have the itch to scratch 
to contribute back. Result: you are left doing the work on your own and 
everybody will ask you features and submit bugs, but the entry gap will 
be too high because you can't force them to learn how the internals work.

If wyona was finished and did everything we needed, I wouldn't want it!!!!!

We would have a great product, but no development community. 
Darwinistically speaking, it's like progressing by cloning, instead of 
gene hybridization: clones are *destined* to extintion because they lack 
the ability to evolve with the environment.

A small, dirty codebase is like fast-reproducing small mammals, a 
perfect CMS donated to OSS will be like cloning dinosaurs. You don't 
have to read Crichton to know how this is going to end. :)

>>> Gee - I knew that one was coming ;-)
>>
>>
>>
>> You can't stop an effort with FUD overhere, expecially an incubation 
>> one. It's not fair!
> 
> 
> I hope some of my points are not considered FUD but genuine concerns. I 
> didn't happen to extensively comment on the other proposals going 
> through incubation lately, since they weren't in the domain I'm working 
> in, or have a particular interest in, nor would they eventually lead to 
> sub-project creation inside a project of which I'm part of the PMC.
> 
> I remember, when I was in school, some teachers demanded more of me 
> because they liked me and felt like I was able to answer the extra demand.

Good point :)

>> And if then fails, we might learn stuff that might help future efforts 
>> not to fail.
> 
> 
> I hope, and will try to commit myself, to make sure this experiment will 
> not fail at the cost of the Lenya project itself ([1] for a 
> light-hearted comment on related matters). I'm therefore volunteering to 
> be one of the sponsors.

Very good! thank you and welcome aboard.

>> If you start entering stuff like workflowed revisioning of content, 
>> multi-user annotation, repository abstraction and stuff like that, if 
>> clearly understand that it's not just a matter of assembling existing 
>> stuff, but it's *MUCH* more complex than this.
> 
> 
> Add multi-linguality to that mix, messaging, repository synchronization, 
> and a generic attribution system, and it rapidly becomes much more than 
> what can be handled in a Cocoon sitemap. ;-)

I see that we resonate, very well.

>> Moreover, nobody in the forrest community is interested in making 
>> forrest a full content management system.
> 
> 
> That's a bold and incorrect statement. Why am I here, commenting on 
> Lenya? :-)

nonono, careful: I meant "everybody in forrest will want a full blown 
CMS, but the current focus is to release 1.0 and go slower to that"

On the other hand, Lenya wants to aim to big-time CMS needs from the start.

I expect them to meet in the middle and at that point, we'll see what 
good old Charles suggests us.

>> So, in my vision, forrest starts from making static web sites and 
>> grows up, Lenya start with making supercomplex multi-user environments 
>> and goes down.
>>
>> Will they meet in the middle? I don't know, but I can't see why not.
> 
> 
> I believe there might be some tricks people can learn from Forrest, even 
> if we Forrest committers might not always be happy with all there is to 
> Forrest. It might be in the interest of both communities to seriously 
> look into each other, since they have both extensive Cocoon linkage, and 
> should both try to showcase a set of Cocoon best practices.

Let's put it down crystal clear: if the two communities isolate, I would 
consider my sponsoring completely failed.

> This being said, here is my sincere and empathatic +1 for Lenya joining 
> Incubator with the ambition to become a Cocoon sub-project. I've 
> subscribed to wyona-dev and will see where I can help.

Very nice. Thank you.

Anybody else with comments, either positive or negative?

> </Steven>
> 
> [1] http://blogs.cocoondev.org/stevenn/archives/000550.html

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

Stefano Mazzocchi wrote:

[extensive snipage]

> Steven Noels wrote:
> 

> You know how I run communities and what are the things I value. Michael, 
> who is the technical leader, resonates with my vision a lot and has been 
> playing very nicely with Cocoon.

Please, I don't see why you need to defend Michael's community & 
technical skills here. I never had any doubts on that, nor did I wanted 
them to arise: if somebody opens up a project and successfully invites 
'foreign' committers, he's pretty cool in my book, regardless of the 
project domain or codebase.

Relinquishing code ownership and slowing down project progress in order 
to let the community in into the project aren't easy things to do, and 
it looks like Michael handled these pretty well.

> Well, I can't be sure either. This is why we are going thru incubation: 
> it should be a period to estimate *IF* this codebase with these people 
> is the right seed for a potential healthy community.
> 
> If now, well, at least we tried.

Yeah. Since Incubation in itself is pretty new and finding its way to 
operate, we might be living under the (wrong) assumption that incubation 
succeeds at all times. I'm the pessimist kind of guy who worries about 
incubation failures and how a project can survive these. That is what I 
was referring to with 'being good for Lenya'. What if they fail to 
attract new blood? What if they remain an isolated community? But you 
are right, we should stop worrying about this and see how Darwin helps 
us here.

>> Of course, I should shut up and get involved (I'll do that). Still, 
>> the idea behind Incubation Proposals is that people can react upon 
>> them. I'm only voicing my concerns, and I would love to be proven wrong.
> 
> 
> I appreciate you voicing your concerns because they allow me to express 
> my feelings about this.

Yep. Suggestion to Incubator: add a rationale from the sponsoring 
Members to a project proposal. You are sometimes referring to a context 
unbeknown to the list, so it might be good if these things are included 
in the proposal.

>> Gee - I knew that one was coming ;-)
> 
> 
> You can't stop an effort with FUD overhere, expecially an incubation 
> one. It's not fair!

I hope some of my points are not considered FUD but genuine concerns. I 
didn't happen to extensively comment on the other proposals going 
through incubation lately, since they weren't in the domain I'm working 
in, or have a particular interest in, nor would they eventually lead to 
sub-project creation inside a project of which I'm part of the PMC.

I remember, when I was in school, some teachers demanded more of me 
because they liked me and felt like I was able to answer the extra demand.

> And if then fails, we might learn stuff that might help future efforts 
> not to fail.

I hope, and will try to commit myself, to make sure this experiment will 
not fail at the cost of the Lenya project itself ([1] for a 
light-hearted comment on related matters). I'm therefore volunteering to 
be one of the sponsors.

> If you start entering stuff like workflowed revisioning of content, 
> multi-user annotation, repository abstraction and stuff like that, if 
> clearly understand that it's not just a matter of assembling existing 
> stuff, but it's *MUCH* more complex than this.

Add multi-linguality to that mix, messaging, repository synchronization, 
and a generic attribution system, and it rapidly becomes much more than 
what can be handled in a Cocoon sitemap. ;-)

> Moreover, nobody in the forrest community is interested in making 
> forrest a full content management system.

That's a bold and incorrect statement. Why am I here, commenting on 
Lenya? :-)

> So, in my vision, forrest starts from making static web sites and grows 
> up, Lenya start with making supercomplex multi-user environments and 
> goes down.
> 
> Will they meet in the middle? I don't know, but I can't see why not.

I believe there might be some tricks people can learn from Forrest, even 
if we Forrest committers might not always be happy with all there is to 
Forrest. It might be in the interest of both communities to seriously 
look into each other, since they have both extensive Cocoon linkage, and 
should both try to showcase a set of Cocoon best practices.

This being said, here is my sincere and empathatic +1 for Lenya joining 
Incubator with the ambition to become a Cocoon sub-project. I've 
subscribed to wyona-dev and will see where I can help.

</Steven>

[1] http://blogs.cocoondev.org/stevenn/archives/000550.html
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

Stefano Mazzocchi wrote:

[extensive snipage]

> Steven Noels wrote:
> 

> You know how I run communities and what are the things I value. Michael, 
> who is the technical leader, resonates with my vision a lot and has been 
> playing very nicely with Cocoon.

Please, I don't see why you need to defend Michael's community & 
technical skills here. I never had any doubts on that, nor did I wanted 
them to arise: if somebody opens up a project and successfully invites 
'foreign' committers, he's pretty cool in my book, regardless of the 
project domain or codebase.

Relinquishing code ownership and slowing down project progress in order 
to let the community in into the project aren't easy things to do, and 
it looks like Michael handled these pretty well.

> Well, I can't be sure either. This is why we are going thru incubation: 
> it should be a period to estimate *IF* this codebase with these people 
> is the right seed for a potential healthy community.
> 
> If now, well, at least we tried.

Yeah. Since Incubation in itself is pretty new and finding its way to 
operate, we might be living under the (wrong) assumption that incubation 
succeeds at all times. I'm the pessimist kind of guy who worries about 
incubation failures and how a project can survive these. That is what I 
was referring to with 'being good for Lenya'. What if they fail to 
attract new blood? What if they remain an isolated community? But you 
are right, we should stop worrying about this and see how Darwin helps 
us here.

>> Of course, I should shut up and get involved (I'll do that). Still, 
>> the idea behind Incubation Proposals is that people can react upon 
>> them. I'm only voicing my concerns, and I would love to be proven wrong.
> 
> 
> I appreciate you voicing your concerns because they allow me to express 
> my feelings about this.

Yep. Suggestion to Incubator: add a rationale from the sponsoring 
Members to a project proposal. You are sometimes referring to a context 
unbeknown to the list, so it might be good if these things are included 
in the proposal.

>> Gee - I knew that one was coming ;-)
> 
> 
> You can't stop an effort with FUD overhere, expecially an incubation 
> one. It's not fair!

I hope some of my points are not considered FUD but genuine concerns. I 
didn't happen to extensively comment on the other proposals going 
through incubation lately, since they weren't in the domain I'm working 
in, or have a particular interest in, nor would they eventually lead to 
sub-project creation inside a project of which I'm part of the PMC.

I remember, when I was in school, some teachers demanded more of me 
because they liked me and felt like I was able to answer the extra demand.

> And if then fails, we might learn stuff that might help future efforts 
> not to fail.

I hope, and will try to commit myself, to make sure this experiment will 
not fail at the cost of the Lenya project itself ([1] for a 
light-hearted comment on related matters). I'm therefore volunteering to 
be one of the sponsors.

> If you start entering stuff like workflowed revisioning of content, 
> multi-user annotation, repository abstraction and stuff like that, if 
> clearly understand that it's not just a matter of assembling existing 
> stuff, but it's *MUCH* more complex than this.

Add multi-linguality to that mix, messaging, repository synchronization, 
and a generic attribution system, and it rapidly becomes much more than 
what can be handled in a Cocoon sitemap. ;-)

> Moreover, nobody in the forrest community is interested in making 
> forrest a full content management system.

That's a bold and incorrect statement. Why am I here, commenting on 
Lenya? :-)

> So, in my vision, forrest starts from making static web sites and grows 
> up, Lenya start with making supercomplex multi-user environments and 
> goes down.
> 
> Will they meet in the middle? I don't know, but I can't see why not.

I believe there might be some tricks people can learn from Forrest, even 
if we Forrest committers might not always be happy with all there is to 
Forrest. It might be in the interest of both communities to seriously 
look into each other, since they have both extensive Cocoon linkage, and 
should both try to showcase a set of Cocoon best practices.

This being said, here is my sincere and empathatic +1 for Lenya joining 
Incubator with the ambition to become a Cocoon sub-project. I've 
subscribed to wyona-dev and will see where I can help.

</Steven>

[1] http://blogs.cocoondev.org/stevenn/archives/000550.html
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: Proposal for Lenya

["Gregor J. Rothfuss" <ro...@abstrakt.ch>]

"Steven Noels" <st...@outerthought.org> wrote ...
> I hope some of my points are not considered FUD but genuine concerns. I
> didn't happen to extensively comment on the other proposals going
> through incubation lately, since they weren't in the domain I'm working
> in, or have a particular interest in, nor would they eventually lead to
> sub-project creation inside a project of which I'm part of the PMC.

not at all, thanks for bringing them up. there are certainly weak
parts in the proposal, and we are glad for feedback so that we can make
a better case :)

for instance, there was a discussion whether refactoring should happen
before we move the code to apache. our initial plan was to submit the
code to apache when it reaches 1.0. we are currently cleaning up the
codebase to make it more consistent, and hopefully easier to get into
for others. (avoiding ridicule over some of the code plays a role too :))

the refactoring wont be too extensive, and we are trying not to hard code
the future direction (to learn from the xindice example). maybe we should
call it spit and polish, but refactoring definitely sounded better on
the roadmap :)

> I hope, and will try to commit myself, to make sure this experiment will
> not fail at the cost of the Lenya project itself ([1] for a
> light-hearted comment on related matters). I'm therefore volunteering to
> be one of the sponsors.

very much appreciated, steven.

> > Moreover, nobody in the forrest community is interested in making
> > forrest a full content management system.
>
> That's a bold and incorrect statement. Why am I here, commenting on
> Lenya? :-)

note to self: install forrest next week, and try to import it into lenya :)

-gregor

--
Gregor J. Rothfuss                   gregor.rothfuss@oscom.org
CMS conferences, interop, advocacy, projects  http://oscom.org

Re: Proposal for Lenya

[Stefano Mazzocchi <st...@apache.org>]

Steven Noels wrote:

> My main concern is the fact that Lenya does not come only with a 
> community, but also with a code base. That code base is in use already 
> at a selected number of commercial installations (which is good, of 
> course). I hope to be proven wrong, yet I fear the existing codebase is 
> intimately linked with these installations - hence the number of 
> publications in CVS. The main group of committers _might_ also depend 
> (financially) on supporting these installations. OK, I'm FUDing here, 
> but I have seen how some other candidate contributions were received 
> lately, and I want to make sure we don't just do the 'huuray - a CMS 
> project at Apache' thing.

Excuse me, but what apache project didn't come with a codebase?

In case you don't know, Apache *requires* an existing codebase to start, 
  there were attempts in the past to create an open source project out 
of design discussions and no code. It *NEVER* worked.

Here, we are lucky enough to have a CMS that is being used in one of the 
most important newspaper of a very high-tech country (switzerland) and 
it's based on apache technologies. Maybe it won't be perfect, but it's a 
seed for a community around CMS issues.

I really can't see what can be a better way for us to start into this.

> Please understand me: if you and some Wyona guys and some other 
> CMS-oriented folks would jump up and invite people to join a CMS 
> project, I would have a vested interest in joining that community. Now 
> if joining that community means supporting an existing, massive codebase 
> instead of proper [RT]-ing with sufficient blank space to be filled in, 
> I would feel less challenged. 

The software is what its development community wants it to be.

You know how I run communities and what are the things I value. Michael, 
who is the technical leader, resonates with my vision a lot and has been 
playing very nicely with Cocoon.

You might not know this, but years ago, Michael approached me asking if 
it was possible to use binary pipelines in cocoon and I said no and will 
probably never happened. This triggered them to write their own pipeline 
engine. Later, they found out that cocoon would have been a better 
choice, but not technically, but community-wise.

I feel that between a strong codebase and a strong community, Micheal 
will choose a strong community. This means delegation, RT-style 
refactoring and so on. The way Cocoon works. The way you like. The way I 
like.

Of course, doing so there will be users to care for and migration paths 
to develop when refactoring takes place. But this happens in Cocoon and 
doesn't seem to bother you.

> I'm not saying this will happen, and I 
> find it great that Wyona people went the extra mile and open-sourced 
> their stuff, but I'm not sure whether your grand vision of an ASF CMF 
> will escape from this (codebase) donation.

Well, I can't be sure either. This is why we are going thru incubation: 
it should be a period to estimate *IF* this codebase with these people 
is the right seed for a potential healthy community.

If now, well, at least we tried.

> Of course, I should shut up and get involved (I'll do that). Still, the 
> idea behind Incubation Proposals is that people can react upon them. I'm 
> only voicing my concerns, and I would love to be proven wrong.

I appreciate you voicing your concerns because they allow me to express 
my feelings about this.

the CMS world is a very difficult one. yet, content needs to be edited, 
managed and published. and those miriads of half-based solutions hurt me 
for lack of reuse between their components and solutions.

Leyna will hopefully bring more choices and less pain for content 
management solution builders, not the opposite. Or I will consider the 
project failed and I will vote -1 to make it exit incubation stage.

>>> * 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.
> 
> 
> Gee - I knew that one was coming ;-)

You can't stop an effort with FUD overhere, expecially an incubation 
one. It's not fair!

> I have a customer asking me about a Cocoon-based CMS [it's a long-term 
> project, so I don't need it right now, so please don't send me quotes 
> for all your homebrewn CMS solutions, beloved colleagues ;-)]. I have a 
> number of options:
> 
>  * try to find out if Lenya fits my requirements and use it
> 
>    - be happy with it as-is (just be a user)
>    - find holes which I can help to plug
>    - wreak havoc while trying to apply Lenya to a use-case it hasn't 
> been designed for
> 
>  * pretend it doesn't exist and write my own one
> 
>    - closed source
>    - open source
>      - cocoondev.org
>      - donation to ASF
> 
> So eventually, given some time, I might have a codebase, but it is still 
> very uncertain.

Leyna is here *NOW*. This is a big plus, in my book. I really can't see 
why shouldn't be one in yours as well.

> Now at this time however, there _are_ already people with CMS codebases. 
> These people might not be willing to work on Lenya, since they are bound 
> to have a different vision and/or implementation, and working on Lenya 
> might mean killing their own baby. I'm afraid (and I repeat: please show 
> me where I'm wrong) that CMS is an area where it is very hard to come up 
> with a decent, generic framework if you don't put many people together 
> right from the start. Even then, there's only a slim chance.

Michael is one of the promoter of the Open Source Content Management 
Conference (http://www.oscom.org/). I think that very few people I've 
met have so much 'open mind' about different open source CMS solutions 
than him.

This said, there will be ego problems. I know that. It's not so hard to 
forecast. But again, that's another reason to move into incubation stage.

>>> 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.
> 
> 
> Sure, and I'm wondering out loud whether the move to Apache will be good 
> for Lenya. 

This is not what we are discussing here. We are discussing if incubating 
Lenya under Apache is good for Apache. The Wyona development community 
(with our advice) already thought about it and decided it was worth trying.

Of course, they are trying to use apache, but it's the usual "do ut des" 
(latin for 'give and take'): they earn visibility and apache earns a new 
community that can improve its overall visibility.

Since it's not certain that it will work, we are proposing the 
incubation facility exactly to avoid hurting other projects by 
bootstrapping the lenya community.

> They have a community, there's buzz, a diverse set of 
> committers so-they-say, and soon they might find themselves in the midst 
> of a much larger community. Does Wyona/Lenya needs the ASF brand to 
> succeed?

Wyona needs to find a place where there is no automatic correlation to a 
commercial entity, otherwise communities don't grow even if seeded 
because nobody likes the feeling of working for a company for free.

They could go to SF, but the Apache Incubator was created as a way to 
bring new potential seeds for communities and help them grow around the 
infamous 'apache way'.

> To attract new committers? Given OSCOM and quite some vocal 
> people working on it, I'm pretty sure Lenya receives a fair bit of 
> attention. 

Yes, but no matter how much you water your seed, it can't grow on 
concrete. You need a more fertile substrate and this is what this 
incubator is meant to provide.

And if then fails, we might learn stuff that might help future efforts 
not to fail.

> But as you say, the system is there and it works. We are 
> allowed to try and do some future-telling, aren't we?

Sure.

>>> 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?
> 
> 
> Aren't we doing that yet? We have XML parsers, XSLT engines, WebDAV 
> stacks, servlet containers, and much more (like mod_perl and AxKit, Matt 
> ;-). Assembling those into a product will not necessarily evolve web 
> technology IMHO.

Well, Forrest is just a bunch of stylesheets, schemas and sitemaps on 
top of Cocoon. Are you proposing we drop Forrest because it's just 
assembling things into a product that doesn't necessarely evolve web 
technology :-)

Seriously: building a CMS on top of Cocoon is *HARD*. I've tried and the 
complexity is much bigger than it seems. I consider Wyona itself just a 
starting point, a seed, in fact.

If you start entering stuff like workflowed revisioning of content, 
multi-user annotation, repository abstraction and stuff like that, if 
clearly understand that it's not just a matter of assembling existing 
stuff, but it's *MUCH* more complex than this.

What I want is not a CMS product, but a content management framework 
backed up by a community of people that know problems and solutions and 
that will write the glue between the pieces that exist and foster 
development of those pieces that are missing.

But in order to do this, we have to start somewhere and Lenya and the 
Wyona people are the best option we could find on outthere!

[again, if you have other alternatives, I'd love to hear them, but they 
have to be here now, not on paper on a possible distant future]

>>> 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.
> 
> 
> I'm _trying_ to understand. Which is better than silently ignoring ;-)

True and appreciated.

>> 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).
> 
> 
> Sure thing. Since Lenya does publishing too, what is the future of 
> Forrest in your scenario? This is not a pun nor a cynical remark: I'm 
> honestly asking. It seems like you guys have spend some serious thoughts 
> in preparing this proposal, and I would like to understand the rationale 
> behind it.

I've spent at least two years thinking about the perfect content 
management framework because content management is what I'm really missing.

my work on cocoon, the spin-off of forrest, my involvement in JSR 170, 
my hopes on xindice, on xopus and now on lenya reflect that.

forrest was created as a stylebook replacer but has grown into something 
that is much bigger, yet, IMO, has yet to find its place because its too 
big for single-user documentation generation and too small to be a 
content management system.

Moreover, nobody in the forrest community is interested in making 
forrest a full content management system.

So, in my vision, forrest starts from making static web sites and grows 
up, Lenya start with making supercomplex multi-user environments and 
goes down.

Will they meet in the middle? I don't know, but I can't see why not.

It might even be possible that leyna exists incubation by mergin with 
forrest, why not.

In short, I don't know the future, but all I know is that *at present* 
there is no community focused on serious content management and I want 
to fix this.

Why? because I need it for my future wild still-top-secret projects :)

>> 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.
> 
> 
> I reckon that. I would like to see it better articulated in that way in 
> the existing codebase, however.

Let me reply with the usual patent pending Jon's reply: 'patches are 
welcome' :)

>> 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 [http://www.wyona.org/roadmap.html#1.0], 
>>> 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.
> 
> 
> Pfew! :-)
> 
>> 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)
> 
> 
> I have been lurking on Xindice since it was moved to Apache, and the 
> Xindice scenario is exactly what is inspiring me when reading this 
> proposal. There are some similarities IMHO.

True and acknowledged.

I'm *very* disappointed about what's happening on Xindice and it is 
partially my fault. I didn't understand that the original development 
community was data-oriented which doesn't make any sense *IMHO) for an 
xml database. Coming into apache created a shift toward 
document-oriented mindsets and the original developers left or found 
themselves uncomfortable with the new paradigm shift.

Xindice needs a technical leader and it's very hard to find one when the 
codebase is pretty solid and oriented toward a different set of needs.

>>> * 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 
>>> xreporter.cocoondev.org right now).
>>
>>
>>
>> Wow, that's very close to be insulting, Steven. Careful.
> 
> 
> It wasn't meant that way. It's a rough and possibly faulthy analysis, 
> while trying to verify what word-of-mouth told me. If I insulted anyone, 
> I'm sorry. But I very much value that criteria for becoming an ASF 
> project, so I think the question _should_ be asked.
> 
>> 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
>> incubation.
> 
> 
> OK.
> 
>> 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.
> 
> 
> Ah. Thanks for sharing! :-)
> 
>> 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.
> 
> 
> Sure thing. Hope I didn't offended anyone. I'm here because I care.

This is very appreciated.

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Proposal for Lenya

[Michael Wechner <mi...@wyona.org>]

Andreas Kuckartz wrote:

<snip />

>
>  
>
>>Sure thing. Since Lenya does publishing too, what is the future of
>>Forrest in your scenario?
>>

To be honest, I am not very familiar with Forrest yet.

But from out of the belly I would characterize Forrest as a specific 
publication type,
with an information architecture suited for software projects, with 
various skins/layouts
to choose from and a specific set of functionalities, such as for 
instance to create the site
automatically out of CVS (right?).

Hence I guess Lenya could be used to manage an instance of the "Forrest 
publication type"
whereas Forrest could be considered as a best practice publication type.

But maybe I am totally wrong, because as I said above I am not very 
familiar with Forrest
and I am sure there are many other people which are much better able to 
steer collaboration
into the right direction.

Thanks

Michael

>>    
>>
>
>I would like to see close collaboration between this projects.
>
>Andreas
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>  
>

Re: Proposal for Lenya

[Michael Wechner <mi...@wyona.org>]

Andreas Kuckartz wrote:

<snip />

>
>  
>
>>Sure thing. Since Lenya does publishing too, what is the future of
>>Forrest in your scenario?
>>

To be honest, I am not very familiar with Forrest yet.

But from out of the belly I would characterize Forrest as a specific 
publication type,
with an information architecture suited for software projects, with 
various skins/layouts
to choose from and a specific set of functionalities, such as for 
instance to create the site
automatically out of CVS (right?).

Hence I guess Lenya could be used to manage an instance of the "Forrest 
publication type"
whereas Forrest could be considered as a best practice publication type.

But maybe I am totally wrong, because as I said above I am not very 
familiar with Forrest
and I am sure there are many other people which are much better able to 
steer collaboration
into the right direction.

Thanks

Michael

>>    
>>
>
>I would like to see close collaboration between this projects.
>
>Andreas
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
>
>  
>

Re: Proposal for Lenya

[Michael Wechner <mi...@wyona.org>]

Steven Noels wrote:

> Andreas Kuckartz wrote:
>
>> You seem to be concerned that the software is *used* in productive
>> environments.
>>
>> Do software developers who want to change the code have to take that into
>> account? Yes, certainly they should do that.
>>
>> Is that an argument against the adoption of the software? No, quite the
>> opposite.
>
>
> No, I'm happy to see it in active use. I fear however that heavy 
> (backward-incompatible) redesign and rearchitecturing will be hindered 
> by the existing installations. Again, this is just thinking out aloud.


No, we definitely won't hinder redesign and rearchitecturing just 
because the software might be backward-incompatible, because we are very 
much aware of that there is still a lot of research and development to 
be done.

That's one of reasons we put so much effort into this XML and XSLT 
thing,because
there will always be stuff to be "migrated", but with XML and XSLT on 
every layer you are certainly
less doomed.

Less seriously, it's rather the opposite: More backward-incompatible 
software gives us some payed
work ;-)

Thanks

Michael

>
>
> I find the overall reaction to this proposal to be only lukewarm. This 
> is worrying me even more.
>
> Thanks for this open discussion.
>
> </Steven>

Re: Proposal for Lenya

[Michael Wechner <mi...@wyona.org>]

Steven Noels wrote:

> Andreas Kuckartz wrote:
>
>> You seem to be concerned that the software is *used* in productive
>> environments.
>>
>> Do software developers who want to change the code have to take that into
>> account? Yes, certainly they should do that.
>>
>> Is that an argument against the adoption of the software? No, quite the
>> opposite.
>
>
> No, I'm happy to see it in active use. I fear however that heavy 
> (backward-incompatible) redesign and rearchitecturing will be hindered 
> by the existing installations. Again, this is just thinking out aloud.


No, we definitely won't hinder redesign and rearchitecturing just 
because the software might be backward-incompatible, because we are very 
much aware of that there is still a lot of research and development to 
be done.

That's one of reasons we put so much effort into this XML and XSLT 
thing,because
there will always be stuff to be "migrated", but with XML and XSLT on 
every layer you are certainly
less doomed.

Less seriously, it's rather the opposite: More backward-incompatible 
software gives us some payed
work ;-)

Thanks

Michael

>
>
> I find the overall reaction to this proposal to be only lukewarm. This 
> is worrying me even more.
>
> Thanks for this open discussion.
>
> </Steven>

Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

Andreas Kuckartz wrote:

> You seem to be concerned that the software is *used* in productive
> environments.
> 
> Do software developers who want to change the code have to take that into
> account? Yes, certainly they should do that.
> 
> Is that an argument against the adoption of the software? No, quite the
> opposite.

No, I'm happy to see it in active use. I fear however that heavy 
(backward-incompatible) redesign and rearchitecturing will be hindered 
by the existing installations. Again, this is just thinking out aloud.

I find the overall reaction to this proposal to be only lukewarm. This 
is worrying me even more.

Thanks for this open discussion.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

Andreas Kuckartz wrote:

> You seem to be concerned that the software is *used* in productive
> environments.
> 
> Do software developers who want to change the code have to take that into
> account? Yes, certainly they should do that.
> 
> Is that an argument against the adoption of the software? No, quite the
> opposite.

No, I'm happy to see it in active use. I fear however that heavy 
(backward-incompatible) redesign and rearchitecturing will be hindered 
by the existing installations. Again, this is just thinking out aloud.

I find the overall reaction to this proposal to be only lukewarm. This 
is worrying me even more.

Thanks for this open discussion.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: Proposal for Lenya

[Andreas Kuckartz <A....@ping.de>]

> My main concern is the fact that Lenya does not come only with a
> community, but also with a code base. That code base is in use already
> at a selected number of commercial installations (which is good, of
> course). I hope to be proven wrong, yet I fear the existing codebase is
> intimately linked with these installations - hence the number of
> publications in CVS.

You seem to be concerned that the software is *used* in productive
environments.

Do software developers who want to change the code have to take that into
account? Yes, certainly they should do that.

Is that an argument against the adoption of the software? No, quite the
opposite.

> Sure thing. Since Lenya does publishing too, what is the future of
> Forrest in your scenario?

I would like to see close collaboration between this projects.

Andreas

Re: Proposal for Lenya

[Stefano Mazzocchi <st...@apache.org>]

Steven Noels wrote:

> My main concern is the fact that Lenya does not come only with a 
> community, but also with a code base. That code base is in use already 
> at a selected number of commercial installations (which is good, of 
> course). I hope to be proven wrong, yet I fear the existing codebase is 
> intimately linked with these installations - hence the number of 
> publications in CVS. The main group of committers _might_ also depend 
> (financially) on supporting these installations. OK, I'm FUDing here, 
> but I have seen how some other candidate contributions were received 
> lately, and I want to make sure we don't just do the 'huuray - a CMS 
> project at Apache' thing.

Excuse me, but what apache project didn't come with a codebase?

In case you don't know, Apache *requires* an existing codebase to start, 
  there were attempts in the past to create an open source project out 
of design discussions and no code. It *NEVER* worked.

Here, we are lucky enough to have a CMS that is being used in one of the 
most important newspaper of a very high-tech country (switzerland) and 
it's based on apache technologies. Maybe it won't be perfect, but it's a 
seed for a community around CMS issues.

I really can't see what can be a better way for us to start into this.

> Please understand me: if you and some Wyona guys and some other 
> CMS-oriented folks would jump up and invite people to join a CMS 
> project, I would have a vested interest in joining that community. Now 
> if joining that community means supporting an existing, massive codebase 
> instead of proper [RT]-ing with sufficient blank space to be filled in, 
> I would feel less challenged. 

The software is what its development community wants it to be.

You know how I run communities and what are the things I value. Michael, 
who is the technical leader, resonates with my vision a lot and has been 
playing very nicely with Cocoon.

You might not know this, but years ago, Michael approached me asking if 
it was possible to use binary pipelines in cocoon and I said no and will 
probably never happened. This triggered them to write their own pipeline 
engine. Later, they found out that cocoon would have been a better 
choice, but not technically, but community-wise.

I feel that between a strong codebase and a strong community, Micheal 
will choose a strong community. This means delegation, RT-style 
refactoring and so on. The way Cocoon works. The way you like. The way I 
like.

Of course, doing so there will be users to care for and migration paths 
to develop when refactoring takes place. But this happens in Cocoon and 
doesn't seem to bother you.

> I'm not saying this will happen, and I 
> find it great that Wyona people went the extra mile and open-sourced 
> their stuff, but I'm not sure whether your grand vision of an ASF CMF 
> will escape from this (codebase) donation.

Well, I can't be sure either. This is why we are going thru incubation: 
it should be a period to estimate *IF* this codebase with these people 
is the right seed for a potential healthy community.

If now, well, at least we tried.

> Of course, I should shut up and get involved (I'll do that). Still, the 
> idea behind Incubation Proposals is that people can react upon them. I'm 
> only voicing my concerns, and I would love to be proven wrong.

I appreciate you voicing your concerns because they allow me to express 
my feelings about this.

the CMS world is a very difficult one. yet, content needs to be edited, 
managed and published. and those miriads of half-based solutions hurt me 
for lack of reuse between their components and solutions.

Leyna will hopefully bring more choices and less pain for content 
management solution builders, not the opposite. Or I will consider the 
project failed and I will vote -1 to make it exit incubation stage.

>>> * 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.
> 
> 
> Gee - I knew that one was coming ;-)

You can't stop an effort with FUD overhere, expecially an incubation 
one. It's not fair!

> I have a customer asking me about a Cocoon-based CMS [it's a long-term 
> project, so I don't need it right now, so please don't send me quotes 
> for all your homebrewn CMS solutions, beloved colleagues ;-)]. I have a 
> number of options:
> 
>  * try to find out if Lenya fits my requirements and use it
> 
>    - be happy with it as-is (just be a user)
>    - find holes which I can help to plug
>    - wreak havoc while trying to apply Lenya to a use-case it hasn't 
> been designed for
> 
>  * pretend it doesn't exist and write my own one
> 
>    - closed source
>    - open source
>      - cocoondev.org
>      - donation to ASF
> 
> So eventually, given some time, I might have a codebase, but it is still 
> very uncertain.

Leyna is here *NOW*. This is a big plus, in my book. I really can't see 
why shouldn't be one in yours as well.

> Now at this time however, there _are_ already people with CMS codebases. 
> These people might not be willing to work on Lenya, since they are bound 
> to have a different vision and/or implementation, and working on Lenya 
> might mean killing their own baby. I'm afraid (and I repeat: please show 
> me where I'm wrong) that CMS is an area where it is very hard to come up 
> with a decent, generic framework if you don't put many people together 
> right from the start. Even then, there's only a slim chance.

Michael is one of the promoter of the Open Source Content Management 
Conference (http://www.oscom.org/). I think that very few people I've 
met have so much 'open mind' about different open source CMS solutions 
than him.

This said, there will be ego problems. I know that. It's not so hard to 
forecast. But again, that's another reason to move into incubation stage.

>>> 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.
> 
> 
> Sure, and I'm wondering out loud whether the move to Apache will be good 
> for Lenya. 

This is not what we are discussing here. We are discussing if incubating 
Lenya under Apache is good for Apache. The Wyona development community 
(with our advice) already thought about it and decided it was worth trying.

Of course, they are trying to use apache, but it's the usual "do ut des" 
(latin for 'give and take'): they earn visibility and apache earns a new 
community that can improve its overall visibility.

Since it's not certain that it will work, we are proposing the 
incubation facility exactly to avoid hurting other projects by 
bootstrapping the lenya community.

> They have a community, there's buzz, a diverse set of 
> committers so-they-say, and soon they might find themselves in the midst 
> of a much larger community. Does Wyona/Lenya needs the ASF brand to 
> succeed?

Wyona needs to find a place where there is no automatic correlation to a 
commercial entity, otherwise communities don't grow even if seeded 
because nobody likes the feeling of working for a company for free.

They could go to SF, but the Apache Incubator was created as a way to 
bring new potential seeds for communities and help them grow around the 
infamous 'apache way'.

> To attract new committers? Given OSCOM and quite some vocal 
> people working on it, I'm pretty sure Lenya receives a fair bit of 
> attention. 

Yes, but no matter how much you water your seed, it can't grow on 
concrete. You need a more fertile substrate and this is what this 
incubator is meant to provide.

And if then fails, we might learn stuff that might help future efforts 
not to fail.

> But as you say, the system is there and it works. We are 
> allowed to try and do some future-telling, aren't we?

Sure.

>>> 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?
> 
> 
> Aren't we doing that yet? We have XML parsers, XSLT engines, WebDAV 
> stacks, servlet containers, and much more (like mod_perl and AxKit, Matt 
> ;-). Assembling those into a product will not necessarily evolve web 
> technology IMHO.

Well, Forrest is just a bunch of stylesheets, schemas and sitemaps on 
top of Cocoon. Are you proposing we drop Forrest because it's just 
assembling things into a product that doesn't necessarely evolve web 
technology :-)

Seriously: building a CMS on top of Cocoon is *HARD*. I've tried and the 
complexity is much bigger than it seems. I consider Wyona itself just a 
starting point, a seed, in fact.

If you start entering stuff like workflowed revisioning of content, 
multi-user annotation, repository abstraction and stuff like that, if 
clearly understand that it's not just a matter of assembling existing 
stuff, but it's *MUCH* more complex than this.

What I want is not a CMS product, but a content management framework 
backed up by a community of people that know problems and solutions and 
that will write the glue between the pieces that exist and foster 
development of those pieces that are missing.

But in order to do this, we have to start somewhere and Lenya and the 
Wyona people are the best option we could find on outthere!

[again, if you have other alternatives, I'd love to hear them, but they 
have to be here now, not on paper on a possible distant future]

>>> 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.
> 
> 
> I'm _trying_ to understand. Which is better than silently ignoring ;-)

True and appreciated.

>> 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).
> 
> 
> Sure thing. Since Lenya does publishing too, what is the future of 
> Forrest in your scenario? This is not a pun nor a cynical remark: I'm 
> honestly asking. It seems like you guys have spend some serious thoughts 
> in preparing this proposal, and I would like to understand the rationale 
> behind it.

I've spent at least two years thinking about the perfect content 
management framework because content management is what I'm really missing.

my work on cocoon, the spin-off of forrest, my involvement in JSR 170, 
my hopes on xindice, on xopus and now on lenya reflect that.

forrest was created as a stylebook replacer but has grown into something 
that is much bigger, yet, IMO, has yet to find its place because its too 
big for single-user documentation generation and too small to be a 
content management system.

Moreover, nobody in the forrest community is interested in making 
forrest a full content management system.

So, in my vision, forrest starts from making static web sites and grows 
up, Lenya start with making supercomplex multi-user environments and 
goes down.

Will they meet in the middle? I don't know, but I can't see why not.

It might even be possible that leyna exists incubation by mergin with 
forrest, why not.

In short, I don't know the future, but all I know is that *at present* 
there is no community focused on serious content management and I want 
to fix this.

Why? because I need it for my future wild still-top-secret projects :)

>> 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.
> 
> 
> I reckon that. I would like to see it better articulated in that way in 
> the existing codebase, however.

Let me reply with the usual patent pending Jon's reply: 'patches are 
welcome' :)

>> 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 [http://www.wyona.org/roadmap.html#1.0], 
>>> 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.
> 
> 
> Pfew! :-)
> 
>> 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)
> 
> 
> I have been lurking on Xindice since it was moved to Apache, and the 
> Xindice scenario is exactly what is inspiring me when reading this 
> proposal. There are some similarities IMHO.

True and acknowledged.

I'm *very* disappointed about what's happening on Xindice and it is 
partially my fault. I didn't understand that the original development 
community was data-oriented which doesn't make any sense *IMHO) for an 
xml database. Coming into apache created a shift toward 
document-oriented mindsets and the original developers left or found 
themselves uncomfortable with the new paradigm shift.

Xindice needs a technical leader and it's very hard to find one when the 
codebase is pretty solid and oriented toward a different set of needs.

>>> * 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 
>>> xreporter.cocoondev.org right now).
>>
>>
>>
>> Wow, that's very close to be insulting, Steven. Careful.
> 
> 
> It wasn't meant that way. It's a rough and possibly faulthy analysis, 
> while trying to verify what word-of-mouth told me. If I insulted anyone, 
> I'm sorry. But I very much value that criteria for becoming an ASF 
> project, so I think the question _should_ be asked.
> 
>> 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
>> incubation.
> 
> 
> OK.
> 
>> 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.
> 
> 
> Ah. Thanks for sharing! :-)
> 
>> 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.
> 
> 
> Sure thing. Hope I didn't offended anyone. I'm here because I care.

This is very appreciated.

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

Stefano Mazzocchi wrote:
> Steven Noels wrote:

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

That's more or less what I'm saying, yes.

> 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?)

My main concern is the fact that Lenya does not come only with a 
community, but also with a code base. That code base is in use already 
at a selected number of commercial installations (which is good, of 
course). I hope to be proven wrong, yet I fear the existing codebase is 
intimately linked with these installations - hence the number of 
publications in CVS. The main group of committers _might_ also depend 
(financially) on supporting these installations. OK, I'm FUDing here, 
but I have seen how some other candidate contributions were received 
lately, and I want to make sure we don't just do the 'huuray - a CMS 
project at Apache' thing.

Please understand me: if you and some Wyona guys and some other 
CMS-oriented folks would jump up and invite people to join a CMS 
project, I would have a vested interest in joining that community. Now 
if joining that community means supporting an existing, massive codebase 
instead of proper [RT]-ing with sufficient blank space to be filled in, 
I would feel less challenged. I'm not saying this will happen, and I 
find it great that Wyona people went the extra mile and open-sourced 
their stuff, but I'm not sure whether your grand vision of an ASF CMF 
will escape from this (codebase) donation.

Of course, I should shut up and get involved (I'll do that). Still, the 
idea behind Incubation Proposals is that people can react upon them. I'm 
only voicing my concerns, and I would love to be proven wrong.

>> * 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.

Gee - I knew that one was coming ;-)

I have a customer asking me about a Cocoon-based CMS [it's a long-term 
project, so I don't need it right now, so please don't send me quotes 
for all your homebrewn CMS solutions, beloved colleagues ;-)]. I have a 
number of options:

  * try to find out if Lenya fits my requirements and use it

    - be happy with it as-is (just be a user)
    - find holes which I can help to plug
    - wreak havoc while trying to apply Lenya to a use-case it hasn't 
been designed for

  * pretend it doesn't exist and write my own one

    - closed source
    - open source
      - cocoondev.org
      - donation to ASF

So eventually, given some time, I might have a codebase, but it is still 
very uncertain.

Now at this time however, there _are_ already people with CMS codebases. 
These people might not be willing to work on Lenya, since they are bound 
to have a different vision and/or implementation, and working on Lenya 
might mean killing their own baby. I'm afraid (and I repeat: please show 
me where I'm wrong) that CMS is an area where it is very hard to come up 
with a decent, generic framework if you don't put many people together 
right from the start. Even then, there's only a slim chance.

>> 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.

Sure, and I'm wondering out loud whether the move to Apache will be good 
for Lenya. They have a community, there's buzz, a diverse set of 
committers so-they-say, and soon they might find themselves in the midst 
of a much larger community. Does Wyona/Lenya needs the ASF brand to 
succeed? To attract new committers? Given OSCOM and quite some vocal 
people working on it, I'm pretty sure Lenya receives a fair bit of 
attention. But as you say, the system is there and it works. We are 
allowed to try and do some future-telling, aren't we?

>> 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?

Aren't we doing that yet? We have XML parsers, XSLT engines, WebDAV 
stacks, servlet containers, and much more (like mod_perl and AxKit, Matt 
;-). Assembling those into a product will not necessarily evolve web 
technology IMHO.

>> 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.

I'm _trying_ to understand. Which is better than silently ignoring ;-)

> 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).

Sure thing. Since Lenya does publishing too, what is the future of 
Forrest in your scenario? This is not a pun nor a cynical remark: I'm 
honestly asking. It seems like you guys have spend some serious thoughts 
in preparing this proposal, and I would like to understand the rationale 
behind it.

> 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.

I reckon that. I would like to see it better articulated in that way in 
the existing codebase, however.

> 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 [http://www.wyona.org/roadmap.html#1.0], 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.

Pfew! :-)

> 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)

I have been lurking on Xindice since it was moved to Apache, and the 
Xindice scenario is exactly what is inspiring me when reading this 
proposal. There are some similarities IMHO.

>> * 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 
>> xreporter.cocoondev.org right now).
> 
> 
> Wow, that's very close to be insulting, Steven. Careful.

It wasn't meant that way. It's a rough and possibly faulthy analysis, 
while trying to verify what word-of-mouth told me. If I insulted anyone, 
I'm sorry. But I very much value that criteria for becoming an ASF 
project, so I think the question _should_ be asked.

> 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
> incubation.

OK.

> 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.

Ah. Thanks for sharing! :-)

> 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.

Sure thing. Hope I didn't offended anyone. I'm here because I care.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Proposal for Lenya

[Steven Noels <st...@outerthought.org>]

Stefano Mazzocchi wrote:
> Steven Noels wrote:

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

That's more or less what I'm saying, yes.

> 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?)

My main concern is the fact that Lenya does not come only with a 
community, but also with a code base. That code base is in use already 
at a selected number of commercial installations (which is good, of 
course). I hope to be proven wrong, yet I fear the existing codebase is 
intimately linked with these installations - hence the number of 
publications in CVS. The main group of committers _might_ also depend 
(financially) on supporting these installations. OK, I'm FUDing here, 
but I have seen how some other candidate contributions were received 
lately, and I want to make sure we don't just do the 'huuray - a CMS 
project at Apache' thing.

Please understand me: if you and some Wyona guys and some other 
CMS-oriented folks would jump up and invite people to join a CMS 
project, I would have a vested interest in joining that community. Now 
if joining that community means supporting an existing, massive codebase 
instead of proper [RT]-ing with sufficient blank space to be filled in, 
I would feel less challenged. I'm not saying this will happen, and I 
find it great that Wyona people went the extra mile and open-sourced 
their stuff, but I'm not sure whether your grand vision of an ASF CMF 
will escape from this (codebase) donation.

Of course, I should shut up and get involved (I'll do that). Still, the 
idea behind Incubation Proposals is that people can react upon them. I'm 
only voicing my concerns, and I would love to be proven wrong.

>> * 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.

Gee - I knew that one was coming ;-)

I have a customer asking me about a Cocoon-based CMS [it's a long-term 
project, so I don't need it right now, so please don't send me quotes 
for all your homebrewn CMS solutions, beloved colleagues ;-)]. I have a 
number of options:

  * try to find out if Lenya fits my requirements and use it

    - be happy with it as-is (just be a user)
    - find holes which I can help to plug
    - wreak havoc while trying to apply Lenya to a use-case it hasn't 
been designed for

  * pretend it doesn't exist and write my own one

    - closed source
    - open source
      - cocoondev.org
      - donation to ASF

So eventually, given some time, I might have a codebase, but it is still 
very uncertain.

Now at this time however, there _are_ already people with CMS codebases. 
These people might not be willing to work on Lenya, since they are bound 
to have a different vision and/or implementation, and working on Lenya 
might mean killing their own baby. I'm afraid (and I repeat: please show 
me where I'm wrong) that CMS is an area where it is very hard to come up 
with a decent, generic framework if you don't put many people together 
right from the start. Even then, there's only a slim chance.

>> 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.

Sure, and I'm wondering out loud whether the move to Apache will be good 
for Lenya. They have a community, there's buzz, a diverse set of 
committers so-they-say, and soon they might find themselves in the midst 
of a much larger community. Does Wyona/Lenya needs the ASF brand to 
succeed? To attract new committers? Given OSCOM and quite some vocal 
people working on it, I'm pretty sure Lenya receives a fair bit of 
attention. But as you say, the system is there and it works. We are 
allowed to try and do some future-telling, aren't we?

>> 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?

Aren't we doing that yet? We have XML parsers, XSLT engines, WebDAV 
stacks, servlet containers, and much more (like mod_perl and AxKit, Matt 
;-). Assembling those into a product will not necessarily evolve web 
technology IMHO.

>> 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.

I'm _trying_ to understand. Which is better than silently ignoring ;-)

> 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).

Sure thing. Since Lenya does publishing too, what is the future of 
Forrest in your scenario? This is not a pun nor a cynical remark: I'm 
honestly asking. It seems like you guys have spend some serious thoughts 
in preparing this proposal, and I would like to understand the rationale 
behind it.

> 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.

I reckon that. I would like to see it better articulated in that way in 
the existing codebase, however.

> 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 [http://www.wyona.org/roadmap.html#1.0], 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.

Pfew! :-)

> 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)

I have been lurking on Xindice since it was moved to Apache, and the 
Xindice scenario is exactly what is inspiring me when reading this 
proposal. There are some similarities IMHO.

>> * 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 
>> xreporter.cocoondev.org right now).
> 
> 
> Wow, that's very close to be insulting, Steven. Careful.

It wasn't meant that way. It's a rough and possibly faulthy analysis, 
while trying to verify what word-of-mouth told me. If I insulted anyone, 
I'm sorry. But I very much value that criteria for becoming an ASF 
project, so I think the question _should_ be asked.

> 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
> incubation.

OK.

> 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.

Ah. Thanks for sharing! :-)

> 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.

Sure thing. Hope I didn't offended anyone. I'm here because I care.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: Proposal for Lenya

[Stefano Mazzocchi <st...@apache.org>]

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 
> http://www.wyona.org/lenya.html 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 [http://www.wyona.org/roadmap.html#1.0], 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 
> xreporter.cocoondev.org 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
incubation.

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                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Proposal for Lenya

[Michael Wechner <mi...@wyona.org>]

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 
> http://www.wyona.org/lenya.html for background info]
> 
> Some remarks and initial thoughts, mostly based on [BT] (belly 
> thoughts), so please don't take too serious or feel offended:

No problem, thanks for starting the discussion.

> 
> * 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.

What does worry you, or better how do read/interpret this sentence?

We mean by this sentence, that we currently have a directory called 
"pubs" where all the (sample) publications are located:

                    pubs
                      |
   ----------------------------------------------- ....
   |             |           |       |
computerworld  oscom       docs    unipublic      .....

and they are mounted "automatically" by */** ,where the first
star is the publication id (e.g. oscom).

The problem is that we have accumulated quite a lot of sample 
publications within this directory and they are all within one
CVS module.

So, all we like to do is to refactor the build process a little bit, 
such that you can declare your pubs path within build.properties for 
instance and that we don't have to ship all sample publications within
one CVS module, but rather have one or two (well maintained) sample 
publications within one CVS module and all the others within a 
scratchpad module for instance, or maybe provided by a third party.
Well, that's it for the moment.


Another reason to do it this way is that:
Let's say you like the publication oscom.org. This means you might 
download it from oscom.org, put it into the directory "pubs", change
the layout et voila you have a publication with the same information 
architecture, the same document types and the same content management
functionalities, but with your own layout.
And you just had to put it into the "pubs" directory

Well, that's one scenario. Another scenario is certainly that
somebody built a website based on Cocoon and wants to make it manageable
by Lenya. That's a bit harder. We have developed some strategies to do
that for instance by defining a Cocoon view "xhtml4lenya", but still 
it's much more work than by customizing an existing instance of a
certain publication type, which is based on the Lenya (framework resp. API).

So, to conclude, I think you could say,that Lenya itself is not a 
ready-to-deployed solution, but really a framework, which is extending 
and based on other frameworks (Cocoon, Slide, ...) (just as Stefano 
decribes it), but the publications can be (but don't have to) 
turn-key-solutions.

In the end you sell it to the customer as a CMS resp. a Box ;-)

> 
> * 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? 
> Will it be the reference ASF CMS tool? Can CMS be considered an area 
> where the ASF wants to operate in, like Zope (CMF) is...? 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.
> 
> * from what I read here [http://www.wyona.org/roadmap.html#1.0], 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

We are currently refactoring a lot of stuff to help developers jump 
start into Lenya (which means dead code removal, simplifying directory 
structures, etc.), but not to set/define a totally ego-centric direction.

Of course we have our ideas, but we really want that others are bringing 
in and are realising their fresh ideas.


  (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).

Please apologize if it sounds like that. But we really don't take it as 
given.


> 
> * 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 
> xreporter.cocoondev.org right now).

No, all of them (http://www.wyona.org/acknowledgements.html) really 
contributed and committed to the CMS, but it's true, that the most 
active committers are currently working at Wyona.

BTW: I just realized that the link to the mailing lists is outdated. The
correct one is http://wyona.org/cgi-bin/mailman/listinfo
(we just changed our mail server the day before yesterday)

The CMS project was never really owned by the company Wyona, but by the
non-profit organization wyona.org (under Swiss Law),which has very 
similar bylaws just as ASF. The reason was to guarantee that the project
is always Open Source and also to guarantee Open Development, no matter 
what could happen to the company Wyona.

Now, we made one mistake (beside others) and that is that we called the
project Wyona. At the very beginning I called it XPS (Extensible 
Publishing System), but the name XPS is registered by Hewlett-Packard 
(and others) and I also thought it was a too technical name. So we 
renamed it to Wyona CMS (I have to admit one reason was also 
cross-branding, just as we learned from Zope did vice versa. Their 
company name used to be Digital Creations).

So, I think the perception of many developers is/was that Wyona CMS is 
owned by the company Wyona, although that is not true
and I think some people didn't join just because of that perception.
But it's perfectly understandable.


> 
> * Xopus has recently had some troubles w.r.t. its licensing policy 
> (open, not open, etc...) Are these things effectively solved right now? 
> What part of Xopus will be inside Lenya CVS?

We are currently using Xopus2.0.0.0 and we will integrate Xopus2.0.0.8,
where both of them are under the Apache License.

It would certainly be great to have the newest version as OS, but it's 
hard to tell at the moment if that will happen.

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

I hope I was able to clarify your remarks/questions.

Thanks

Michael
> 
> Best regards,
> 
> </Steven>

Re: Proposal for Lenya

[Nicola Ken Barozzi <ni...@apache.org>]

Steven Noels wrote, On 20/02/2003 13.36:
> 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 
> http://www.wyona.org/lenya.html 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.

What does that come from? Where does low-level and?
And if it were, it needs we need a more comprehensive CMS thing, since 
we don't have it ;-)

> 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.

Too generic a remark IMHO. Wyona has been working on that goal for some 
time now, it's not just an Apache-proposal thing. They know what they 
are talking about.

> * 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? 
> Will it be the reference ASF CMS tool? Can CMS be considered an area 
> where the ASF wants to operate in, like Zope (CMF) is...? 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.

Errr, not to me ;-)

Cocoon can do much of Jetspeed, Turbine can do much of both, Tapestry 
now... we have loads of server frameworks that do the *same* thing with 
a different perspective. ASF wants to operate on community-driven 
opensource, mainly in the server area, so a CMS fits.

> * from what I read here [http://www.wyona.org/roadmap.html#1.0], 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 

The refactoring is about code... it's good that it's done here, where 
possibly new developers-viewers can drive it from here.

> * 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 
> xreporter.cocoondev.org right now).

Even if it was mainly one company/group working on the codebase now, 
it's not a big issue. We are here to ensure it expands. Incubation was 
created also for this reason.

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

Thre will be no licensing issues. All will be donated fully to Apache.

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

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Proposal for Lenya

[Stefano Mazzocchi <st...@apache.org>]

Matt Sergeant wrote:
> On Thu, 20 Feb 2003, Steven Noels wrote:
> 
> 
>>* 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?
>>Will it be the reference ASF CMS tool? Can CMS be considered an area
>>where the ASF wants to operate in, like Zope (CMF) is...? 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.
> 
> 
> Not really. There's mod_perl vs mod_php vs jakarta, there's Cocoon vs
> AxKit, and probably a few other projects that I haven't thought about that
> operate in the same space within the ASF.
> 
> You really need to get out of your Java shaped shell :-)

Tell him, brother :)

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Proposal for Lenya

[Stefano Mazzocchi <st...@apache.org>]

Matt Sergeant wrote:
> On Thu, 20 Feb 2003, Steven Noels wrote:
> 
> 
>>* 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?
>>Will it be the reference ASF CMS tool? Can CMS be considered an area
>>where the ASF wants to operate in, like Zope (CMF) is...? 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.
> 
> 
> Not really. There's mod_perl vs mod_php vs jakarta, there's Cocoon vs
> AxKit, and probably a few other projects that I haven't thought about that
> operate in the same space within the ASF.
> 
> You really need to get out of your Java shaped shell :-)

Tell him, brother :)

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Proposal for Lenya

[Matt Sergeant <ma...@sergeant.org>]

On Thu, 20 Feb 2003, Steven Noels wrote:

> * 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?
> Will it be the reference ASF CMS tool? Can CMS be considered an area
> where the ASF wants to operate in, like Zope (CMF) is...? 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.

Not really. There's mod_perl vs mod_php vs jakarta, there's Cocoon vs
AxKit, and probably a few other projects that I haven't thought about that
operate in the same space within the ASF.

You really need to get out of your Java shaped shell :-)

-- 
<!-- Matt -->
<:->get a SMart net</:->
Spam trap - do not mail: spam-sig@spamtrap.messagelabs.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Proposal for Lenya

[Stefano Mazzocchi <st...@apache.org>]

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 
> http://www.wyona.org/lenya.html 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 [http://www.wyona.org/roadmap.html#1.0], 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 
> xreporter.cocoondev.org 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
incubation.

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                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------