You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kevin Williams <kw...@tarity.com> on 2003/04/23 19:08:20 UTC

[OT]RE: Maybe there should be a tomcat connectors list?

Having recently decided to utilize multiple open source software
packages, the most frustrating, and the most difficult part of open
source is the lack of support/documentation.  IMHO, the primary
advantage Microsoft has over any open source project is the superior
documentation and support (I think Apache might be an exception there
regarding docs).

There are items within open source projects that I would love to
implement, but due to my unfamiliarity and the lack of response from
questions I post to forums, I have been unable to implement (and I don't
know C/C++ so stepping through the code isn't really an option).

I am venting here, but the primary reason why corporations choose
against open source software is the lack of documentation and support
(CIO Magazine).  I would love to see open source projects dominate the
IT industry.  For this to happen we need complete documentation that far
exceeds anything that companies who charge for software put out.  I
would be happy to help in that task--I just need help so I can
completely understand the software!

Kevin Williams



On Tue, 2003-04-22 at 17:56, Mayne, Peter wrote:
> I knew you'd say that. :-)
> 
> I am participating in the open source community (not nearly as much as some,
> admittedly). However, I can only do so much participating.
> 
> If, as part of my job, I wrote decent software without accompanying decent
> documentation, I'd be told off, and rightly so. Why should the open source
> community be different?
> 
> What makes you think that documentation isn't part of the software? There
> seems to be a pervasive view that code is software, and documentation is
> something else. Sad.
> 
> Look at it from an efficiency point of view. I'm not particularly familiar
> with the JK2 code. I could become familiar with it, certainly, but that
> would take time that I may not have. I expect that amongst those most
> familiar with it would be those who wrote it. Who then is best placed to
> write proper documentation, as opposed to "this is what worked for me in my
> limited experience"?
> 
> (Please note that these are polite rhetorical questions: I'm not trying to
> be antagonistic at all, especially to you in particular. And yes, this is
> probably my own wishful thinking.)
> 
> > TNSTAAFL
> 
> This is the grammatically correct version of TANSTAAFL, I presume? :-)
> 
> PJDM
> -- 
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
> 
> > -----Original Message-----
> > From: John Turner [mailto:tomcat-user@johnturner.com] 
> > Sent: Tuesday, 22 April 2003 11:04 PM
> > To: Tomcat Users List
> > Subject: Re: Maybe there should be a tomcat connectors list?
> > 
> > 
> > 
> > A year ago I said the same thing on this list.  Then, after 
> > reading the 
> > professional and restrained replies from a lot of gurus, I 
> > realized what 
> > the whole point of open source is: community participation.
> > 
> > The "wishful thinking" you're describing is actually the 
> > belief that you 
> > can have top-notch, high quality software and top-notch, high quality 
> > documentation together in a vacuum, for free, without any 
> > participation 
> > from you.
> > 
> > TNSTAAFL
> > 
> > John
> 
> The information contained in this email and any attachments to it:
> 
> (a) may be confidential and if you are not the intended recipient, any interference with, 
> use, disclosure or copying of this material is unauthorised and prohibited; and
> 
> (b) may contain personal information of the recipient and/or the sender as defined 
> under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
> collect, hold and use such information and any personal information contained in a 
> response to this email, for any reasonable purpose in the ordinary course of 
> Spherion's 
> business, including forwarding this email internally or disclosing it to a third party. All 
> personal information collected by Spherion will be handled in accordance with 
> Spherion's Privacy Policy. If you have received this email in error, please notify the 
> sender and delete it.
> 
> (c) you agree not to employ or arrange employment for any candidate(s) supplied in 
> this email and any attachments without first entering into a contractual agreement with 
> Spherion. You further agree not to divulge any information contained in this document 
> to any person(s) or entities without the express permission of Spherion.
> 
> 
> ----
> 

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Re: [OT]RE: Maybe there should be a tomcat connectors list?

Posted by "G. Wade Johnson" <wa...@abbnm.com>.
Kevin Williams wrote:
> 
> Having recently decided to utilize multiple open source software
> packages, the most frustrating, and the most difficult part of open
> source is the lack of support/documentation.  IMHO, the primary
> advantage Microsoft has over any open source project is the superior
> documentation and support (I think Apache might be an exception there
> regarding docs).
> 

I should leave this one alone, but I can't. Let me preface this with
the obvious comment that this is my experience and my opinion.

In the >15 years I've used MS programming products, I don't think I
would every claim they had "superior documentation and support." I
agree that some decision-makers "perceive" this to be true. But, in
docuementation, quantity is not the same as quality.

And, as for support, now I have the option to pay for the privilege
of talking to people who usually know less about the problem than I
do. I've actually sometimes had to make multiple calls to finally
get to someone who actually had some idea of what I was talking about.

I do find it amusing that much of the MS documentation I've seen that
is good comes from books published separately from the product. (Many
of them by MS Press.<shrug/>)

In the time I've worked with open source products I've sometimes been
frustrated by a lack of printed documentation. However, forums like
this one have always more than made up for it. And, unlike the
proprietary products, when I have stumbled into a bug the developers
are normally quite willing to help with workarounds and fixes. Unlike
some proprietary products, where they are usually loath to admit there
is an issue much less fix it.

Sorry for the rant,
G. Wade

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Re: [OT]Maybe there should be a tomcat connectors list?

Posted by Mark Eggers <it...@yahoo.com>.
Kevin,

I am going to disagree with almost every point in your
mail message.

1. I personally think that Microsoft documentation is
some of the worst I have ever read.  While it enables
me to bring systems up, it gives me no real
understanding of the software.  For that, I have to
rely on third party books, personal experience, and
usenet.  Or very expensive training . . . .

2. Many of the open software packages now have third
party companies willing to support them (for a price).
 Choosing support from these companies depends on your
in-house expertise and comfort levels.

3. I agree, the documentation quality of many open
source software packages remains challenged.  Then
again, the documentation for something like Perl is
completely beyond most anything I have seen for
commercial products.

However, I think this is also a perception in that the
documentation from commercial companies is slickly
produced and marketed, whereas the open source
documentation is not as nice looking.  Hopefully
Apache projects like Forrest will change that.

That being said, I think a different approach needs to
be taken when working with open software projects than
with commercial projects.

1. Proceed methodically
In other words, walk before you run.  I know, with
deadlines approaching and complex software to
configure / run the temptation is to just 'slam it in
there'.  With commecial software, this often works,
but you're left with a less than optimal environment. 
With open source software, this often doesn't work.

2. Assume that the basic installation and test
procedures work.

I know, assumptions make . . . . However, most open
software packages do at least install and test OK
(caveats for the CVS checkouts).  If the install and
test procedures are not successful, then a more
deliberate (see step 1) reading of the instructions is
probably warranted.

3. Learn something about compilation

You do not have to be a coding wizard in
C/C++/Java/XML in order to understand the output of a
make command.  Being able to read the output and see
that you're missing a required library or file,
wondering why you need a jar file to compile C code,
or that paths seem to be off by a level go a long way
in solving most build and install problems.

4. Document

I've gotten into the habit of either doing my builds
in emacs to keep a text record of everything I do, or
having a text editor open where I can take notes. 
Once I am successful, I clean up my notes so that if
I'm run over by a truck (surprisingly likely since I
bike a lot), other people will not have to recreate
the wheel.

These are my opinions and experiences only.  Your
mileage (especially with your executive management)
may differ.

HTH
/mde/
just my two cents . . . .

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org