[OT] On the subject of opinions (from the JUnit thread)

[Robert <rm...@bull-enterprises.com>]

Since I know you guys are strong and well motivated on good design (the
'passionate' discussions on this list can attest to that :-) ), I would
like you general opinion on, well your opinions.

What I would like to know is if you actually look at the source code
from an open source project (Jakarta or otherwise) and have that
influence your usage of that particular API/Package. If not, are there
any other criteria that you use to evaluate something, such as its
following, reputation, etc.

Any comments would be greatly appreciated. Oh, and you can feel free to
send them to me personally if you like: rmcintosh@bull-enterprises.com

Thanks a bunch gentlemen,
Robert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [OT] On the subject of opinions (from the JUnit thread)

[Leo Simons <le...@apache.org>]

On Tue, 2002-09-10 at 21:06, Robert wrote:
> Thanks Leo. Very interesting. Without ever thinking about it, I've done
> pretty much what you describe below. 

=) I hadn't thought about it before either...

> Perhaps I should rephrase my question a tad: Would you use an open
> source project/library if you DID look at the source and found it, well,
> lacking in design, coding conventions, etc. but it worked good and the
> general idea is a sound one?

generally, yes. I use the Sun JDK quite a lot, after all ;)

However, if there is big risk of the project dying meaning I would have
to start maintaining it, no. Of course, if (for example only!) logkit
would die, that's not that much of a problem for me as I can just switch
to log4j.

cheers,

Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [OT] On the subject of opinions (from the JUnit thread)

[Berin Loritsch <bl...@apache.org>]

> From: Robert [mailto:rmcintosh@bull-enterprises.com] 
> 
> Thanks Leo. Very interesting. Without ever thinking about it, 
> I've done pretty much what you describe below. 
> 
> Perhaps I should rephrase my question a tad: Would you use an 
> open source project/library if you DID look at the source and 
> found it, well, lacking in design, coding conventions, etc. 
> but it worked good and the general idea is a sound one?


We use JUnit don't we?  ;P

The bottom line is #1 does it work, and #2 is it something I would
otherwise have to maintain?

We dropped Avalon Testlet in favor of JUnit because they basically
did the same thing (very small differences), and JUnit already
had a very good following, was open source, and was open to
input from its users.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [OT] On the subject of opinions (from the JUnit thread)

[Robert <rm...@bull-enterprises.com>]

Thanks Leo. Very interesting. Without ever thinking about it, I've done
pretty much what you describe below. 

Perhaps I should rephrase my question a tad: Would you use an open
source project/library if you DID look at the source and found it, well,
lacking in design, coding conventions, etc. but it worked good and the
general idea is a sound one?

Thanks again, Robert

-----Original Message-----
From: Leo Simons [mailto:leosimons@apache.org] 
Sent: Tuesday, September 10, 2002 1:49 PM
To: Avalon Developers List
Subject: Re: [OT] On the subject of opinions (from the JUnit thread)

Hi Robert,

there's a few things I usually look at. Top-of-my-head:

1) CVS. Checkout, glance over, build distro. If it doesn't work, check
the docs, mailing list archive, if there is no mention, subscribe, post
message, and with the feedback...

2) evaluate developer community. There are very few projects out there
which are so big you cannot rebuild them yourself in a lifetime. A lot
of added value is the feedback 'n support from developers

3) evaluate use in other OSS projects. Ant is used across OSS dev land,
so it rocks. Same goes for JUnit.

4) recommendations. Of course, the source of the original recommendation
about the project also counts. If one of the avalon developers here says
"check out this, it is cool" that's a plus automatically.

5) documentation. If there isn't a good amount of well-written stuff the
project isn't ready for prime time (many people disagree with me here)

6) stability/maturity. Kinda logical, no?

7) google. If it turns up high in the results, it is referenced well
from other pages so either has good marketing or something to offer.
Coincides with #3.

8) license. Company policy is not to use GPL software unless it comes on
a redhat CD (we keep things closed source 'till I convince everyone
we're not going to make money by licensing, GPL 'kinda' prohibits that)

9) ties with apache. Some of the best OSS is developed here or in use
here.

This all for 'commercial' stuff. For hobbies, it all depends on whether
things

a) interest me
b) are developed by people I like

cheers,

Leo

On Tue, 2002-09-10 at 17:18, Robert wrote:
> Since I know you guys are strong and well motivated on good design
(the
> 'passionate' discussions on this list can attest to that :-) ), I
would
> like you general opinion on, well your opinions.
> 
> What I would like to know is if you actually look at the source code
> from an open source project (Jakarta or otherwise) and have that
> influence your usage of that particular API/Package. If not, are there
> any other criteria that you use to evaluate something, such as its
> following, reputation, etc.
> 
> Any comments would be greatly appreciated. Oh, and you can feel free
to
> send them to me personally if you like: rmcintosh@bull-enterprises.com
> 
> Thanks a bunch gentlemen,
> Robert



--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [OT] On the subject of opinions (from the JUnit thread)

[Leo Simons <le...@apache.org>]

Hi Robert,

there's a few things I usually look at. Top-of-my-head:

1) CVS. Checkout, glance over, build distro. If it doesn't work, check
the docs, mailing list archive, if there is no mention, subscribe, post
message, and with the feedback...

2) evaluate developer community. There are very few projects out there
which are so big you cannot rebuild them yourself in a lifetime. A lot
of added value is the feedback 'n support from developers

3) evaluate use in other OSS projects. Ant is used across OSS dev land,
so it rocks. Same goes for JUnit.

4) recommendations. Of course, the source of the original recommendation
about the project also counts. If one of the avalon developers here says
"check out this, it is cool" that's a plus automatically.

5) documentation. If there isn't a good amount of well-written stuff the
project isn't ready for prime time (many people disagree with me here)

6) stability/maturity. Kinda logical, no?

7) google. If it turns up high in the results, it is referenced well
from other pages so either has good marketing or something to offer.
Coincides with #3.

8) license. Company policy is not to use GPL software unless it comes on
a redhat CD (we keep things closed source 'till I convince everyone
we're not going to make money by licensing, GPL 'kinda' prohibits that)

9) ties with apache. Some of the best OSS is developed here or in use
here.

This all for 'commercial' stuff. For hobbies, it all depends on whether
things

a) interest me
b) are developed by people I like

cheers,

Leo

On Tue, 2002-09-10 at 17:18, Robert wrote:
> Since I know you guys are strong and well motivated on good design (the
> 'passionate' discussions on this list can attest to that :-) ), I would
> like you general opinion on, well your opinions.
> 
> What I would like to know is if you actually look at the source code
> from an open source project (Jakarta or otherwise) and have that
> influence your usage of that particular API/Package. If not, are there
> any other criteria that you use to evaluate something, such as its
> following, reputation, etc.
> 
> Any comments would be greatly appreciated. Oh, and you can feel free to
> send them to me personally if you like: rmcintosh@bull-enterprises.com
> 
> Thanks a bunch gentlemen,
> Robert



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [OT] On the subject of opinions (from the JUnit thread)

[Peter Donald <pe...@apache.org>]

Hi,

On Wed, 11 Sep 2002 01:18, Robert wrote:
> What I would like to know is if you actually look at the source code
> from an open source project (Jakarta or otherwise) and have that
> influence your usage of that particular API/Package. If not, are there
> any other criteria that you use to evaluate something, such as its
> following, reputation, etc.

It really depends upon what you want to use it for. I generally try to work 
out the cost vs benefit ratio factoring in risk. Some rules of thumb;

If I start to rely on something and it fails completely then I want to know 
that I am capable of replacing or rewritting it. Replacement is easy if it is 
a standards implementation (and multiple implementations exist). Rewritting 
is an option for small clearly defined projects.

"Complete" solutions and "one size fits all" philosophies should be avoided 
like the plague. I want to be able to mix n match toolkits and if this is 
easy then it is likely the underlying toolkits are lightly coupled and 
cohesive.

Think of web application frameworks. Some want to give you everything from the 
presentation layer, through dispatch layer, through service and buisness 
logic layers. Some focus one aspect. ie It is easy to use Sitemesh for 
templating, struts for dispatching, Avalon for service layer, torque for 
persistence and velocity for presentation. If I decide I prefer the icky jsps 
I could easy swap velocity for jsp. If I decide I need to use OJB rather than 
torque then that should also be an easy option. Some toolkits don't allow 
this.

Projects with recent releases are better than those without unless I monitor 
development lists ... and ... Projects with documentation are better than 
those without unless I monitor development lists.

Also you will notice that opensource developers often follow a certain 
behaviour pattern as they become more "mature" opensource developers. ie Many 
start as idealistic GPL advocates who have a toolkit that will solve all your 
problems (that only they can maintain). Later many of these same developers 
move to more liberal licenses (ala LGPL, BSD, Apache) have smaller focused 
toolkits and find it easy to move between different projects. I prefer to use 
code by the more "mature" developers as has less road bumps, is more 
consitent and stable.

The other thing I like to look at is reputation. I know certain groups/people 
who I think are good developers and will give whatever they do a looking at. 
For example, the developer of MX4J also maintains Foxtrot (a swing API for 
alternative style thread management). I looked at it purely because I 
respected the authors work on MX4J. If other people I respect also recomend X 
then I will look at X (thats how I ended up using Sitemesh and how I will end 
up using OJB).

The stability and longevity of the project is also a good indicator for a 
project.

Code quality is a fine thing to look at but does not really come in as a 
factor if I just want to use the project. I use quite a bit of crappy code 
but I don't care because I never see it and never have to maintian it (try 
looking through the JDK src one day). On the flipsode, sometimes really nice 
code (think Craigs work on Tomcat4/Catalina) is not enough. When I looked at 
TC4 code I really liked it but it was not as production worthy as TC3.x 
stream so I didn't use it for a long time.

-- 
Cheers,

Peter Donald
 "Man's mind stretched to a new idea never goes back to its original 
dimensions." -Oliver Wendell Holmes 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>