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): http://www.dwheeler.com/oss_fs_why.html 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.
