cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: experimental XSLTC-2, a clarification
Date Thu, 07 Mar 2002 00:47:37 GMT
"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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message