The Apache Software Foundation Board of Directors Meeting Minutes - DRAFT January 22, 2003 1. Call to order The meeting was scheduled for 10am PDT -0800 and was begun when a sufficient attendance to constitute a quorum was recognized by the chairman at 10:10am. The meeting was held by teleconference hosted by Jim Jagielski (Covalent): IRC #apacheboard on irc.freenode.net was used for backup purposes. 2. Roll Call Directors Present: Brian Behlendorf Ken Coar Roy T. Fielding (arrived at 11:02am) Jim Jagielski Sam Ruby Greg Stein Bill Stoddard Directors Absent: Dirk-Willem van Gulik Ben Laurie Guests: Chuck Murcko Davanum Srinivas 3. Minutes and supplements from previous meetings A. The meeting of December 18, 2002 See board_minutes_2002_12_18.txt in cvs.apache.org:/home/cvs board. These minutes were not approved at this time since not all directors had read and reviewed them. 4. Officer Reports A. Chairman [Greg] Greg reported on the refactoring of the XML Project and was mostly pleased with the current status of most of the ASF projects. B. President [Dirk] No report. C. Treasurer [Chuck] Chuck had nothing to report. D. Exec. V.P. and Secretary [Jim] Jim reported that the ASF office had received some signed CLAs and License Assignments, mostly for the Jakarta subprojects. These were noted to the subprojects as a matter of course. Jim also reported that the POP3 Protocol module, which was developed by Ryan Bloom and a version of which is currently under CVS, is, in fact, covered under the Apache License. There was some discussion of whether this was the case. 5. Committee Reports A. Apache DB Project [Jason van Zyl] See Attachment A. By general consent, this report was recorded as entered and approved. B. Apache TCL Project [David Welton] See Attachment B. By general consent, this report was recorded as entered and approved. C. Conference Planning [Ken Coar] Ken reported on the growing frustration with Security Travel. Feedback on the conference itself has been favorable, yet Security's responsiveness on post-conference details has been less than acceptable at times. Preliminary results indicate that ApacheCon 2002 may not show a profit. D. Security Team [Ben Laurie] See Attachment D. By general consent, this report was recorded as entered and approved. E. Ant Project [Conor MacNeill] See Attachment E. By general consent, this report was recorded as entered and approved. Discussed at this phase was the growing need for a universal set of Bylaws, or at least a boilerplate Bylaw that all projects and subprojects could use. There was also some discussion regarding the use of 'authortags' in codebases and whether it was useful, beneficial, harmless or harmful. F. Avalon Project [Nicola Ken Barozzi] See Attachment F. By general consent, this report was recorded as entered and approved. 6. Other Reports A. Sam Ruby -- discussions with the PHP Group Sam reported that the PHP group, in general, would favor a move to v2.0 of the Apache License. However, a move to more fully follow normal ASF project considerations would be difficult. PHP enjoys its own infrastructure, CVS policies and community, separate and distinct from the ASF. It was further discussed whether it made sense for PHP to be considered a "sister project" to the ASF rather than a "real" ASF project. The general consent was that was the most likely end result but that discussion would continue. B. Status update on Peter Donald's suspension. The board was brought up to date on Mr. Donald's suspension. A key point was his insistance on certain statements being made out of context or even completely fabricated yet "forbidding" the board and others from posting the Emails and discussions which would prove matters once and for all. 7. Special Orders A. Creation of the Apache Cocoon Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the Apache Cocoon framework, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Cocoon PMC", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Cocoon PMC be and hereby is responsible for the creation and maintenance of the Cocoon framework and related software components, subject to a revised charter, based on software licensed to the Foundation; and be it further RESOLVED, that the office of "Vice President, Apache Cocoon" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Cocoon PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Cocoon PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Cocoon PMC (in alphabetical order by lastname): Nicola Ken Barozzi (nicolaken@apache.org) Marcus Crafter (crafterm@apache.org) David Crossley (crossley@apache.org) Torsten Curdt (tcurdt@apache.org) Bertrand Delacrtaz (bdelacretaz@apache.org) Vadim Gritsenko (vgritsenko@apache.org) Christian Haul (haul@apache.org) Bernhard Huber (huber@apache.org) Matthew Langham (mlangham@apache.org) Berin Loritsch (bloritsch@apache.org) Stefano Mazzocchi (stefano@apache.org) Michael Melhem (michaelm@apache.org) John Morrison (morrijr@apache.org) Steven Noels (stevenn@apache.org) Andrew C. Oliver (acoliver@apache.org) Giacomo Pati (giacomo@apache.org) Konstantin Piroumian (kpiroumian@apache.org) Ovidiu Predescu (ovidiu@apache.org) Jeremy Quinn (jeremy@apache.org) Gianugo Rabellino (gianugo@apache.org) Peter Royal (proyal@apache.org) Diana Shannon (shannon@apache.org) Sylvain Wallez (sylvain@apache.org) Jeff Turner (jefft@apache.org) Carsten Ziegeler (cziegeler@apache.org) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Stefano Mazzocchi be and hereby is appointed to the office of Vice President, Apache Cocoon, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Cocoon PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Cocoon Project. RESOLVED, that the initial Apache Cocoon PMC be and hereby is tasked with the migration and rationalization of the XML PMC Cocoon subproject; and be it further RESOLVED, that all responsibility pertaining to the XML Cocoon sub-project and encumbered upon the XML PMC are hereafter discharged. By Unanimous Vote, the above Resolution Passes. B. Creation of the Apache James Project Please see the additional commentary provided in Attachment G. WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the Apache James E-Mail server and the Apache Mailet API, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache James PMC", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the James PMC be and hereby is responsible for the creation and maintenance of software related to the Apache James Mail and News server, the Apache Mailet message processing API, and related software components based on software licensed to the Foundation; and be it further RESOLVED, that the office of "Vice President, Apache James" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache James PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache James PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache James PMC: Serge Knystautas Danny Angus Peter Goldstein Noel Bergman Charles Bennet NOW, THEREFORE, BE IT FURTHER RESOLVED, that Serge Knystautas be and hereby is appointed to the office of Vice President, James, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache James PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the James Project; and be it further RESOLVED, that the initial Apache James PMC be and hereby is tasked with the migration and rationalization of the Jakarta PMC James subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta James sub-project and encumbered upon the Jakarta PMC are hereafter discharged. By Unanimous Vote, the above Resolution Passes. C. Creation of the Web Services Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to Web Services, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Web Services PMC", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Web Services PMC is be and hereby is responsible for software related to the provision and discovery of application program interfaces made available via HTTP (and others like SMTP, JMS) and whose requests and responses are usually formatted in XML. The technologies relevant here are those typically associated with "Web Services" by the popular IT press, such as SOAP, XML-RPC, UDDI, WSDL, and others. Based on software licensed to the Foundation; and be it further RESOLVED, that the office of "Vice President, Web Services" be and hereby is created, the person(s) holding such office to serve at the direction of the Board of Directors as the chair of the Web Services PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Web Services PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Web Services PMC: David Chappell Glen Daniels Anthony Elder Jeremy Hughes Tom Jordahl Erwin van der Koogh Ted Leung Steve Loughran Christian Geuer-Pollmann Axl Mattheus Nirmal Mukhi Scott Nichol Daniel Rall Sam Ruby Alek Slominski James Snell Davanum Srinivas Sanjiva Weerawarana NOW, THEREFORE, BE IT FURTHER RESOLVED, that Davanum Srinivas be and hereby is appointed to the office of Vice President, Web Services, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Web Services PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Web Services Project; and be it further RESOLVED, that the initial Web Services PMC be and hereby is tasked with the migration and rationalization of the XML PMC Axis, SOAP, Security, and XML-RPC subprojects; and be it further RESOLVED, that all responsibility pertaining to the XML Axis, Soap, Security, and XML-RPC sub-projects and encumbered upon the Web Services PMC are hereafter discharged. By a vote of 6 For and 1 Against, the above Resolution Passes. 8. Unfinished Business 9. New Business 10. Announcements The following new members were elected to the Jakarta PMC: Nicola Ken Barozzi Robert Burrel Donkin Stephen Colebourne Martin Cooper Henri Gomez John Keyes Larry Isaacs Otis Gospodnetic Thomas Mahler Remy Maucherat Glenn Nielsen Andrew C Oliver Rob Oxspring Martin Poeschl Scott Sanders David Sean Taylor Glen Stampoultzis Mladen Turk James Turner Henri Yandell 11. Adjournment Scheduled to adjourn by 11:30 PDT -0800; adjourned at 11:56am. ============ ATTACHMENTS: ============ ----------------------------------------- Attachment A: Status report for the Apache DB Project As yet there is no site or charter for db.apache.org but I wanted to assure the board that the desire to bring db.apache.org to fruition hasn't waned. I know that all the the PMC members have been busy with their projects and I would like some things to happen before the site is launched. I would like the site to be generated as changes are made to the individual projects in as much an automated fashion as possible. I want to be notified of exceptions: I don't want anyone to have to manage this manually. I do not want to foist yet another disparate, incoherent website on an unsuspecting crowd. I would like db.apache.org to be an example of what an OSS website can be. I also don't want this process to consume my life, or anyone else's. To this end, over the last while I've been working on Maven, Plexus, Continuum and have hired Bob McWhirter to improve Drools and create Werkflow: the only OSSPetrinet-based workflow engine that I'm aware of. I'm using all these tools as part of my daytime work but slight adjustments have been made here and there to accomodate things I would like for db.apache.org. I would like the site and infrastructure to be manageable from day one. If there were projects that were planned to be released for the first time on db.apache.org then I would certainly be guilty of not pushing hard enough to get the site, charter and infrastructure in order. But none of the projects that are initially taking part are being dealt any life threatening blows due to the non-existence of the db.apache.org site. I would like the PMC to have the time to get the project together as we see fit. I realize that the DB PMC has not made much progress on the infrastructure side but none of us have been idle. I am trying to make some tools I think will be valuable and genuinely help. Axion, Torque, and OJB are also getting in a lot better shape to the point where real releases could be made available when the site launches which I think is a good thing. I myself can't commit to a date for the launch (someone else may want to) as this is purely volunteer and my day job takes precendence but I think it holds true that each of the PMC members want to see this happen. If it is the case that we must have something by a date to satisfy the board then I will not personally commit and will let someone else commit and take over the chair position. I feel I would rather wait and make something worthfile then procure something to satisfy an artificial requirement. As I noted before, I don't think any harm is being done by not launching. As an aside I'm curious as to the history surrounding the nascent Jakarta and XML projects? Were there in fact deadlines or was the time taken to get things in order properly? If we need things like the charter then we could probably borrow one from an existing project and ratify it in short order, but I would still like to wait on the launch of the site. --- [1] Maven: http://jakarta.apache.org/turbine/maven [2] Plexus: A application container based on Avalon. Maven will eventually be a Plexus application. [3] Continuum: A continuous integration tool using Plexus, Drools, and Werkflow [4] Drools: OO-Rete based rules engine. [5] Werkflow: Petrinet-based workflow engine using Drools. ----------------------------------------- Attachment B: Status report for the Apache TCL Project The Apache Tcl project continues to move along, slowly, but surely. Most of the recent work has gone into Rivet and mod_dtcl. Thanks to Randy Stanard, we now have a new logo for Rivet, and soon we hope to have one for Apache Tcl as a whole (which will probably be some combination of the Tcl feather plus the Apache one). Rivet is now available as a download, and we are working towards stabilizing it, especially on the windows platform, in order to do a real release. NeoWebScript is heading for mothballing, sooner or later. mod_dtcl will also be phased out in favor of Rivet as the latter continues to stabilize. This will help bring down the number of codebases to a more manageable three, instead of the current 5. After voting on the idea of accepting projects that are not necessarily related to C code that ties together the web server and Tcl, we have begun looking for interesting candidates, although to date we haven't started down this path with any codebases. We are trying to be very selective. Some of the projects we have talked with include tclhttpd, tclxml, and the people responsible for starkits (a system for deploying a tcl/tk system in one file). There are no outstanding legal issues or with people involved in the project. ----------------------------------------- Attachment C: Status report for the Conference Planning Committee There is no Attachment C. ----------------------------------------- Attachment D: Status report for the Security Team The security team now has its own mailing list (security-team@apache.org), for discussion of team business and _not_ security issues. security@apache.org is still the primary contact for security issues, which are then dispatched to the security list for the appropriate (sub-)project. These are being set up on a piecemeal basis, as needed for new security issues, and are of the form -security@apache.org, security@.apache.org or -security@.apache.org. This diversity is regrettable, but needed in order to match the list to the correct audience, without breaking intuitiveness of naming. security@apache.org is subscribed to _all_ these mailing lists, so the core security team remain aware of developments. So far these lists only exist for httpd and Tomcat, but this is probably a good thing, so we can work out any wrinkles in the plan without having to modify dozens of lists to conform. There is also a CVS repository, security, which is used to (manually) track the status of reports. It is currently proposed to break this into subdirectories for each (sub-)project, with group access as appropriate to the subdirectory (which I support, but has not yet had time for discussion). I've also unilaterally adopted a numbering scheme for tracking reports, of the form AST-yyyymmdd(-nn), with no complaints yet heard. Although it is early days, it seems clear that this system has already resulted in two clear positive benefits: a) issues are not getting (permanently) dropped on the floor b) issues are being dispatched to the project teams and are no longer summarily dealt with by the security core team. ----------------------------------------- Attachment E: Status report for the Ant Project o Ant 1.5.2 Recent discussions on the dev list has settled that 1.5.2 will primarily address the Jar update bug. Once this has been fixed, 1.5.2 will be released and will include all other bug fixes committed to that date. That will then be the final 1.5 release barring discovery of new urgent problems. o Ant 1.6 Still expecting a release around Mid year. The strategy for this release will be to complete new core functionality in the first quarter and then leave the core to settle. Since these are core changes , I envisage a long beta cycle to get these changes well tested. Recently an task has been implemented. This is still experimental and has thrown up some issues regarding the resolution of file paths in the importedbuilds. It is not clear if import should be a straight include mechanism or it should support the composition of projects into larger projects, each with its own basedir and property namespaces. currently does a bit of both theseroles. Other goals for new functionality in the Ant core include * Some form of ant library mechanism. We have pretty much settled on associatinglibraries with XML namespaces to give each library of tasks its own namespace toavoid collisions and to allow a build to specify the libraries it uses (via namespace declarations) * Support for polymorphic types. This may not be included in the 1.6 release, if we consider that the core has already changed significanly. * Delayed Task construction, Top levels tasks, etc. These are implemented and seem relatively stable. o ant.apache.org site The site is live but still in development. This hasn't stopped us getting bug reports about its XHTML compliance :-). One of the Ant committers has developed a stylesheet for Anakia to give the site a Forrest look and feel (so called FakeForest). No decision has been taken to adopt Forrest at this time, however. o Bylaws I haven't done much work on the bylaws so these will probably not be ready by end Jan, as stated in the last report. I think this is the area where the board can be of most assistance. As I said in that report, as more projects move to the Top level, it does not make sense for each project to develop a new set of bylaws, guidelines, etc. This is something I think should be standardised across projects. Not only would it eliminate duplication, it would reinforce the concept of an "Apache Way". If each project adopts its own version of the bylaws, that concept will be diluted and differences emerge. o Legal Issues No new issues. o Outstanding bugs and patches Stefan and I are working through the bug reports. Still a large number outstanding. o Community Community on both the ant-user and ant-dev lists is very strong, with much active discussion taking place without any flamage. ----------------------------------------- Attachment F: Status report for the Avalon Project Out project STATUS file ------------------------- http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/STATUS.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup Diff between this and last report: http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/STATUS.txt.diff?r1=text&tr1=1.13&r2=text&tr2=1.21&diff_format=h Additional info for the board ------------------------- * What code releases have been made? Phoenix has been released to fix some bugs. We will soon release Fortress. We now have a tentative roadmap to a single container, and Fortress will be the first step. * Any legal issues to bring to the board? AvalonDB, part of Avalon Apps, will want to move out of Apache and have the license be reassigned to the authors-contributors of that codebase. Pending the request of the authors for this, I'm asking if the board would have the intent to grant such a copyright change to the original authors, specifying if the adoption of an Apache-like license would influence this decision. * Any cross-project issues that need to be addressed? We are progressively getting rid of projects that are not in scope. AltRMI has asked Incubator to be relocated, but has not asked for a target location. We will decide base-by basis about where to move them. * Any problems with committers, members, etc? There is growing unrest for some, due to uncertaincy about Peter Donald's status. In my past report I saw that the one that were originally were resisting change were partecipating in it actively. To be more precise this time, if we talk about changes in the technical project direction, it still applies. The problem is about new community rules we are deciding on. The focus on good code instead of good community is still very rooted in some committers. * Plans and expectations for the next period? For the first time in weeks, decisions started to appear without strong discussions, like the one about the project roadmap. This is a good sign, so I expect that we will follow that roadmap and work actively towards a container effort done with all the community. We will be probably creating a Component subproject where projects that use Avalon can contribute in maintaining the Avalon components they use. This would be the first step towards a future unified Component repository. * etc (your own thoughts on what is important would be helpful!) The 3 month suspension of Peter Donald is coming to an end, and we don't see a resolution to the issue. This is starting to hurt. He hasn't appeared to change the same disruptive patterns seen before, and has again said that he was not informed about the reason of the suspension. I see two trends now, a positive one about the advancement of the community, and a negative one incentrated on the suspension of Peter Donald. Things are now moving (still slowly) in a single direction, except for the suspension afromentioned. A recent discussion on @author tags has ignited a very strong discussion [1].Recognition in the form of @author tags is so deeply rooted that it has been percieved by some as if all code and documents of the project were to be cleaned of any reference to committers. It's quite clear to me that it disturbes some that "perfectly good code" is being abandoned "just because it's a one-man codebase". My feeling is that it will change when we will see tangible results from the new effort. As for me, I'll try to keep a somewhat lower profile now that all major issues have been addressed, and concentrate on the application of these decisions, in any way I will feel that the community would prefer. [1] http://marc.theaimsgroup.com/?t=104297259700001&r=1&w=2 --------------------------------------------------------------------- ----------------------------------------- Attachment G: Supporting commentary for creating Apache James The following text was received by the Board, in support of creating the Apache James PMC. Jakarta-James Proposal for adoption as an Apache top-level project ---------------------------------------------------------------------- ---------------------------------------------------------------------- Preamble: ---------------------------------------------------------------------- To the Board of the Apache Software Foundation. We, the committers 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 status 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, evolving into a complete electronic messaging solution that integrates the range of IETF protocols, such as SMTP, POP3, IMAP, NNTP, and XXMP with unified user account management and open storage mechanisms. James provides highly configurable SMTP mail transport and local delivery into POP3 or IMAP accounts, utilizing 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 electronic messages. James implements the Mailet API, and as such is itself a platform for Mailet applications. Mailet applications include providing custom mail processing, such as list servers, or providing gateways into other systems, messaging systems such as NNTP, SMS or proprietary messaging, or insertion into non-standard storage media. James itself provides a number of mailets performing configurable standard MTA services, such as aliasing and forwarding. ---------------------------------------------------------------------- Reasons for our application: ---------------------------------------------------------------------- General: ---------------------------------------------------------------------- James is a mature, self-determining project that is able to govern itself under the auspices of the ASF Board in accordance with ASF bylaws and guidelines. As James consists primarily of the server which is an end-user product we feel that top level project status, emphasizng its function rather than its platform, would suit James well. Top level project status would also facilitate the ability to offer the Mailet API as a separate specification, of which James would represent only a reference implementation. James would continue to work closely with the Avalon Project, and is establishing ties with the Cocoon and BSF projects to integrate some of their technologies within James. ---------------------------------------------------------------------- Project Management: ---------------------------------------------------------------------- James has a small yet mature self-sustaining community. We seldom seek recourse to the Jakarta PMC, and equally seldom are we scrutinized 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. We believe that normalizing our relationship with the ASF Board by reporting directly rather than through the Jakarta PMC, and taking official control of all the issues we currently inherit and "interpret" from Jakarta, would benefit James. ---------------------------------------------------------------------- Profile: ---------------------------------------------------------------------- As outline above James is composed of three main areas. JAMES server Sub-Projects: Mailet API Mailet Applications ---------------------------------------------------------------------- History: ---------------------------------------------------------------------- JAMES was originally envisioned and placed as a holding page on java.apache.org, before Jakarta was organized. Individuals (unfortunately names forgotten at this point) had submitted a proposal to the (HTTP) servlets group at Sun to provide mail handling. They rejected the proposal for technical reasons. Serge Knystautas later donated a Java SMTP server implementation that became the original code base for JAMES. The mailet API was heavily discussed and finalized, the original code was massively re-factored and improved, and a POP3 implementation was added. JAMES was later re-factored to use the new Avalon code base. JAMES also received a donation of an NNTP implementation. JAMES has slowly added new mailets, improved reliability and scalability, SMTP AUTH, FetchPOP, and other feature enhancements since then. ---------------------------------------------------------------------- Future: ---------------------------------------------------------------------- Our vision of the future for James contains five main foci, 1/ To continually improve the performance and functionality of the core messaging 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 dependence on James or James' dependencies, and to continually support, refine and enhance the Mailet API in response to feedback from Mailet API users and Mailet developers, for example to cover message domains other than e-mail. 3/ To build on James' Mailet packages in order to provide more, and more sophisticated, behaviors which would be available to any application implementing the Mailet API. 4/ Provide a common message repository abstraction to all of James' protocol servers (e.g, SMTP, POP3, NNTP and IMAP) and support standard repository data formats like maildir and mbox to ease migration to James. 5/ Provide a common user repository abstraction to all of James' protocol servers. 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 and 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 committers, and six currently inactive. Only one of the active committers, Serge Knystautas, has been associated with the project since it started, and the continued success of James is no longer dependent on his continued participation. Our developer community includes a number of Avalon contributors and committers, 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 course work. We believe that this represents a healthy interest in James, and the fact that James continues to be of interest to so many groups in spite of the existence of email server software with much higher profiles, sendmail, Microsoft Exchange, etc., is perhaps better proof of its worth than is its market share in comparison with those goliaths. ---------------------------------------------------------------------- Conclusion ---------------------------------------------------------------------- We believe, as we hope we have shown, that James is a mature and worthwhile candidate for inclusion as a top level Apache project, and hereby take the opportunity of presenting our proposal for consideration by the Board of Directors. On behalf of The James committers, Danny Angus Charles Bennet Noel Bergman Peter Goldstein Serge Knystautas __________________________________________________________ End of minutes for the 22 Jan 2003 board meeting.