At 18:44 12.04.2001 -0700, Craig R. McClanahan wrote:
>On Fri, 13 Apr 2001, Peter Donald wrote:
>
>> At 08:16 12/4/01 -0400, Sam Ruby wrote:
>> >If you accept that you are in a world where interfaces that you are
>> >depending on change frequently, then the problem to solve is optimizing the
>> >communication paths.
>> >
>> >I don't accept that reality.
>> >
>> >I bet that 98% of the servlets out there would compile just fine against a
>> >version of servlet.jar that was built two years ago. I bet that 98% of
>> >these servlets will compile just fine against the version of servlet.jar
>> >that will be built two years from now.
>> >
>> >The same can not be said for applications which depend on avalon or
>> >turbine. Not two years, not one year, not six months, not three months.
>> >Heck, I doubt that 98% of the applications which depend on turbine would
>> >compile against the version of turbine that WAS BUILT LAST NIGHT.
>>
>> Welcome to opensource! Standards are not done here - we can implement them
>> but we don't build them - for those please go elsewhere
>> (IETF/W3C/JCP/Other). One of the advantages of opensource is people are
>> free to adapt them to their own environments. Hence they do. If you want
>> static versions go buy something from a major vendor. Even those generally
>> do complete changes every major version (see MS and their DX1-8 or MFC
>> versions).
>>
>
>In a backhanded way, I agree with this sentiment -- open source is
>demonstrably good at creating great implementations, and not so good at
>creating specifications. I suspect this is partly/mostly because many
>open source developers rebel against the very disciplines that a
>"standard" implies. (If you want a fight, let's talk about where the
>curly braces should go on an "if" statement :-).
>
>But this also raises an issue of who are the "users" we are trying to make
>life easier for. More on this below.
>
>> >Gump doesn't solve these problems. Peter Donald has outsmarted it.
>>
>> I haven't outsmarted it. I solved the problem that was presented. You have
>> failed to pose any other problem that would make me adjust my position - I
>> want low cost of entry.
>>
>> Have a look at all the projects under apache umbrella. Now rate the
>> activity of each project excluding people who get paid to directly work on
>> products. Now correlate this with cost of entry (of which jars in CVS is a
>> factor). Excluding ant for the moment what do you see? ... Which ones have
>> more community behind them? Which ones store binaries in CVS? Coincidence?? ;)
>>
>
>This paragraph begs for multiple responses, from different viewpoints (not
>necessarily building on each other):
>
>* How are you measuring "activity"? I would guess from your statement
> that you are talking about developers doing commits -- but what about
> they users who just want to USE your project in their own work and could
> give a rip about how the thing is built. By that measure, I would submit
> that Tomcat is far and away the most active Jakarta project, followed by
> Ant, followed by Struts, followed by everything else. (Check download
> counts and -USER list subscriptions and activity for corroborating
> evidence). Tomcat 3.x and Struts contains no checked in JARs, Tomcat 4
> only has patched versions of the stupid JAXP sealed jars until the next
> version of JAXP fixes that for us.
Are the stats available? If so, I would appreciate a pointer.
Coming back to the number comparisons, I think that most jakarta projects are very
popular compared to the thousands of open source projects out there. Log4j which is
not as nearly as popular as tomcat, gets over 10'000 hits/day, a 2000-4000
visitors/day, and about 500 downloads each day, that's more than most open source
projects get in a whole year. Although log4j is totally dwarfed by Tomcat which is
probably the most popular Java application in the world today. The point to remember
is that even if Tomcat included binaries in its CVS module, Tomcat would still be very
popular, not more, not less. It is becoming increasingly clear to me that the
inclusion of binaries in a CVS is a minor or even a negligible point. It begets heated
debate but does not matter that much at the end of the day. What matters is the
quality of the code, stability of the API and portability.
>* The number of binary distro downloads of most Jakarta projects is orders
> of magnitude more than the number of people who download source distros
> or update via CVS. Note that the popular packages for USERS include
> convenient "all in one" binary distributions, despite the fact that they
> don't use CVS to store JAR files. (Ant is sorta an exception - they
> offer two downloads (Ant and optional.jar) but you have to go grab
> everything else yourself).
>
>* There seems to be a theory that only people who build from source can
> contribute patches and enhancements. That is not borne out by
> experience on the projects I'm involved in, because the source code is
> there for examination anyway -- very large percentages of patches come
> from people who are just looking at the "src" directory included with
> the binary distributions.
Indeed. Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
