> I think you might be missing the big picture. James > is already (I stand corrected, it's not dead) in idle > mode. My feeling is that new development cannot > happen with the current committers not committing > anything. Unless they let other (active) developers > in, they are nothing more than sourceforge-squatters. > Case study: FreeBSD vs. DragonflyBSD.
No, I see your big picture ... sadly you do not see mine. James is not idle - there is a tremendous amount of work going on. You need to understand this is not a question of letting in active developers, but letting developers who actively support James and share it's vision to contribute time and effort to promote and propel James down it's path. --> Neither do lengthy discussions pitting one --> technology against another. > Could you please elaborate? If you are defending the > Avalon beast, I have nothing to add. Except, that > having to rely on deprecated components is not a good > thing and does tarnish James's image. The short version is that I see no benefit in discussing which new technology to use to replace part or all of James' interfaces and my remark was geared to that instead of attaching Avalon for example. > Yeah, but the growth part ain't happening and it won't > without active players. James won't grow without players actively supporting James. My position is that writing code is a small part of what James needs. All code that we accept into James needs to be what James needs (Break/Fix), what James is developing (new features), and what James is moving into. I believe that today's Open Source is no longer the free willy-nilly that one was, but is now a more structured project with deliverables and responsibilities, and because of this, we need to exercise more restraint and actively reject brilliant work if it does not fit into the James Vision or ASF model. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
