cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Open support vrs. Company support (long!)
Date Fri, 19 Sep 2003 08:58:07 GMT
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.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message