Thank you. And here's my +1.
Upayavira On Mon, 2008-06-02 at 08:47 -0700, Alan D. Cabrera wrote: > On Jun 2, 2008, at 8:18 AM, Upayavira wrote: > > > Please include proposal in this thread so that people don't have to go > > externally to see it. > > > > Regards, Upayavira > > > JSecurityProposal > > JSecurity Proposal > > Project Name: JSecurity > > Introduction > > This proposal seeks to create a top-level Apache Software Foundation > project to continue the development and advancement of the JSecurity > open-source framework. It has broad backing from the JSecurity > Community and unanimous backing from the current development team. > > We thank you for your consideration. > Key Features & Goals > > * > > The simplest and easiest to understand Java Security API > possible. > * > > Authentication (log-in) across one or more pluggable Realms > (JDBC, LDAP, etc), providing PAM (Pluggable Authentication Module) > functionality. > * > > Authorization (access control) via one or more of said Realms. > * > > Dynamic security model support allowing users, roles, and > permissions to be changed and assigned dynamically at runtime. > * > > Dynamic Instance-level access control - the ability to secure > individual instances (files, objects, users, etc) at runtime. > * > > POJO-based Enterprise Session Management - access to clustered/ > distributed/federated user sessions in web or non-web environments via > the same API. > * > > Heterogeneous client session access - access shared session > state across client mediums (web MVC, Swing, Flash, C#+SOAP etc). > * > > Simple SSO (Single Sign-On) support. > * > > Simple Cryptography API. > > 0. Rationale > > The current JSecurity community ([WWW] http://www.jsecurity.org) > fosters a positive environment of contribution, feedback and > supporting fellow members. Although already an open-source project for > the last 3+ years, the project as of late has grown quite > substantially over the last six months especially, and it is our > desire to see JSecurity be adopted by the Apache Software Foundation > to continue these efforts. We feel the ASF community will enable the > JSecurity project to reach higher adoption rates with better community > support beyond what we are able to accomplish ourselves. > > Furthermore, a significant number of Apache projects today could find > much benefit in JSecurity, as there is not currently anything in the > ASF that addresses its feature set as single unified project. We feel > that helping other Apache projects would create a symbiotic > relationship beneficial to the existing JSecurity community as well as > the ASF. > 0.1 Criteria > Meritocracy > > The JSecurity project will be meritocratic. The project will follow > the guidelines ([WWW] > http://apache.org/foundation/how-it-works.html#meritocracy) > of the Apache Software Foundation. In order to achieve this, we plan > on pro actively recruiting individuals in the Community to get > involved in the project: specifying work that needs to be done, > encouraging bug fixes, enhancements, and advancements, and engaging in > discussion on how the code works and is structured. In the end, we are > committed to creating an environment to foster a meritocracy. > Community > > JSecurity has had a small but active community for its first couple of > years after inception, with a significant increase in community > members the last 6 months. There are hundreds of posts in the forums, > some dating back over 2 years old. Current mailing list activity is > around 100+ messages per month and growing with the accumulation of > new contributors and users. It is expected that community growth will > only continue flourish as an ASF adopted project. > Core Developers > > All developers who have ever committed to the existing code repository > are still active on the current JSecurity team and will continue to > participate. They are: > > * > > Les Hazlewood > * > > Jeremy Haile > * > > Tim Veil > * > > Peter Ledbrook > * > > Allan Ditzel > > Alignment > > JSecurity is aligned well with Apache in terms of technologies and > licensing. It fits in well technologically with other Apache projects, > which also focus on clustering, web frameworks, and Java technolgies. > > We are sure there are quite a few ASF projects that could find utility > in JSecurity. Apache Tomcat might wish to enhance or simplify its > Realm functionality by using JSecurity's native support for multiple > back-end datasources. There has also already been mention of interest > by the Apache Directory TripleSec team in using JSecurity to support > LDAP integration as well as enable dynamic runtime support for > security users, roles, and permissions. > > Essentially any Apache project that utilizes log-ins, access control, > time-based Session access (in both web and non web environments), or > cryptography would find JSecurity beneficial. > 0.2 Warning Signs > Orphaned products > > JSecurity is already a 3+ year old open-source project with a long > history and currently in use in many open-source and commercial > software products. The interest from the respective communities that > use JSecurity (grails.org, et. al.) have continuously grown over the > last few years, with very heavy growth in the last 6 months. It is > expected that this community growth will only increase with the > adoption of the ASF, and the commercial products that use JSecurity > will continue to encourage and ensure its longevity. > Inexperience with open source > > The current committers have varying degrees of experience contributing > and/or committing to open source projects, including Spring ([WWW] > http://www.springframework.org > ), Hibernate ([WWW] http://www.hibernate.org), Grails ([WWW] > http://www.grails.org > ), and others. All have been involved with source code that has been > released under an open source license using an open source development > process to varying degrees. All current committers are comfortable > with normal meritocracy rules, as that is how the development team > informally operates now. We do not in any way expect any difficulty in > executing under normal ASF meritocracy rules. > Homogeneous developers > > All 5 current JSecurity committers works for different companies, with > no overlap. They live in different parts of the world, in the United > States and Europe. > Reliance on salaried developers > > The current committers are not compensated by their employers to > contribute to the project. One committer works for G2One ([WWW] > http://www.g2one.com/) > , the company behind the Apache 2.0 open-source Grails platform and > may contribute to the project on company time. Any such contributions > are provided with full knowledge and support of the company, with a > valid CCLA on file. > No ties to other Apache products > > Currently JSecurity has a required dependency on Apache Commons > Logging, with an optional dependency on Apache Commons BeanUtils Core. > > Also based on the above Alignment section, JSecurity could very > quickly become a part of many other ASF projects, ensuring a > successful future within the ASF. > A fascination with the Apache brand > > JSecurity started outside of the ASF under the LGPL license. The > development team voted unanimously to switch to the Apache 2.0 license > to foster a more open community, provide flexible options for > commercial deployment, and also to be eligible as an ASF project. > > 1. Project Scope > > The scope of the JSecurity project would be the continued development > of JSecurity technology core infrastructure software, including the > related utilities and tools. The development would include adding new > features and improving performance, scalability, quality, and > extensibility. > > 2. Initial Population Source > > The initial resources would be garnered from: > > * > > JSecurity SourceForge repository > o > > ([WWW] http://sourceforge.net/projects/jsecurity/) > > 3. ASF Resources Requested > 3.1 Mailing lists > > * > > jsec-private (with moderated subscriptions) > * > > jsec-user > * > > jsec-dev > * > > jsec-commits (scm = Software Configuration Management for SVN > commits, automated build notifications, et. al.) > > 3.2 Revision Control System > > JSecurity would like to use a Subversion repository: [WWW] > https://svn.apache.org/repos/asf/incubator/jsecurity > 3.3 Issue Tracking > > Since JSecurity would have its own release cycle, it should have its > own JIRA project > > * > > Project Name: JSecurity > * > > Project Key: JSEC > > 4. Initial Comitters > > * > > Alan Cabrera ([MAILTO] [EMAIL PROTECTED]) > * > > Les Hazlewood > * > > Jeremy Haile > * > > Tim Veil > * > > Peter Ledbrook > * > > Allan Ditzel > > 5. Sponsoring Individual > > We kindly request the Apache Incubator PMC to be the sponsor for this > project. > Champion > > * > > Alan D. Cabrera > > Mentors > > * > > Alan D. Cabrera > * > > Paul Fremantle > * > > Alex Karasulu > * > > Emmanuel Lecharny > * > > Craig Russell > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
