cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <>
Subject Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]
Date Wed, 10 Apr 2002 21:06:22 GMT
Trying to conclude this touchy-feely thread with some positive (?)

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/ media outlets
(thanks, Leigh, Edd!)
* 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

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?



To unsubscribe, e-mail:
For additional commands, email:

View raw message