geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "n. alex rupp" <>
Subject Re: A thought on optimisation and project goals
Date Wed, 10 Sep 2003 15:22:07 GMT

I agree with the order of your goals, but there are some hitches in your
reasoning I'm concerned with.

> I also think that in order to address (3) there are benefits in linking
> up with as many other projects as possible, rather than develop a Not
> Invented Here syndrome.

It's very easy to toss around pat rhetorical phrases like "Not Invented Here
Syndrome", but this project is trying to build a certifiable J2EE stack.
The point being that someone must bear the direct responsibility of ensuring
the project's compliance, to the letter of the law (which we're still trying
to get our hands on, if I'm not mistaken) or else we will never accomplish
that goal.  Because we're trying to build and certify an entire stack, we
cannot responsibly demand that other projects hold their efforts directly
accountable to our members.  That runs contrary to our goals and to theirs.
On the other hand, we do have an extremely modular architecture which will
allow small teams to work on the separate subsystems and we have an open
door policy for contributions, so nothing's keeping existing ASF members
from becoming involved--everyone's welcome to help.

> I am not an Apache member, so I don't know The
> Apache Way (maybe someone can fill it in here), but what it means to me
> is that Apache builds projects that are useful, and that may then be
> integrated into other Apache projects.

You're not an Apache committer, but you are a member of the community, which
underlines my following point:  The goal of the ASF is to build a strong and
lasting *community* around technology, without which the technology will
die.  The hope is that strong communities lead to strong and *lasting*
technologies.  Weak communities can build strong technologies--for a time.
But Jason calls that place for a reason : )

Interoperability of the software is critical, which is why all of the
software is ASF licensed and made available to the rest of the community,
but there is no practical reason why development efforts cannot overlap.
Interoperability isn't mandatory.  That level of inbreeding would be
dangerous to the community.  Competition benefits both teams, and open
disagreement within the ranks is a sign of a healthy and functioning
democratic community.

> I know that the current focus is on (1) (and probably (2/3) as well)
> for the project, and so a getting-there-fast approach is probably a
> good idea. But let's not write off trying to use other parts (and keep
> them!) from the Apache projects when they're useful; after all, object
> orientation is mainly about reuse.

"Getting-there-fast" is probably more important for teams who've never "been
there" before--just to prove to themselves and everyone else they can "get
there" at all.  Nearly everyone on the current committers list has "been
there" before, and I'm certain they're comfortable with the speed at which
they're returning there.  The amount of discussion they contribute to the
list is a good indicator that the development is moving forward at a
satisfactory pace.

> I personally think that (4) should be the last point on the list, by
> some way. J2EE servers are going to be notoriously powerful beasts, and
> whilst it would be advantageous to run on constrainted hardware, I
> really don't think that's where the target customer base is going to
> be.

Not the point. Speed and scaleablity come from clusters.

View raw message