on 11/27/2000 2:22 PM, "Sam Ruby" <rubys@us.ibm.com> wrote:

> Peter Donald wrote:
>> 
>> You may want to have a look at a message that Stefano Mazzocchi
>> sent  to cocoon-dev list on what it takes to be a successful
>> free/open source software project. Basically it crystalized into
>> three factors;
>> 1. low cost of entry
>> 2. good ideas
>> 3. bad implementation
> 
> I agree with this.  I'm not sure how this relates to the subject line,
> however.
> 
> Low cost of entry = click on a URL and get everything you need.  Or run a
> system such as the one that Jon described in a recent email.
> 
> An example of high cost of entry is checking in an XML parser which may be
> incompatible with other products one may be using.

You keep using this example, but this specific issue has been resolved and
also has not been an issue since. It was also related to someone doing
something stupid. :-)

I find it hard to believe that your entire policy of no jars in CVS is based
entirely on this single (IMHO non-)issue.

> My two cents: pulling together a coherent set of binaries and associated
> source that is certified to work together is a GOOD THING.  If you would
> like to check them into a frozen branch then that would be OK too.
> 
> Mixing snapshots from discrete points in time and a moving baseline is not.
> 
>> Compare the projects Turbine, Cocoon and BSF.
> 
> Not enough data points.

Ok, add in jakarta-site2. How many data points do you need?

IMHO, your single example of the XML parser isn't enough data points. I need
at least 4. :-)

> Actually, all that indicates is that I haven't had enough time to do the
> job right.

So, what is the job done right?

Somehow checking in the .jar's for Turbine has solved the low cost of entry
problem quite nicely. Maybe you should try doing something; that is known to
work; in your project as well to see what happens. :-)

-jon

-- 
twice of not very much is still a lot more than not very much