Update: I was right, even if his interest has moved elsewhere, Stefano still believes in Cocoon and this was one of his social engineering tricks. A hard and foolish one though, because of the potential effects on our users.

Update 2: This post was picked up by Eric for this week's Pulse .

Stefano, Cocoon's original creator, sent two days ago a provocative post on cocoon-dev: " Is Cocoon obsolete"? That's not uncommon from Stefano to put a firebrand in the anthill. This even one of the social engineering techniques he uses when a community has become somehow sleepy: force the group to unite again to face a danger. And the fact that it happens just a few days before the annual Get Together is certainly not a coincidence.

This time is somehow different though, as it may well be the sign of a divorce between Cocoon and its creator: Stefano has been working for about 3 years now as a researcher on the semantic web at the MIT, doing cool and amazing stuff on the Mozilla platform, which is a very powerful environment. So his interest has moved from smart server-side solutions to smart client-side solutions, hence his questioning.

This questioning needs to be answered from several point of views.

Technical aspects
Cocoon has for long be very innovative: it was the first widespread framework to have XML processing pipelines, component oriented programming, continuation-based page flow and scripted controllers ( flowscript). There are other frameworks that do have this now, even if this doesn't mean average programmers all use these features.

J2EE developers heavily use Spring. Although Cocoon is based on the aging (and retired) Avalon/Excalibur framework, integrating Spring with the current release is straightforward. And the 2.2 development branch allows virtually any component container to be used instead of Avalon. Spring support is there, and adding Hivemind or Pico to the picture is easy.

Ruby on Rails is having a lot of attention lately. It is certainly cool stuff, but will it ever been used in large companies? Cocoon has for long has some strong RAD capabilities. This includes its ability to use a wide range of datasources (start with static XML files with sample data then switch to a database) and the "save-and-reload" approach combined with the scripting and templating features make development much faster than "stop-deploy-restart". The 2.2 branch also allows to associate a classpath and a sourcepath (yes, on the fly compilation) to each sitemap, with dynamic reloading. And there's also an important ongoing work about using OSGi for hot-deployable application blocks.

There's currently no real equivalent to ActiveRecords which is one of the coolest things in RoR. But I'm pretty sure the Java community will come up with a solution sooner than later.

Also, everybody's talking about Ajax too. Well, Cocoon has it since April, and it's use is dead easy. But there "just" has been no official release since then (which is a problem -- see below).

So technically, Cocoon is not obsolete. It has a number of yet-to-be-released cool features, and as Pier says, it is not obsolete, but mainstream.

Market aspects
Stefano says: " the more I learn how to drive the client, the less I feel the need for advanced server frameworks". Right, but not everybody is using the latest (and yet unreleased) Firefox 1.5. Like it or not, IE is still the dominant browser, and there are quite a large number of other different browsers. Not everybody has an high-end desktop PC and a high bandwidth connection. The mobile web is taking off, and there are a number of cheap PC initiatives to reduce the digital divide. No XUL on these devices, no built-in XSLT processor, no Ajax.

So there is a great need for a powerful server-side framework that is able to adapt content to the various capabilities of these browsers. And Cocoon is the solution for this, already used by huge mobile operators to drive their mobile portal.

Now that's true that things like Google IG or its Netvibes clone lead portal vendors (Cocoon included) to question themselves about what a portal will be in the near future. Ajax applications also make less use of sophisticated processing pipelines, but flowscript and continuations shine there.

Social aspects
That's the main point: why has there been this trafic slowdown on the cocoon-users list this year? Well, we, Cocoon developers, have neglected our users. A mainstream product is not to be managed as a research product. Our users are less technical and want to read documentation rather than digging in the code as we are so used to doing. We also had no official release since March, which means that a lot of cool new stuff is still unkown to a large majority of our users. Release early, release often: we failed to do that lately.

This must change: we need to have periodical releases, and the 2.2 branch must enter the beta stage so that people can start using it. This has been discussed on the dev list, and we must do it.

We have to make the buzz too: Cocoon is almost absent from the main information portals. Let's write articles for onJava, post on portals such as TSS, Javalobby and Ajaxian!

This means that developers have to change their mindset, and rather than developing Cocoon driven by their own needs, have to think about spreading the word and care about end users that need some stable and documented features (yes, I know who I am). That will bring back the virtuous cycle where more users mean more inputs, more developers, and more Cocoon-related business.

Conclusion
Thanks to Stefano for this provocative post. As usual when he does this, this brings food for thought and forces people to get out of the daily stuff and start looking at the current situation and think about the future.

This will certainly be a hot topic at the Get Together, and gives me some material for my "state of the project" keynote!