Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ralph.goers@dslextreme.com
 designates 66.51.199.81 as permitted sender)
Message-ID: <4315E04B.2060207@dslextreme.com>
Date: Wed, 31 Aug 2005 09:52:27 -0700
From: Ralph Goers <Ralph.Goers@dslextreme.com>
Reply-To: rgoers@apache.org
User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: 2.1.8 (Was: Re: JING Transformer...)
References: <251B34B1-3E0B-45CC-B0A3-6CD947ADED42@betaversion.org>
 <4314907B.8050501@reverycodes.com> <43149AB7.3080509@dslextreme.com>
 <4314A036.80605@reverycodes.com>
 <4D0D0562-D410-4277-8E1E-D8E31361AF3E@betaversion.org>
 <4315CE90.3010406@dslextreme.com> <4315D60B.6030504@reverycodes.com>
In-Reply-To: <4315D60B.6030504@reverycodes.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Vadim Gritsenko wrote:

> You are here to help grow and maintain community as a whole, and 
> community currently needs more often releases much more than a stable 
> cforms block (which is just a bit of software, at the end of the day).
>
> Vadim

Vadim,

I guess I have to more completely respond to this.

If you were to review my posts back to when I first started getting 
involved with this community you would find that I have always advocated 
treating Cocoon as a software "product", just as websphere, weblogic 
are.  JBoss, Tomcat, the Apache web server, struts and many other open 
source projects all seem to behave that way.  Yet within the Cocoon 
community there seems to be a resistance to that.  And I don't believe 
that is good for the long term health of Cocoon.  While there is an 
awful lot of creativity here just take a look at our list of blocks. How 
many are stable vs. unstable?  How long will we leave unstable blocks to 
just sit around?  Now I can tolerate this to a large degree with most of 
these because they don't seem to have a large user base so they don't 
cause a lot of harm (although they do cause problems in how Cocoon is 
perceived).

I worked for 17 years at a company that produced performance monitoring 
products for IBM mainframes. We dealt with real customers and their 
problems all the time.  I got very used to putting the company's 
customers first.  What I am doing within this community is a carryover 
from that.  I believe Cocoon's customers - which includes me my employer 
and everyone else on this list - deserve a stable framework with which 
they can deliver the products that they create, deploy and sell.  I 
don't believe Cocoon is a play-toy that we can tweek to our hearts 
content until it is perfect at the expense of our customers.  And that 
is what I see going on here.

I have a simple question - if you had to pay for Cocoon and were told 
that every few months a new release was going to come out but that to 
upgrade you'd probably have to modify your software to use it, would you 
buy it or look elsewhere. I know what my answer would be.  We already 
have a hard enough time convincing folks that Cocoon is a great way to 
build internet applications.  We don't need that as well.

So while you can argue about frequent releases or whatever, I still want 
a forms framework that this community is willing to call "stable".

Ralph