Alex, 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 SourceForget.net 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.
