"Jacek R. Ambroziak" wrote: > > Dear XSLTC users, > > I owe you clarification about the status of > my XSLTC version, binaries of which are served > from my website www.ambrosoft.com. > The version is derived from Apache/Xalan/XSLTC 2.3.1 > which in turn is derived from my final project > at Sun Microsystems. > > I have returned to this topic because I myself need > XSLTC for my commercial work; the direct trigger was > an email from Stefano Mazzocchi on lack of benchmarking > data and bugs prohibiting him from the unrestricted use > of this promising technology in Cocoon. > > I started to work on XSLTC again after a long break > thinking that perhaps it was a matter of fixing a few > outstanding bugs and everything will be fine. > After many long days of intensive effort I realized > that the code is in fact quite far from fully > realizing the potential of the original vision. > This is my personal opinion. I am not going to discuss > details here, but improvement opportunities are numerous > and I am implementing them. > > My current version represents an uncompromising overhaul > of the code base and is no longer implementation compatible > with Xalan/XSLTC (although it is API compatible). > Therefore at this point I cannot CVS-commit nor -update > as doing so would mess up the Apache and/or my versions. > > I am calling my version "experimental" because I indeed > experiment freely with any, however far-reaching, changes > I feel are beneficial to the technology. I am addressing > performance and architectural issues with a fresh perspective. > Maybe my long break was not such a bad thing after all :-) > > This level of free experimenting would not be possible > in the context of the Xalan community effort, > neither would it be a good thing: it would be destabilizing. > > Naturally, I wouldn't be investing energy into > reenginering XSLTC if I didn't believe a worthwhile outcome > would result. > > I will continue to post information about XSLTC-2 > at my website, but I strongly feel it inaproppriate to > continue discussing it at this forum. That's why I had asked > people interested in progress/use of XSLTC-2 > to contact me directly. > > I am sorry if this explanation disappoints some of you > but I hope my results will end up being useful > to XML/Java users.
Jacek, being relatively new to Apache, you might not be aware of the 'rules for revolutionaries' (these are not stated explicitly on any apache web site because there is not much need for such a thing... but the PMC should greatly considering adopting them) http://www.x180.net/Mutterings/OpenSource/RulesForRevEmail.html They were written and proposed by James Duncan Davidson, former Sun's leader for open source ventures, original author of Ant and Tomcat, ASF member and part of the Jakarta founders. In short they state: 1) any Apache committer has the right to propose the creation of an 'internal fork', stating a codename for it. 2) if the above is done, the community automatically grantes a location in the project CVS, normally under /proposal/[codename] 3) the 'internally forking' committer has the right, at any time, to call for a 'take-over' vote on the dev community: if passed with a majority of pending votes, the internal fork becomes the new codebase. This has been adopted in the past several times: 1) JServ 0.9.11 vs. JServ 1.0b (proponent myself! yes, JServ was created out of an internal fork and the community voted to take it over the old one!) 2) Tomcat 3.x vs. Tomcat 4.0 (proponent Craig McClanahan, codename Catalina, result: not yet clear even if the community voted in favor of Catalina) 3) Ant 1.x vs. Ant 2.x (proponent Peter Donald, codename ??, no vote placed yet... there are several proposals, actually) 4) Cocoon 1.x vs. Cocoon 2.x (proponent myself, codename Cocoon2 (sometimes called C2), result: 2.x took over 1.x) 5) Xalan 1.x vs. Xalan 2.x (proponent Scott Boag, codename Xalan2, result: 2.x took over 1.x) 6) Xerces 1.x vs. Xerces 2.x (proponent Andy Clark, codename Xerces2, result: no clear result, currently in a transition period, but 2.x will clearly take over 1.x) and, last but not least, 7) Apache 1.3.xx vs. Apache 2.0.x (proponent many, codename Apache two-'o', result: transition period, but 2.x will clearly take over 1.x) The trend is clear: Apache has been dealing with internal forks in the past so you're definately wrong stating that there is no space here for your development and there is no support for your effort. In case you need any help bootstrapping this effort of yours, I'll be very happy to give you a hand. Ah, for the proposal codename, I think Gregor would be really cool :) Tom, regarding > It does not seem ethical or even legal to take open > source software -- even if you were the original > architect -- and use it for your own purposes. As for legality, you are wrong in this respect: the Xalan license doesn't say anything about any restriction of use of the 'XSLTC' term, not even on the restriction of 'forking' the project (actually, I would not use a license which stops people from forking my code: it keeps me honest and them loyal!) As for ethic: everyone of us uses software for our own purposes. There's nothing wrong in that. The balance of open development comes from the fact that being selfish *is* also being altruistic, that is: I make my software open so that others contribute and help me out. I loose money, but I gain a huge development power.... in fact, a development power which would be far more expensive than the money I loose. This is why the model, if understood and applied correctly, works. This is exactly the reason why I'd like Jacek to do its internal fork within the Xalan community: we cocoon devs are not happy with Xalan-j performance-wise and we are not happy with XSLTC compliance-wise. Jacek wants to bring the two together and we will support him as much as we can. But if he chooses to fork the project externally, we'll be forced to fork it back into apache because otherwise, we fear of powerful code that lacks a community around it (see JClark's XT, for a great example) [hoping that Jacek keep the source of his changes open, which is not automatic since the ASF isn't viral in that respect] Hope this helps both of you to gain better knowledge of the Apache processes. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
