Jakarta-James Proposal for adoption as an Apache top-level project ---------------------------------------------------------------------- ---------------------------------------------------------------------- Preamble: ---------------------------------------------------------------------- To the Board of the Apache Software Foundation. We, the commiters of the Jakarta sub-project jakarta-james have held a vote and agreed to apply to you for elevation of our sub-project to the staus of a top-level Apache project. This document outlines details of our project, our community, and our reasons for wanting to take this step. ---------------------------------------------------------------------- Introduction to James: ---------------------------------------------------------------------- James is a 100% java Mail and news server. James provides highly configurable SMTP mail transport and local delivery into POP3 or IMAP accounts, utilising file system or database storage configurable on a per-repository basis. The jakarta-james sub-project hosts the Apache Mailet API specification The Mailet API is a Java API providing a framework for the conditional processing of mail and news messages. James implements the Mailet API, and as such is itself a platform for Mailet applications. Applications providing bespoke/custom mail processing, such as listservers, or providing gateways into other systems, messaging systems such as NNTP, SMS or proprietery messaging, or insertion into non-standard storage media. James itself provides a number of mailets performing condifgurable standard MTA services, such as aliasing and forwarding. ---------------------------------------------------------------------- Reasons for our application: ---------------------------------------------------------------------- General: ---------------------------------------------------------------------- Some believe that Jakarta is becoming too big to function as a single project, that community and culture become diluted as you descend the heirarchy and that one solution is for mature projects leave the nest. Of course other projects are free to make their own choices but as James consists primarily of the server which is an end-user product we feel that top level project status, emphasisng its function rather than its platform, would suit James well. The proposals being discussed on reorg & community include the notion of federated projects. We would like to think that we wouldn't be leaving Jakarta, just growing up. We also know that James would continue to rely on Jakarta for code, insight and knowekdge, but we don't need to be a Jakarta sub-project to benefit from that. ---------------------------------------------------------------------- Project Management: ---------------------------------------------------------------------- This proposal is more about management than web-site and mail addresses, we don't believe that james.apache.org will bring many direct benefits, but we do think that normalising our relationship with Jakarta by becoming a sibling rather than a child, and taking official control of all the issues we currently inherit and "interpret" from Jakarta would benefit James. James has a small yet mature self-sustaining community, we seldom seek recourse to the jakarta PMC, and equally seldom are we scrutinised by them. We are perhaps not the most active project, and some of us may feel that this sometimes causes James to be disregarded. Likewise, apart from Avalon, we have few direct ties with other jakarta projects. ---------------------------------------------------------------------- Profile: ---------------------------------------------------------------------- As outline above James is composed of three main Sub-Projects: Mailet API: Mailet Applications: ---------------------------------------------------------------------- History: ---------------------------------------------------------------------- ### TODO: SERGE you must know most of the history..? ### ---------------------------------------------------------------------- Future: ---------------------------------------------------------------------- Our vision of the future for James contains three main foci, 1/ To continually improve the performance and functionality of the core services. Currently focusing on making IMAP stable and increasing fault tolerance across the board. 2/ To promote the Mailet API as a standard API (providing portability to mail specific code) to all Java projects involved with processing email both OS and commercial, this will involve further isolating the Mailet API from any dependance on James or James' dependancies. And to continually support, refine and enhance the Mailet API in response to feedback from Mailet API users and Mailet developers. 3/ To build on James' Mailet packages in order to provide more, and more sophisticated, behaviours which would be available to any application implementing the Mailet API. These plans include: Providing functionality capable of reproducing services provided by commercial and open source competitors such as Microsoft Exchange, or ezmlm. Implementing a number of related services defined by RFC's, such as the email aspects of Icalendar, Vcard to name but two. And offering greater interoperability with other mail applications, such as sendmail. ---------------------------------------------------------------------- Our Community: ---------------------------------------------------------------------- The James community is small, but focused and self-sustaining, comprised of six active commiters, and six currently inactive. Only one of the active commiters, Serge Knystautas has been associated with the project since it started, and the continued success of James is no longer dependant on his continued participation. (Sorry Serge, mate, but thats a *good* thing!) Our developer community includes a number of Avalon contributers and commiters, and a number of people who are working with or on James in a commercial setting. Our user base is hard to quantify, but includes a wide cross section of different classes of users, from individuals through small enterprises looking for big enterprise mail functionality, commercial users adapting James or using James to provide bespoke services through to students using James in their coursework. We believe that this represents a healthy interest in James, and the fact that James continues to be of interest to so many groups inspite of the existence of email server software with much higer profiles, sendmail, exchange etc, is perhaps better proof of its worth than is its market share in comparison with those goliaths.