You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/04/10 14:26:21 UTC
Cocoon Marketing Position
giacomo wrote:
> You can have a look at it using http://fw.otego.com/demoshop/
If we enter the 'pet shop' marketing arena, we might find ourselves
having to fight J2EE from one side and .NET from the other.
*this* is exactly the marketing and technical pressure that I don't
think we can affort to stand at this very moment.
First of all, without Cocoon Blocks, we can't stand their usability, so
I would not even try to compete.
Second: I'd rather market Cocoon as an awesome glue technology than a
"new" way of doing stuff compared to J2EE or .NET. Cocoon can be used to
create SOAP web services using J2EE technology. It will also be possible
to turn a web service into a web application, and also glue advanced
publishing and report functionalities.
In short, instead of a competitive tagline 'use Cocoon instead of J2EE
or .NET' (which would eventually emerge out of a Cocoon Pet Shop demo),
we should do something different 'no matter what you what to do with
your web, Cocoon will help you doing it better'. [please, excuse the
shitty marketing tone, but we are talking about vapor anyway]
Those are my thoughts.
--
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: Cocoon Marketing Position
Posted by Michael Hartle <mh...@hartle-klug.com>.
Stefano Mazzocchi wrote:
>If we enter the 'pet shop' marketing arena, we might find ourselves
>having to fight J2EE from one side and .NET from the other.
>
Comparing Cocoon with J2EE or .NET is like comparing apples with oranges
as J2EE/.NET is another level than Cocoon in my opinion. We should make
the position of Cocoon (presentational layer) relative to J2EE/.NET
(application/logic layer) clear for anyone.
Making a "Pet Shop" sample explicitly independent of the application
layer (via SOAP, etc), showing how to support J2EE/.NET/something
homebrewed should
- give Cocoon more visibility, thus more feedback,
- provide anyone with a decent sample how to harvest the powers Cocoon
in a real life environment ;) and
- keep us out of any architectural war that is not our own.
The questions left are whether this is sufficiently needed and if there
is enough volunteer capacity available to "scratch the itch".
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Marketing Position
Posted by Ivelin Ivanov <iv...@apache.org>.
Agreed about the marketing position we don't want to squeese ourselves in
and if you look again at my proposal you'll probably realize we're on the
same page.
I wanted us to remove the persistance layer and only leave the flow control
and form handling as a demo how Cocoon can be used as front end.
I also like Ovidiu's suggestion. Don't use the Pet Store code.
Rather provide a pet store app which behaves similarly.
It is important that we make it behave similarly, to flatten the learning
curve.
People who know the original works, will be faster to catch on the Cocoon
way of things,
than if they had to lear how a new app works before studying the impl.
Ovidiu or Konstantin or both of you together, do you want to do the flow
control?
I'll help to plug in the form handling.
Cheers,
Ivelin
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Wednesday, April 10, 2002 7:26 AM
Subject: Cocoon Marketing Position
> giacomo wrote:
>
> > You can have a look at it using http://fw.otego.com/demoshop/
>
> If we enter the 'pet shop' marketing arena, we might find ourselves
> having to fight J2EE from one side and .NET from the other.
>
> *this* is exactly the marketing and technical pressure that I don't
> think we can affort to stand at this very moment.
>
> First of all, without Cocoon Blocks, we can't stand their usability, so
> I would not even try to compete.
>
> Second: I'd rather market Cocoon as an awesome glue technology than a
> "new" way of doing stuff compared to J2EE or .NET. Cocoon can be used to
> create SOAP web services using J2EE technology. It will also be possible
> to turn a web service into a web application, and also glue advanced
> publishing and report functionalities.
>
> In short, instead of a competitive tagline 'use Cocoon instead of J2EE
> or .NET' (which would eventually emerge out of a Cocoon Pet Shop demo),
> we should do something different 'no matter what you what to do with
> your web, Cocoon will help you doing it better'. [please, excuse the
> shitty marketing tone, but we are talking about vapor anyway]
>
> Those are my thoughts.
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Marketing Position
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Stefano Mazzocchi wrote:
>giacomo wrote:
>
>>You can have a look at it using http://fw.otego.com/demoshop/
>>
>
>If we enter the 'pet shop' marketing arena, we might find ourselves
>having to fight J2EE from one side and .NET from the other.
>
>*this* is exactly the marketing and technical pressure that I don't
>think we can affort to stand at this very moment.
>
Can you clarify/expand on that? My plan is to do a series of what I
call "petshop" like apps.
Not in the Microsoft vs Sun performance jingo, but just sample apps that
show a complete picture
of how to use Cocoon for specific things. For starters: a website (I
chose an auction website), two reports (why even to Excel :-). My
intention is to document the pieces of Cocoon (call them blocks if you
like), and the so-called "best-practices" for using them in building
these sample apps. As a whole the principal problem with adopting
Cocoon, is that once you read all the documentation, you're still not
sure what it does. Once you figure out what it does, you're still not
sure what things to use. Once you figure out what things to use (become
familiar with a subset), you're still not sure how to do it.
Talk is cheap, actually showing it in use with all sources and the such
and comprehensible documentation to go along with it will go a longer
way in "marketing" Cocoon than "Marketing" ever could.
I envision a "petshop example" (in the original context) plus howto for
a set of high level use cases "how do I do a webapp", "a report", "a web
service", "a portal" .... etc etc. Perhaps "petshop example" has taken
on a new connotation with the recent .NET hype and we should call it
"usage example" or something less loaded.
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Marketing Position
Posted by Leigh Dodds <ld...@ingenta.com>.
Just to delurk for a moment, I think that marketing Cocoon
as glue technology is a big win.
Being able to tie together multiple legacy interfaces and expose
them through a XML interface is a big plus point for Cocoon.
Cheers,
L.
--
Leigh Dodds, Research Group, Ingenta | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic | sine necessitate"
http://www.xml.com/pub/xmldeviant | -- William of Ockham
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Marketing Position
Posted by Ivelin Ivanov <iv...@apache.org>.
<snip/>
> One article about web technologies in general and problems
> that cocoon is trying to solve, plus problems that other
> major frameworks are trying to solve, all in positive
> manner, should have impressive success. There are not so
> many guys who are doing such things (even when there many
> ones who are know enough to do this).
Good point. It's been a while since the XSP vs JSP article on O'Reily was
published.
>
> Mikhail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Marketing Position
Posted by Mikhail Fedotov <mi...@kittown.com>.
Hi!
> If we enter the 'pet shop' marketing arena, we might find
> ourselves having to fight J2EE from one side and .NET
> from the other.
>
> *this* is exactly the marketing and technical pressure
> that I don't think we can affort to stand at this
> very moment.
...then get rid of ideas that are leading to this and think
about other ways.
> Second: I'd rather market Cocoon as an awesome glue
> technology than a "new" way of doing stuff compared
> to J2EE or .NET.
And this is an example of another way. There are zillion of
ways. This one is better then first. Everything is going
right. ;-)
I would also present cocoon as an implementation of many
good ideas about web programming with having online forum
and articles on website I've been talking in another email.
The only problem is that someone has to write them.
For example, my mp3 encoding-related homepage (no files,
just info, all in russian) wasn't updated since 1999, but
it still has almost the same amount of visitors due to
forum available. Imagine that it could become if only I had
enough time. This page started from article there I've been
comparing information about all encoders and decoders I've
been known that time, some info about mp3 in general, and
that's it. Some guys wrote more specific articles after,
but noone implemented original idea of one big overview,
even now, then everything about mp3 seems to be stable and
finished.
One article about web technologies in general and problems
that cocoon is trying to solve, plus problems that other
major frameworks are trying to solve, all in positive
manner, should have impressive success. There are not so
many guys who are doing such things (even when there many
ones who are know enough to do this).
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Marketing Position
Posted by Steven Noels <st...@outerthought.org>.
Torsten wrote:
> Well, I do see this differenlty... "only" XML-base web
> publishing is not
> enough... Nearly everyone seems to need more. This would
> explain all the
> homegrown form approaches out there. If there would be an
> easy integration
> of other webapp frameworks like e.g. Struts I would aggree.
> But there is
> no such... So we need to come up with something. Current form handling
> seems to be thorn in quite a lot people's side.
>
>
> > I'm quite sure the Flow & Form people out here will help Cocoon
> > transition into the webapp space, but we are not there yet.
>
> yepp... but are trying :)
>
Sure - which was my point :-)
Once Schecoon, its flowmaps and some hybrid best-of-all-breeds form
handling approach are fully fleshed out and absorbed by this wonderful
community, we'll kick some ?ss after all ;-)
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Marketing Position
Posted by Torsten Curdt <tc...@dff.st>.
On Wed, 10 Apr 2002, Steven Noels wrote:
> Stefano wrote:
>
> > In short, instead of a competitive tagline 'use Cocoon instead of J2EE
> > or .NET' (which would eventually emerge out of a Cocoon Pet
> > Shop demo),
> > we should do something different 'no matter what you what to do with
> > your web, Cocoon will help you doing it better'. [please, excuse the
> > shitty marketing tone, but we are talking about vapor anyway]
> >
> > Those are my thoughts.
>
> I second this: we shouldn't be competing with Struts, J2EE, .Net, and a
> gazillion other web frameworks out there. And before we have *really*
> conquered the flow/webapp domain, we should focus on our strengths, i.e.
> XML-based web publishing.
Well, I do see this differenlty... "only" XML-base web publishing is not
enough... Nearly everyone seems to need more. This would explain all the
homegrown form approaches out there. If there would be an easy integration
of other webapp frameworks like e.g. Struts I would aggree. But there is
no such... So we need to come up with something. Current form handling
seems to be thorn in quite a lot people's side.
> I'm quite sure the Flow & Form people out here will help Cocoon
> transition into the webapp space, but we are not there yet.
yepp... but are trying :)
<snip/>
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Marketing Position
Posted by Mikhail Fedotov <mi...@kittown.com>.
Hi!
> I second this: we shouldn't be competing with Struts,
> J2EE, .Net, and a gazillion other web frameworks out
> there.
Why ? I think we should highlight areas there cocoon is
strong.
If there would be some good article on how major frameworks
are compared by different parameters (1) plus online forum
for discussions(2), this could improve both creditability
and visibility.
You have two options - to become a good competitor, or to
become an outsider. If you have good technology, but didn't
put efforts to make it visible, you are loosing your
audience and community support like if you hadn't anything
to show.
If you are a good competitor, you have some other options.
For example, you can choose to be a creditable competitor,
or to be some badass marketing suit. And so on. I guess
most of your favorite choices are obvious, the problem is
with finding correct questions in proper time.
> And before we have *really* conquered the flow/webapp
> domain, we should focus on our strengths, i.e.
> XML-based web publishing.
We should always focus on strengths only and maybe even
make notes on existing weaknesses, to keep them in mind and
to prevent misunderstanding. Creditability rules(3).
> And as far as sexy web pages is concerned, we should
> remember that Apache is a community based on
> collaborative *source code* development, where good
> solid code and relevant documentation is more
> important than marketing-savvy web pages :-)
Take marketing in one hand, creditability in another one,
and mix them(4). Struts page has enough things to be
considered as a pure marketing (including questionable
sentences), but they are creditable and contain useful
information. You can get rid of questionable sentences, but
the first one of them would be that cocoon rules or XYZ
rules or xml is better than anything... you've got an idea.
Marketing as a technology has nothing to do with lies. If
all you have is your imagination, you can base you
marketing on lies, that's your life and you decisions. But
if you have real thing like Cocoon, you can use marketing
rules to present correct information about your software in
good way, and that's it. And, of course, you could push
marketing way too much and ruine everything. ;-)
ps. There are many good bits of information on
www.useit.com. As well as many not so useful bits.
ps1. Docs.. docs are required of course. That was one of my
reasons to point out Struts page. They have links to things
like User's Manual, their structure also can be copied.
Structure of manuals.
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Marketing Position
Posted by Steven Noels <st...@outerthought.org>.
Stefano wrote:
> In short, instead of a competitive tagline 'use Cocoon instead of J2EE
> or .NET' (which would eventually emerge out of a Cocoon Pet
> Shop demo),
> we should do something different 'no matter what you what to do with
> your web, Cocoon will help you doing it better'. [please, excuse the
> shitty marketing tone, but we are talking about vapor anyway]
>
> Those are my thoughts.
I second this: we shouldn't be competing with Struts, J2EE, .Net, and a
gazillion other web frameworks out there. And before we have *really*
conquered the flow/webapp domain, we should focus on our strengths, i.e.
XML-based web publishing.
I'm quite sure the Flow & Form people out here will help Cocoon
transition into the webapp space, but we are not there yet.
And as far as sexy web pages is concerned, we should remember that
Apache is a community based on collaborative *source code* development,
where good solid code and relevant documentation is more important than
marketing-savvy web pages :-)
If I find some time during the summer months, I'd like to start
something in the line of http://httpd.apache.org/docs-project/ for
Cocoon, built on top of Forrest. I was pretty impressed with the WebWork
documentation (http://213.203.18.31/), we already have a lot out there,
but it should be re-structured and made more accessible.
</Steven>
---------------------------------------------------------------------
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
Ranting on a Wednesday evening [was: RE: Cocoon Marketing Position]
Posted by Steven Noels <st...@outerthought.org>.
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