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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
