I think that all of this - while valid - is really just a big misunderstanding about what phase of development Howard is at with tapestry 5.
I'll start off my email with saying I personally promise - when the time comes for it - to create a tapestry 4 "extension" to tapestry 5 that will allow some form of backwards compatibility. I don't know what "my word" means to anyone, but I think I've generally tried to live up to any promises I've made regarding tapestry so far. The marketing message may very well be wrong. Perhaps instead of saying "there will be no backwards compatible support" we should just say it's too early in the design process to focus on that, but when the time comes we will address it. I don't know about everyone else, but I haven't traditionally been a consultant throughout my career. Most of my time has been spent developing and evolving products. If our customers got to hear/be part of the discussions we had for each major new version of a product there would rioting and screaming. Children crying in the streets, buildings burning, etc...Fortunately they never were part of these discussions, save for a few select clients that we would involve to get feedback/input on specific portions that we wanted feedback on. In the end though, the next release always included an upgrade path which made our customers AND developers happy. No one was ever the wiser :) We also ~never~ discussed or thought about backwards compatibility while designing/developing a new major product version. This wasn't a clunky little windows app we were developing either. It was a rather large fault tolerant medical records system that people used in operating rooms / critical care areas / etc. We had custom hardware to design / devices interfacing with hospital equipment / 5 9's requirements / etc....Ie they weren't f-#%-ing around when it came to stability ;) This is just how the process works. At the end of the day, when whatever form of T5 does come out I'm supremely confident that backwards compatibility will be addressed. Partly from years of experience developing products this way, and partly because I just promised it would :) I can't speak to the other issues as much - besides the fact that this is so early in the process people shouldn't be basing their opinions on anything other than the pure design of it as it is - but I view the IoC work being done as a huge example of how Howard ~is~ listening to users. It's become pretty obvious that however technically good hivemind is it has become a thorn in the side of the tapestry 4 series as far as new users getting up to speed. Once you figure out how everything works of course everyone generally loves it, but that's still an issue. I don't know about you, but I'd consider it to be a huge pain in the ass to have to maintain two different repos while designing a framework. I think he's even mentioned on the tapestry5 website (or his blog) that he plans on eventually migrating some form of this back into hivemind. This isn't a hivemind vs tapestry thing. Hivemind isn't being rejected or abandoned. As far as collaboration goes, I think Howard has been pretty open about where he wants to go on things the whole way through. I can understand wanting to be more involved, but you will probably have to assert your involvement yourself instead of waiting for invitations. Everyone is very busy and I'm sure it's hard enough to find time to do all of this free work, let alone do all manner of socializing to make sure all are happy. That's my viewpoint on things. In summary: -) Message about backwards compatibility should be changed to "too early to even discuss it", but should someone need something to feel good about it Jesse has promised to provide some form of tapestry 4 backwards compatibility extension to T5 once enough of the framework has been developed. -) Hivemind isn't being abandoned, Howard is just designing. -) Give the man a break. We should be happy someone as smart/knowledgable is leading the charge and continuing his work in open source. Let him enjoy "some" of the T5 development :) Those are my thoughts, for whatever they're worth. On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote:
Howard, I know you're very innovative and all, but doesn't this really sound somewhat crazy to you? If you really want Tapestry to gain acceptance, then backward compatibility is a big issue. I jumped into the Tapestry world with the 4.0 release and I'm really enjoying it, but if switching to 5.xis going to be "VERY difficult", then I don't know if I'll ever upgrade. Tapestry is definitely (IMHO) very superior to the "standard" JSF, but if it keeps becoming a "moving target", then it will never gain market acceptance. The big wigs will win out because they support a "standard." If Tapestry has the reputation of becoming the "consultant's framework" (as has been said in the past) because it requires so much work to upgrade, then it's going to suffer. It's not that I disagree with the direction you're heading. It's that I don't know whether or not changing paradigms so drastically is a good idea for the health of the "product" or "brand." I agree so far with what you're doing. I don't like the fact that you're switching from HiveMind to TapIoCa (that's my little nickname for the Tapestry IoC container), but if you don't want to be tied to HiveMind or don't want to be constrained by the release schedule, then I understand (although you're a big part of the HiveMind community and we can easily accommodate any changes you could need IMHO). Anyway, this is your baby, but if you want to gain some market share, then you should really listen to your users. Tapestry is starting to get a bad reputation for not supporting backward compatibility. Again, I think the direction you're heading is a good one, if you don't have to consider your current users, but we don't have that luxury.
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
