cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: Open support vrs. Company support (long!)
Date Sat, 20 Sep 2003 10:18:13 GMT
Sylvain Wallez dijo:
> Tony Collen wrote:
>> Antonio Gallardo wrote:
>>> Hi:
>>> I want to point out what really means Free Maillist Support.
>>> At first sight when we said Cocoon has support trought free maillist,
>>> it seems like it is less than Company Support. Many of us saw this as
>>> a  lack
>>> instead of a feature, just before we make the first taste of the
>>> Cocoon's
>>> free support feature.
>>>> From my point of view Open support means:
>> <snip/>
>> I didn't have any specific replies because it's all good, so I'll add
>> some more thoughts, slightly on the "Devil's Advocate" side of things.
>> When is commercial (or 'professional') support desired, compared to
>> the "free" kind?
>> I'm sure the members of Orixo can answer this one :)  It's a tough one
>>  though.  The notion of professional support is relative, since many
>> of  us are not here as a result of our jobs (me, for instance).  Sure,
>>  we're all professionals in one way or another, but I'll limit my
>> definition to refer to people who are directly supporting Cocoon for
>> money.
> <snipped-very-true-comments/>
> I have found several reasons that led our customers to ask for paid
> support (I prefer to say "paid" support as "professional" implies that
> cocoon-users is of lesser quality). You mentioned some of them already :
> 1/ They're not accustomed to using opensource software. They use it
> because it's both powerful and free, but are a bit frightened both by
> the fact that there's no "real" person they can ask to when they have a
> problem and by the information flood in the mailing-list (in clear text,
>  they're not subsribed to cocoon-users).

> 2/ Project-related support. We do architecting, prototyping, guidance,
> evaluation and all that stuff that require some minimal knowlege of the
> project domain. And this can't be provided by cocoon-users.
> 3/ Training. Cocoon is a large beast with many features, and mastering
> it takes time. Training allows to greatly reduce the learning curve.
> 4/ Custom component development. Cocoon allows to build entire
> applications without writing a single line of Java. But sometimes a
> particular feature is needed, which requires to code new component and
> thus requires a deeper knowledge that what the customer doesn't want to
> invest in. Being a committer also allows the new component (if generic
> enough) to go back to Apache, thus relieving the customer of its
> maintainance.
> The "knowledge hub" aspect is not something whose benefits are
> immediately perceived. But as most projects use other libraries as well
> (and Cocoon comes with a big load of jars), this quickly proves useful.
> Coming to us because we are Cocoon-geeks, customers quickly discover
> that we're also Ant-geeks, Tomcat-geeks, FOP-geeks, etc. This is what we
>  call the "Cocoon galaxy".
> As you can see, free support and paid support don't serve the same needs
>  (except on point 1/) and are complementary.

Thanks Sylvain. I just thinked in this first example. Then you showed me
that there are other activities that clear can be called support too.
Anyway I found a very interesting doc related to this topic (warning: the
doc is large too):

But related to support, they show that this is not black and white. If you
does not want to read all the docs. I can point to the 9 chapter:
Unnecessary Fears.

Best Regards,

Antonio Gallardo.

View raw message