I have the exactly same feeling as you. Tapestry needs to learn the management aspect from other open source projects such as Eclipse, Spring Framework, etc.
On 11/29/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > > > > 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] > >
