You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2002/04/10 23:06:22 UTC

Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]

Trying to conclude this touchy-feely thread with some positive (?)
thinking...

Something like one-and-a-half year, Struts became "hot" in the Belgian
IT world, i.e. Struts-focussed seminars, appserver vendors being
enquired about "their level of Struts-support" (lol), people doing
Struts-specific consulting, etc... This was all caused by some
mysterious momentum around Struts, caused by a number of products
supporting Struts-based web development out-of-the-box, articles on the
right websites and in the right magazines, etc... Struts was cool, a
best-practice-framework being regarded as some kind of
mega-design-pattern, etc etc...

Just to state my opinion clearly: Struts is pretty easy to understand
and to start working with for web based apps, it definitively has real
merits. I believe something like WebWork, built by equally great minds
but entering the market two years later, will have a very tough time
defending itself against Struts. So this is not a Struts vs. Cocoon
mail, OK?

After 1.5 years in the spotlights, things appear to be changing somewhat
for Struts. When we encounter people who have been using Struts for some
time now, sometimes we hear negative comments. Especially people who
want to augment Struts with some real XML/XSLT support have difficulties
doing so. People who are on the lookout for XForm support typically also
don't take Struts into consideration, yet others find it too limiting or
too advanced for what they do... but why am I telling you this? I
believe framework technology goes through a cyclical movement between
popularity and impopularity, quite often not because of technical
issues, but because of the lack of good expectation management.

Building frameworks requires some good, strong and thorough thinking, so
as the creator of such a framework, it is like building the hammer for
all nails. Clearly, they will stress the strong points of their own
child, sometimes neglecting to state what it hasn't been designed for.
Eventually, frameworks get over-promoted in areas where they aren't
ideally suited for, and will receive unjustified, but bad critics.

Open source frameworks are also becoming immensily popular during the
past two years, which means they become subject to appreciation by not
only developers, but also consultants, architects, website editors,
magazine writers, etc... Being the first website or magazine to report
on the "new and utterly cool framework for everything" is but one way to
attract an audience. Market perception and good market reception, based
on whatever scientifical or non-scientifical evaluation criteria, is
very important nowadays. Basically, we should be aware of the
counterproductive effect of bad expectation management, i.e. we should
"sell" where we are good at.

Although we have seen numerous very interesting attempts at expanding
Cocoon into the webapp domain, we shouldn't sell this new aspect before
we really are confident we are able to offer a novel and sound way of
supporting webapp development. IMHO, I believe Schecoon/flowmaps and a
*unified* (1) approach for form handling, combined with the future
Cocoon Blocks, might be the seeds that will bring us these aspects
somewhere in the future. I'm pretty confident we have the great minds in
this community that will judge wisely "when we are ready" to launch this
into the world, and eventually, it will be picked up by the websites and
magazines (and become subject to that same cyclical movement :-)

--------------
(1) Unified as in 'one way to do do it', thoroughly documented, not only
in code but also using (shudder) whitepapers, architecture descriptions,
tutorials etc...
--------------

I don't want to say that the current efforts are not mature or not
up-to-specs, but I believe we can all agree that there is still a lot of
work to do, especially with regards to integration and unification. As
long as we don't feel confident, I believe we better focus on developing
instead of marketing ;-)

That being said, let's look at the other issues (and the good news).

Despite some efforts to really bring the Cocoon documentation to a new
level, the Cocoon distribution and website is still a maze of
information. As stated in my previous post, I'd like to coordinate a
rehaul during the course of summer, to make sure the Cocoon website will
be a reference case for showing off the power of Forrest. We have a lot
now, thanks to various contributors, but we really should make it more
accessible for Cocoon newbies. But then again, I'll shut up about this
until I have something to contribute ;-)

Now as far as market perception is concerned, let me take a look at my
Cocoon evangelisation slides:

* Cocoon is in use within the HP Web Services development platform
* Computer Associates is working with it, too
* we have regular coverage now on the O'Reilly/Usefull.inc media outlets
(thanks, Leigh, Edd!)
* Salon.com is using Cocoon, but we could use some more high-profile
website references
* we have a number of Cocoon books in the making (which is extremely
cool, there's only one (and very bad) Struts book ;-)
* we for instance happen to be asked specifically to explain Cocoon
during seminars, the name is becoming more and more familiar (Struts
already is)
* we have one excellent non-Apache Cocoon support site
http://www.cocooncenter.de/

On a community metrics level, we're healthy as ever:

* 33 committers, with very few irregulars
* +/- 400 CVS commit mails / month
* +/- 1800 mails / month on cocoon-dev
* admittedly, only +/- 1000 mails / month on cocoon-users - I believe
the boundary in between both isn't too clear and Cocoon is still in flux
in some areas to further install such a boundary - maybe we are still
more of a developer framework?

In terms of community development, I guess we are approaching some
inflection point where the number of developers is sufficient to create
some self-volunteering topical subtaskforces, but that's a very personal
IMHO ;-)

Furthermore, I believe we have pretty strict rules in terms of release
management, which is good, but which also means we don't release new
features every other day, and that some new things are hidden in the
dungeons of cocoon-dev a long time before they are marketed to the outer
world. I for myself prefer this rather evolutionary approach.

All in all, I'm pretty convinced we shouldn't be too afraid of Cocoon
being badly received or marketed. We have our worries, sure, both in
terms of design (the webapp story) and documentation, things which need
more written docs and diagrams than code or sample apps, I guess. I know
it is politically incorrect to state in an OSS context, but I strongly
believe these are rather small defects which can be handled by
repartitioning the work, and having some more (shudder) proces
management instead of release management. Basically the pitbull that
bites if you don't supply clear documentation with your new & fancy
Cocoon extension, but also tries to keep "information", "ideas" and
"code" in sync for non-cocoon-dev-frequenters.

Any ideas, counter-rants?

Cheers,

</Steven>
http://outerthought.org/


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


Re: Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]

Posted by Rob Jellinghaus <ro...@unrealities.com>.
At 01:43 AM 4/11/2002 +0200, Uli Mayring wrote:
>Project  #user   #dev   /user   /dev   ratio
>Xalan      1282   10825    99     833   0.2
>Ant       13829   18143  1064    1396   0.8
>Cocoon    14504   18083  1116    1387   0.8
>Velocity   5866    3938   451     303   1.5
>Tomcat    41090   20315  3160    1563   2.0
>Soap       8974    3355   690     258   2.7
>Struts    25535    5379  1964     414   4.7
>Zope      27651    5915  2127     455   4.7
>
>Yep, Cocoon is definitely a developer technology. Users go elsewhere. Any
>other interpretations of these numbers?

One other interpretation: Struts-dev is dead!  I posted a fairly 
provocative email there yesterday, and no response whatsoever.  I think the 
fact that cocoon-dev postings outweigh struts-dev postings by almost 4 to 1 
indicates that Cocoon developers are definitely more loquacious and 
potentially more numerous than Struts developers.  (I'm a bit depressed 
about it, actually -- the Struts developers seem rather inaccessible.)

(Why'd you omit Axis?  the last project I contributed to....)
Cheers,
Rob




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


Re: Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]

Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 10 April 2002 07:43 pm, Uli Mayring wrote:
> While development has substantially increased, usage has remained
> constant. Conclusion?

Most people hang out on the -dev list :)

Its where all the action is, and it seems like there are a fair number of 
developers that aren't just building solutions with cocoon, we're all 
extending it out into our various needed directions thanks to the wonderful 
component architecture :)
-pete

-- 
peter royal -> proyal@managingpartners.com

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


Re: Ranting on a Wednesday evening [was: RE: Cocoon MarketingPosition]

Posted by Uli Mayring <ul...@denic.de>.
On Thu, 11 Apr 2002, Stefano Mazzocchi wrote:

> Just one comment: would you venture to state that Ant is a developer
> technology while Struts is a user technology?

Ant is a developer technology for the purposes of writing on the mailing
lists. Regular users download binary versions usually, so they won't need
ant for building. And even if they build from sources, they might have ant
around for the job, but they don't work with it intensively so that
questions might arise for the mailing list. I venture that only
developers, who write their own build scripts, will join the mailing list.
So in that context ant is a developer technology.

Struts is a user technology in the sense that people download it and make
web pages or web apps with it. Then something doesn't work as expected or
they don't know about a feature, so they join the mailing list. I admit
that framework users are always developers to a certain extent and that
seperates struts and ant users in this context.

> Anyway, I would not imagine having to substain the pressure of that 4.7
> ratio: it would definately place development to a halt and we are not
> ready for that.

These are just numbers, interpretation can be difficult. Maybe the ratio
is so high, because the developers have largely left the project? Or maybe
the thing is fairly complete, not much to develop anymore? Maybe
documentation and functionality is so good, that only very few users will
join the mailing list and ask questions? Maybe it is too complicated, so
only expert users stick around?

That is the problem with numbers. They don't lie, but human interpretation
might.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


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


Re: Ranting on a Wednesday evening [was: RE: Cocoon MarketingPosition]

Posted by Stefano Mazzocchi <st...@apache.org>.
Uli Mayring wrote:
> 
> On Wed, 10 Apr 2002, Steven Noels wrote:
> 
> > * +/- 1800 mails / month on cocoon-dev
> > * admittedly, only +/- 1000 mails / month on cocoon-users
> 
> FWIW:
> 
> #absolute number of postings (03/2001 - 03/2002)
> /average number of postings per month for this 13-month period
> 
> user = user mailing list
> dev = developer mailing list
> 
> Project   #user   #dev   /user   /dev   ratio
> Xalan      1282   10825    99     833   0.2
> Ant       13829   18143  1064    1396   0.8
> Cocoon    14504   18083  1116    1387   0.8
> Velocity   5866    3938   451     303   1.5
> Tomcat    41090   20315  3160    1563   2.0
> Soap       8974    3355   690     258   2.7
> Struts    25535    5379  1964     414   4.7
> Zope      27651    5915  2127     455   4.7
> 
> Yep, Cocoon is definitely a developer technology. Users go elsewhere. Any
> other interpretations of these numbers?
> 
> Now let's take a look at the historical development of Cocoon's numbers. I
> have two 13-month periods here, the topmost is the one from above and
> below is the previous 13-month period:
> 
> Period     #user   #dev   /user   /dev   ratio
> 2001/2002  14504   18083  1116    1387   0.8
> 2000/2001  15664   10505  1205     808   1.5
> 
> While development has substantially increased, usage has remained
> constant. Conclusion?

Interesting figures.

Just one comment: would you venture to state that Ant is a developer
technology while Struts is a user technology?

Anyway, I would not imagine having to substain the pressure of that 4.7
ratio: it would definately place development to a halt and we are not
ready for that.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Re: Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]

Posted by Stefano Mazzocchi <st...@apache.org>.
Diana Shannon wrote:
> 
> Simeon Walker wrote:
> 
> > AS a user I can say that it's very hard to use Cocoon. Don't
> > get me wrong, *I* love it and I can see the potential, but I
> > think that many potential users will look at it and think
> > 'christ I'm never going to figure all that out' and then leave.

> If a "learning road map for newbies"  would be of some utility, I'd be
> happy to provide a first draft.

I would *love* this to happen.

Please, do.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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


Re: Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]

Posted by Diana Shannon <sh...@terracare.com>.
Simeon Walker wrote:

> AS a user I can say that it's very hard to use Cocoon. Don't
> get me wrong, *I* love it and I can see the potential, but I
> think that many potential users will look at it and think
> 'christ I'm never going to figure all that out' and then leave.

There are so many layers and levels of learning within Cocoon for new 
users. While it may seem appropriate for frustrated, vocal newbies to 
point the finger at Cocoon generally or its documentation specifically, 
many times this blame is misplaced. If you peer through the smoke screen 
of their "Cocoon frustration," there's often a more fundamental source 
of the problem. Most obvious are lack of experience with servlet 
containers, server configuration issues, XML/XSLT, logging and debugging 
practices, etc. While it's not the responsibility of the Cocoon 
community to educate newbies in all of these fundamentals, I think we 
could provide a road map for mastering it, with suggestions on what 
skills and learning is needed -- both inside and outside of Cocoon -- 
along the way. This could be something like an author's description of 
the intended reader in a "Who you are" introduction to a technical book 
book, but targeted at the many different levels and skill sets of users.

Perhaps many new users fail to realize is that you can use Cocoon in 
very simple ways at first and gradually add complexity as your 
comfort/knowledge increases. I have set up Cocoon-based web sites for 
clients who have but an elementary understanding of XML. Still, Cocoon's 
wonderful SoC allow them to maintain their web sites almost  completely 
(although I do jump in from time to time to add new features).

If a "learning road map for newbies"  would be of some utility, I'd be 
happy to provide a first draft.


Diana Shannon


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


Re: Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]

Posted by Simeon Walker <si...@sbs.bangor.ac.uk>.
Uli Mayring wrote:
<snip/>
> 
> Period     #user   #dev   /user   /dev   ratio
> 2001/2002  14504   18083  1116    1387   0.8
> 2000/2001  15664   10505  1205     808   1.5
> 
> While development has substantially increased, usage has remained
> constant. Conclusion?
> 
> Ulrich
> 
AS a user I can say that it's very hard to use Cocoon. Don't
get me wrong, *I* love it and I can see the potential, but I
think that many potential users will look at it and think
'christ I'm never going to figure all that out' and then leave.

I've been following Cocoon for a long time but occasionally,
when I have had a lot of other work to do, I take my eye off
the ball. Given the fast moving nature of the project it means
that coming back to it after just a couple of months can be
very hard work.

Dare I mention the documentation? Ok I'll stick my neck out...
The missing bits of it and the lack of detail make things
hard for the users. There seem to be a number of places where
the available parameters and the use of them is not explained.
I'm often digging around in the source code to see if I can
figure out what's meant to be going on. I don't think that
the majority of users will even bother downloading the source
code.

Ok, I've gone on more than I meant to here and it does sound
a bit critical. It's not really meant to, like I said, I love
Cocoon but it's hard work.

Regards,
Simeon

-- 
Simeon Walker,                      email: simeon@sbs.bangor.ac.uk
School of Biological Sciences,      phone: +44 (0)1248 383702
University of Wales, Bangor,        fax: +44 (0)1248 382569
Gwynedd, LL57 2UW, UK.              www: http://biology.bangor.ac.uk/


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


Re: Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]

Posted by Uli Mayring <ul...@denic.de>.
On Wed, 10 Apr 2002, Steven Noels wrote:

> * +/- 1800 mails / month on cocoon-dev
> * admittedly, only +/- 1000 mails / month on cocoon-users

FWIW:

#absolute number of postings (03/2001 - 03/2002)
/average number of postings per month for this 13-month period

user = user mailing list
dev = developer mailing list

Project   #user   #dev   /user   /dev   ratio
Xalan      1282   10825    99     833   0.2
Ant       13829   18143  1064    1396   0.8
Cocoon    14504   18083  1116    1387   0.8
Velocity   5866    3938   451     303   1.5
Tomcat    41090   20315  3160    1563   2.0
Soap       8974    3355   690     258   2.7
Struts    25535    5379  1964     414   4.7
Zope      27651    5915  2127     455   4.7

Yep, Cocoon is definitely a developer technology. Users go elsewhere. Any
other interpretations of these numbers?

Now let's take a look at the historical development of Cocoon's numbers. I
have two 13-month periods here, the topmost is the one from above and
below is the previous 13-month period:

Period     #user   #dev   /user   /dev   ratio
2001/2002  14504   18083  1116    1387   0.8
2000/2001  15664   10505  1205     808   1.5

While development has substantially increased, usage has remained
constant. Conclusion?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


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