xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [spinnaker] Announce
Date Sun, 09 Jul 2000 15:36:18 GMT
All right, 

Duncan placed "the XML team at Sun" and all good intentions were sinked
by corporate shit. I was honestly surprised to see such a baby mistake
from one that taught me so much about human resource management and
diplomatic skills, but shit happens.

Is Spinnaker a "coup d'├ętat"?

This is the question, we'll answer this at the end.

I never worked in the Xerces team, nor I did any code contribution
(well, besides a very early Ant build file), nor I know the internals of
the code well, nor I partecipate in any of the xerces mailing lists.

So, since I don't consider myself entitled to speak for Xerces, I'll
make up an equivalent situation where I'd be entitled to speak.

Suppose that Cocoon2 is out, Stylebook is deprecated, but some people
don't like it. [This is a possibility I have to take into serious
consideration.]

So, since Cocoon2 is much more advanced than stylebook but not good
enough for their needs (whatever they are, it doesn't matter), they
decide to propose a new project that clones Cocoon2 functionality but
make it more similar to what they are used to.

This is the exact equivalent of what is happening with Xalan/Spinnaker,
as well as Tomcat/Catalina and happened with JServ0.9/JServ1.0,
Apache1.3/Apache2.0

This is called "internal forking" and Duncan wrote an excellent paper
about this called "rules for revolutionarists". (James, where is it?)

But let's continue with the Cocoon2 story: will I be happy for this
"internal forking"?

Honestly, no, I wouldn't be: some guy believes some of the decisions we
have taken are bad and they can do better. Instead of helping directly,
they feel it's better to fork or start off from scratch.

But while ego dissipates, I start thinking:

 1) they may have good points
 2) they will have less visibility (internal forks are not as visible as
main projects)
 3) they may come up with things I could reuse for the main project
 4) we may change their minds and incorporate the efforts later on
 5) or we may be blinded by our own ideas and die out

The question is: what is the most durable thing, the code or the
process?

The answer is obvious, expecially in IT where things move so fast.

I normally don't like revolutions but I did one: JServ 1.0 (award
winning!) came out of Pier's and mine intention of internal fork.
JServ0.9 was crap, we could do better, the history told us we did.

Do all internal forks terminate in a project take-over? no, almost
never. Catalina will become Tomcat 4.0, Cocoon2 (which is an internal
fork, in fact, I haven't written a single like of code yet on that
codebase) will be Cocoon-next, Apache2 will be Apache-next, and so on.

Will "codename Spinnaker" be Xerces-next? I don't know, nor care, to be
honest. The important part is that somebody is not feeling happy about
what a project and the process gives them the right to fork internally
and the ASF agrees to donate them resources to continue their quest.

If they _happen_ to work for one company or another, or if this is their
day job or night hobby, we (the Apache community) don't give a shit: the
only thing that counts is the outcome, we'll judge that one.

Will Spinnaker be smaller, faster and more modular? Great, we'll use it.

Will it sink? Great, we won't use it.

Egos are a big part of open source development and most of the time
revolutions create lots of friction... but when they happen they
_rarely_ do harm in the long term, expecially under Apache where several
internal forks happened but no external forks.

Internal forks happen when the development community is not responsive
enough nor willing to accept diversities.

When I proposed the JServ 1.0 internal fork, Ed Korthof (ed@apache.org)
at that time one of Jserv0.9 project coordinators judged the whole thing
with this sentence: "Enjoy your cathedral."

After JServ 1.0 became a successful project and boosted an incredibly
more successful community, Ed publicly apologized for not having
understood my intentions.

I've questioned myself many times: would have been possible to do JServ
1.0 without any revolution? I still don't believe so.

The problem is never in the code, but in the developer community.
Sometimes dev communities become closed, sellfish and oppose
diversities. (note, this has nothing to do with corporations or day
jobs, it just happens)

An internal fork is a way to go around the obstacle, it's a way to
"challenge" the power of the dev community a way to emerge and influence
the project.

If a group of individuals are capable of bootstrapping an internal fork
and reach the point where the community appreciate them more than the
original project, let this be.

Viva la diversitad!

Arnaud Le Hors wrote:
> 
> James Duncan Davidson wrote:
> >
> >     * Crimson isn't so optimized, yet it runs about as fast as Xerces
> >       does on modern VMs such as HotSpot. The HotSpot team told us
> >       that heavily optimized code for 1.1 would not benefit under
> >       HotSpot. We have the proof now. In fact, there's cases where
> >       it seems that Xerces slows down.
> 
> So far the only proof I've got is that Hotspot miserably fails on
> Xerces. This means to me that Hotspot has a problem, not xerces.

Bullshit. 

I used to optmimize x86 assembly code by hand for Pentium I dual
pipeline, then worked great for Pentium I but failed miserably with
Pentium II machines compared to what the C compiler produced
automatically.

If you JVM specialities to optimize your code that don't work anymore if
the JVM evolves, you are the mistaken one, not those who build a JVM
that should optmimize "normal code".
 
> >     * However, because Xerces was heavily pre-optimized, its
> >       extremely complex to understand and delve into. I think
> >       that this is best reflected in that most of the bits that
> >       go into Xerces come from IBM Cupertino.
> 
> Not so. What you're refering to as "IBM Cupertino" is hardly a fixed set
> of people. We've actually had a lot of turnover and we keep getting new
> people involved in this project all the time. This hasn't prevented any
> of them to contribute significantly. The only reason most bits come from
> IBM is that nobody else has comitted as many resources to this project.

I don't give a shit about who is paying whom to do anything as long as
what is being done is good for me. I'm happy with Xerces and I use it.
But if somebody is not, they have all the rights in the world to do
something about it and if the community is not open enough to listen, to
prove their points by creating new code and let the community decide.

This is _NOT_ a IBM vs. Sun thing and I suggest everyone on this list to
ignore any post that go in that direction.
 
> >     * In our analysis of the Xerces code base, we can't use it for
> >       future inclusion in the JDK. The pre-optimization is a killer.
> >       The code-complexity is a killer. And the memory consumption is
> >       a problem.
> 
> There definitely are choices that have been made that could be
> revisited. But you make it sound like we never took into account memory
> consumption. It is hardly the case. As you know there is always a
> trade-off between memory consumption and performance. You may have
> different requirements here, but they'd have to be laid out and agreed
> upon.

Sometimes is easier to write different code than to agree upon every
single bit. Expecially when everything becomes a "Sun vs. IBM" war.
 
> > So, in the best of Apache traditions, were gonna do something about it. I'm
> > creating a tree in the xml-contrib area in which to do a lot of code work to
> > explore how such a new parser could come to be. It's called Spinnaker.
> 
> Is it really in the Apache traditions to start new things like that over
> a week-end without having any discussion beforehand? Looking at Sun's
> record I guess I can see a trend for sure...

Get real. If this is your day-job that's good for you, but don't assume
everybody has your same status, nor live in the same place of the
planet.

Apache is a "worldwide community of software developping volunteers".

If you don't feel you fit in this category, this is your problem, not
ours.
 
> > So, to close a few thoughts...
> >
> > Q. Isn't this a slam on the Xerces guys?
> 
> I say yes. Looks like a "coup d'etat" to me.

A "coup d'etat" would be if the ASF ruled the XML parser project out to
start off a new project. This is not so, nor will _ever_ be.

Spinnaker is a way to express points with code and bootstrap a community
around a fresh codebase with the intention to improve what is already
existing. A clean-room implementation that hopes to bring ideas and
experience from all parties, along the spirits of Apache. A 2.0-version
that happens naturally within projects.

James assumed a couple of points in his announcement:

1) spinnaker is a "codename", not a project name. Spinnaker, if approved
by the community, will become Xerces 2.0.
2) the community rules: if users like Xerces more, Spinnaker will die.
3) internal forks don't get "full project" visibility. They have to gain
their visibility with code and community interaction on the mail lists.

At the hand, while I don't have anything to say on the technical side of
things, I judge this move very _healthy_ for the overall stability of
the Apache XML parsing community of developers.

Of course, this is a medium/long term vision and James is perfectly
aware of this. It might win or go nowhere, but if he has enough energy
to start this and back it up, we can only respect this and stay at the
window to see what they have to say.

The important thing is the quality of the process: quality in code then
happens naturally.

The Spinnaker effort will indicate if Xerces is stopping innovation or
not. Unfortunately, this is easier to do with revolutions that
evolutions so some competition friction will be developped, but as long
as this is kept respectful and any company racism is left out of the
picture, it'll be a good thing.

This is why I suggest you all to ignore any "this vs. that" corporate
bullshit.

[Note: I'm talking as a volunteer individual with no affiliation to
anything rather than himself]

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message