>
> You cannot be serious. C'mon, are you saying that
> dealing with "blackboxed" product bug helps your
> personal productivity?!
>
> "Common good" is a worthy purpose, but even on very
> pragmatic, personal and immediate level it is highly
> rewarding to be able to dive into somebody else's code
> and fix bugs here and there.
> - if you fixed the bug - you just gained productivity;
> - went through that project code and did not throw up
> - you just gained confidence in the project and gained
> productivity again by becoming familiar with internals
> of the tool/library whatever;
First, I didn't say I wanted to stay on closed source products; I
said I wanted to stay *off* beta products. Tapestry 3.0.3 has source, just
like 4.0, so if I run into something I don't understand (which has been
known to happen from time to time), I can still whip out the source
regardless of whether I'm on a Beta or not. The difference is that on
Tapestry 3.0.3, if something doesn't work, my first assumption is "must have
been something I did", whereas with a Beta, my first question has to be "is
it me, or the beta?" which doubles my debugging space.
Second, I don't see fixing somebody else's bug as gained
productivity. If fixing bugs in other people's code improved productivity, I
could make an entire team highly productive in no time if I just checked in
buggy code all the time and made them clean up my messes. After all, they
got familiar with my code, got confident in it, etc :). Instead, I see it as
time that could have been spent working on something else. Fundamentally I
use a third party library precisely because I *don't* want to have to worry
about that part of the code.
As for the more general question, yes, I'd honestly prefer a
perfectly stable, well documented and predictable black box over an
unstable, poorly documented and unpredictable open source project. Clearly
this is something of a charicature; plenty of commercial black boxes are
unstable, and plenty of OS projects are rock solid and well documented.
Somewhere between these two extremes is my crossover point where the
benefits of having access to the source begin to offset the disadvantages of
doc/stability/predictability, but it's not an absolute for me. Just because
something has source doesn't mean it's automatically my preferred choice;
it's a point in favor, but far from the determining one.
To give an example, last week I wanted to profile a tapestry app.
Like most of you (I suspect), I work with eclipse. So I went hunting for an
eclipse profiling plugin. I first tried the open source, and free Eclipse
Profiler Plugin http://eclipsecolorer.sourceforge.net/index_profiler.html.
Four hours, a few hundred google searches, and extensive mucking around with
my JVM startup parameters later ... it still didn't work. I then went out
and downloaded JProfiler which ... just ... worked. I was up, running, and
profiling within five minutes of the download. I'll give up source code any
day of the week and twice on Sunday for that kind of ease of use.
In the particular case of Tapestry, clearly I've determined that a
basket of factors (of which source availability is definitely one) make it
the right tool for my current job. The same thing is true for a number of
other open source packages I'm using right now (Hibernate, POI, commons
logging, commons email, commons beanutils, etc). I'm still using JProfiler
for my profiling though, Windows XP for my development OS, Outlook as my
mailer, and MS Word to work on documentation :).
--- Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
