Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 6586 invoked by uid 500); 24 Jul 2003 12:12:07 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 6537 invoked from network); 24 Jul 2003 12:12:05 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 24 Jul 2003 12:12:05 -0000 Received: (qmail 15482 invoked from network); 24 Jul 2003 12:12:02 -0000 Received: from unknown (HELO apache.org) (stefano@127.0.0.1) by pulse.betaversion.org with SMTP; 24 Jul 2003 12:12:02 -0000 Date: Tue, 22 Jul 2003 23:35:09 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: [RT] Updating our marketing strategy From: Stefano Mazzocchi To: Apache Cocoon Content-Transfer-Encoding: 7bit Message-Id: <0AB69273-BCC7-11D7-9868-000393D2CB02@apache.org> X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I'm on the plane back to Italy. My iTunes plays Celia Cruz's "el carnival de la vida" in honor of her recent death. And I'm thinking that the time has arrived for this RT to land. In really short term: Cocoon is mismarketed. I think many realize this. What many don't necessarely realize is that this has been kept so on purpose. At least by me. Cocoon, so far, has been marketed as a publishing framework. Web publishing is mostly a stateless thing and, everybody agrees, Cocoon rocks for stateless sites even if it has been hard to market it on those realms where performance, scalability and high availability is critical, mostly due to the fact that the concept of transparent proxying is not understood at all by system administrators and Apache HTTPd has always done a really bad job in promoting the proxy concept. Anyway, while publishing accounted for the greatest majority of money invested on the web in the early days, today this is not true anymore as most data-driven stateful web applications (and most of them are not public!) get the funding. That's where the money is and J2EE knows this. Now, with the advent of the flow (consider it abstract, I'm not talking about continuations-based flowscript), cocoon is ready to confront with web-app frameworks such as Struts, Turbine and the like. But with a great advantage: we are the only project adressing this need from the publishing perspective. The Zope people are busy trying to move from a CMS-oriented mindset to a CMF-oriented mindset (and rewriting avalon in python, in the meanwhile and going CoP... we are years ahead of them in that area, both in technological terms and in community terms) Everybody else started with the FSM concept and grew on it. Result: fragmentation of the control concern and overlapping of all the presentation concerns. This is what we have, now: how do we make people understand why the above is better than what is exists out there? - o - IMHO, we can't and we shouldn't. We don't have a billion dollar marketing engine. We don't have access to the technical press (only a few opensource-related web sites, but the CEO don't read those things). If we market cocoon as 'an alternative to best J2EE practices' we find ourselves fighting against J2EE and .NET I have said this before, but let me repeat it here: cocoon has a great advantage, it is a combination of three things that carry lots of marketing momentum "java, xml and apache". I fully believe that cocoon is far superior technologically, but marketing-wise, our differences from a "regular" J2EE implementation are too subdle for a project manager to understand, probably even for a CTO. Cocoon enforces SoC and this is the marketing value, but the value of SoC is not so evident unless you apply it in a working environment. So, out strategy should be to "sneak cocoon behind the enemy lines", basically market it as some innocent thing that helps without hurting but without being pretentious about its capabilities. Once cocoon enters a working environment, people wills start understanding the value of SoC and SoC-enforcing architectures and will be infected by this meme, resulting in the use of cocoon in more and more locations. I've seen this happening several times: cocoon entered by the back door and made it all the way to the front door and when people marketed it, they found out they were already using it! - o - Cocoon is glue and duct tape for your web needs. Sounds harmless, doesn't it? suppose you want to use cocoon in some of your web stuff because you like the features and the how it works... you go to your boss and he asks you, boss: what the hell is this? you: it's apache stuff written in java and xml boss: ok, but what does it do? at this point: scenario a: you: it's the next big thing, they promote a concept called MVC++ that uses continuations based flowscript to keep a centralized control flow and a view composed of pipelines made of reusable components boss: how does it integrate with Struts? you: well, this is way better boss: hmmm, who uses it? you: well, this is new stuff, cocoon used to be a publishing framework and only recently they added the necessary functionality to match other webapp frameworks boss: so, you are asking me to replace a de-facto industry standard with something that come out from nowhere and without no industry backup? forget it scenario b: you: they call it "glue for your web needs". basically, it can cohexist side by side with our existing J2EE infrastructre and provide additional services like dynamic PDF or excel generation. we were thinking about using it to generate our database reports in excel for our sales people. boss: hmmm, interesting. does it need any change in our infrastructure? you: no, not at all, it's a fully compliant J2EE thing, we can install it in what we have and we can make it talk to what we already have with no problem. it's a java servlet after all. boss: what about performance, memory, load and the like? you: well, since the processing they do is rather extensive, they include a pretty fancy caching architecture that keeps track of those resources that didn't change. the cache logic is pluggable so we can write it to match our needs. it is also designed to be proxy friendly, so it works transparently with our proxy setup. boss: apache stuff? you: yep, open source, apache license and a pretty healthy community, something like 15 active developers boss: who is using it? you: apparently, it has been used in many different ways: from financial institutions to provide B2B capabilities to personal weblogs. It seems like rather powerful stuff. boss: is there anybody providing support? you: well, Oracle explicitly states to provide support for it, along with Struts and Turbine. Moreover, recently, 6 european companies formed a business alliance to provide cocoon support and development. Ah, several books have been published on it. it's a rather popular projects in the java/xml world. boss: hmmm, sounds cool, but why didn't I hear about this before? you: the project is evolving rather fast. it was born as a proof of concept of using XML technologies for publishing, but given the great success it had, it grew into a much more complete framework. boss: but, again, you say it interoperates nicely with what we already have? you: totally! as I said, it can work with all the J2EE stuff we have. boss: all right, go ahead. The two scenarios reflect the different approaches we can take. I propose to choose the humble one. At that point, we would be *inside* and cocoon will do the marketing itself by perpetuating its viral memes to the technical guys who will get more and more used to it and will start using it for more and more stuff. At that point, we won't even have to go around saying "we are better than struts"... we just say we are different. people will choose what they like the best and what fits their needs the most. What do you think? -- Stefano.