On Tue, May 12, 2009 at 11:36 AM, A. Rothman <[email protected]> wrote: > > I think JAMES is currently in a deadlock of sorts regarding contributors. My > base assumptions are - > > > 1. The only usable version of JAMES at the moment is 2.x. Other than core > developers, very few users will checkout trunk on some random day and use > that as a production system. 3.x is off-limits for normal users, at least > until there's some milestone release they can depend on.
i know of projects downstream that use 3.0. also a number of developers use 3.0. > 2. No one is going to contribute to 2.x. As everyone here seems to agree - > while it may be battle-worn (in the good stable sense), it is a dead-end > development-wise, and not even the core developers want to mess with it, for > all the reasons we stated earlier. It's abandoned. it's not abandoned - it's just mature bugs are fixed and minor improves backported (see https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10411&styleName=Html&version=12312493) if there are contributors willing to test a new release then it might be possible to cut a 2.3.2 sometime soonish > 3. Contributors contribute to projects they use. As a consequence of being a > user, they stumble upon bugs and enhancements, hopefully report them, and > even more hopefully contribute solutions themselves. If they don't use a > project, the chances of contributing as an academic exercise is slim. the libraries (IMAP, mime4j, jsieve, jspf) have downstream users and are more accessible for new developers. i would like to see more services factored out into reusable, OSGi enabled services but i doubt that this view is a consensus one. > From these 3 assumptions, the potential contributor's deadlock is evident - > he will be willing/able to contribute only to 3.x, he will be willing/able > to actually use in his project/production systems only a 2.x, and since it's > unlikely that he'll develop for a product he doesn't use, he thus he won't > contribute at all, and keep bitchin' on 2.x being dead and 3.x not getting > anywhere, because no one else will either. While this is a generalization, I > think it does apply to many if not most potential contributors. > > How do u break this deadlock? In my opinion - by making a 3.x release. Even > a Beta. the conventional terminology here at apache would be a milestone. > It can get early adopters to adopt, send the message that it's > becoming ready for the average user, and start the use-interact-contribute > cycle that's necessary for the project to get back on track. james has been short of contributors willing to push any 3.0 releases after the explosion IMHO a major consequence of the explosion was that obtaining the consensus required to release became improbably (until enough time has passed and enough new contributors emerged). time has passed but very few contributors have emerged for the server (unlike the libraries). > What should be included in such a release? what do users want? As a start, > I'd say a Java mail server. That's what users search for when they find > JAMES. SMTP/POP3 and a DB backend. No fancy bells and whistles just yet. A > bare-bones replacement for 2.x. 2.x already works very well for this we've discussed issues a stripped down 3.x but without deciding on a new framework to replace avalon, it seems a little pointless... > And as can be seen from some other Java mail > server projects mentioned here or googled, that's shouldn't become a 3-year > project, but a rather modest goal for a handful of core developers. james already has a SMTP/POP3 server that's proved production ready with an advanced architecture: it's called 2.3.1. the basic SMTP/POP3 code's fine (and the 3.x code is essentially the same). there's no reason to rewrite it. but if you're interested just in POP3 and SMTP - please start contributing (james is very short of active developers in that area). i'm confident that just a few more interested contributors in this area would make a big difference. > One only needs the very basics that will bring 3.x into the spotlight as an > alternative to 2.x, and after things get into motion it can take off to many > creative directions. if that's your vision for james, then go for it! start contributing and push for it :-) IMHO it'd be much easier to start with solid, production ready SMTP and POP3 code and just polishing it up than working on a new implementation otherwise, those developers whose interest lies in those creative directions will just continue pushing the 3.x code onwards - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
