An unfair comparison; those other projects started with a hierarchical employee situations, developed an internal framework, then open-sourced it. Tapestry has evolved as an open source project entirely. I can guide it as best I can, but nobody is in a position to "order" others to follow a procedure. Have to work much more indirectly than that.
People want conflicting things: total backwards compatibility, and super-super new features. Be patient. Upgrading from 3.0 to 4.0 is not that bad, and with each release, the simplifications will make things easier. On 11/29/05, Cliff Zhao <[EMAIL PROTECTED]> wrote: > 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] > > > > > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
