You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-cvs@jakarta.apache.org by hu...@apache.org on 2002/01/15 00:37:25 UTC
cvs commit: jakarta-site2/xdocs/site newproject.xml
husted 02/01/14 15:37:25
Modified: xdocs/site newproject.xml
Log:
Commit latest version of revised new product page.
Revision Changes Path
1.6 +189 -136 jakarta-site2/xdocs/site/newproject.xml
Index: newproject.xml
===================================================================
RCS file: /home/cvs/jakarta-site2/xdocs/site/newproject.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- newproject.xml 20 Oct 2001 15:03:28 -0000 1.5
+++ newproject.xml 14 Jan 2002 23:37:25 -0000 1.6
@@ -3,100 +3,110 @@
<properties>
<author email="jon@latchkey.com">Jon S. Stevens</author>
+ <author email="husted@apache.org">Ted Husted</author>
<title>New Project Proposals</title>
</properties>
<body>
-<section name="Introduction">
+<section name="Subproject Proposals">
+
<p>
-This document will attempt to describe the criteria for what it takes to
-get the members of the <a href="whoweare.html">Jakarta PMC</a> to accept
-the creation of a new top level project within the Jakarta Project. This
-document does not describe what it takes to get into the <a
-href="/commons/">Jakarta Commons</a> project because there is a whole
-separate set of rules over there that have been hashed out separately.
+Not every software product is suited for life at Jakarta. Before proposing
+a new subproject, it is important to read this document carefully and determine
+whether your product is a good fit.
</p>
+
</section>
<section name="Criteria">
<p>
-Jakarta has a high threshold for creating new projects.
+Here are some best practices that we will expect to find in a successful
+proposal. This is not a checklist, but guidelines to help communicate what
+is expected of a Jakarta subproject.
</p>
<p>
-Over the years the members of the PMC have established a base set of
-criteria for acceptance into the Jakarta project. The criteria is not a
-hard strict set of rules. Instead, it is based on the fundamental belief
-that Jakarta is more than what something like Sourceforge.net is.
+<strong>Meritocracy.</strong> Before submitting a proposal, be sure to study
+the guidelines that <a href="guidelines.html">govern Jakarta subprojects</a>.
+These guidelines explain our system of Meritocracy, which is the core
+of the Jakarta Project. If the product developers do not wish to adopt
+this system, then they should <strong>not</strong> donate their code
+to the Project, and should look elsewhere for hosting.
</p>
<p>
-The Jakarta community is primarily developers who like to focus their
-efforts towards Java server side technologies where Sourceforge.net is
-more of a general place for anyone to host any type of project. Please
-note, this is not a negative view on the service that Sourceforge.net
-provides to the open source community, it is simply a statement which
-reflects the actual focus and differences between the two.
+<strong>Community.</strong> Jakarta is a Project of the
+<a href="http://apache.org">Apache Software Foundation</a>. A prime purpose of
+the ASF is to ensure that the Apache projects continue to exist beyond the
+participation of individual volunteers. Accordingly, a prime criteria required
+of any new subproject is that it already enjoys -- or has a high potential for
+attracting -- an active community of developers and users.
</p>
<p>
-The Jakarta PMC is the group of volunteers who have stepped up to take
-leadership roles over the long term health of the Jakarta project. As a
-result, the rules for adding a new project also hinge on how well the
-people submitting the proposal can convince the PMC to accept it. At
-some level, the Jakarta project is a living entity with its own
-personality. Projects with excellent proposals may still be rejected
-because of things as seemingly mundane as personality conflicts between
-developers.
+Proposals for non-established products have been accepted, most often when
+the proposal was tendered by experienced open source developers, who understand
+what it means to build a community.
</p>
<p>
-In order for a new project to be considered, a proposal must be sent to
-the general@jakarta <a href="mail.html">mailing list</a>. All discussion
-about the proposal should also happen there.
+A design document, developer and user documentation, example code, and a
+working implementation all help to increase the likelihood of acceptance.
+Well-documented products tend to build stronger communities than
+products that rely source code and JavaDocs alone.
</p>
<p>
-The proposal submitter(s) should be well versed in the policies that <a
-href="guidelines.html">govern the way that the Jakarta project is
-run</a>. This is important because these are the rules that govern how
-your project will need to be run. If the proposal submitter does not
-agree to them, then looking elsewhere is wise.
+<strong>Core Developers.</strong> To considered, a product must have
+at least 3 active developers who are already involved with the codebase.
+This is an absolute minimum, and it is helpful for there to more than
+three developers. It is <strong>very</strong> helpful for at least one of the
+developers making the proposal to already be active in a Jakarta subproject or
+other open source initiative.
</p>
<p>
-One of the most important criteria's for acceptance is for the proposal
-submitter(s) to provide proof that their project has an established
-developer community supporting the projects development and user base.
-This is something that takes time and energy. The reason for requirement
-is that Jakarta is a long term hosting platform for projects. Once a
-project has been accepted by the Jakarta project it will remain with the
-Jakarta project indefinitely and because of the visibility of the Jakarta
-project, will most likely develop a large user and developer base.
+At Jakarta, the core developers of a product (the
+<a href="roles.html">Committers</a>) manage the codebases and make the
+day-to-day development decisions. We are only interested in products
+that can guided by their own development communities. Jakarta provides
+the infrastructure, and some essential guidelines, but the Committers
+must take responsibility for developing and releasing their own product.
</p>
<p>
-It is required that at least 2 active developers be actively working on
-the project. According to the <a href="proposal.html">unratified
-proposal guidelines</a>, it is preferred but not required that at least
-one PMC member be a Committer to a new subproject. Think of this as
-being similar to bringing a new baby into a household. You want to be
-sure that it will be supported by its parents.
+<strong>Alignment with existing Apache subprojects.</strong> Products that
+are already used by existing subprojects make attractive candidates, since
+bringing such a codebase into the Apache fold tends to benefit both
+communities. Products with dependancies on existing Apache products are also
+attractive for the same reason.
</p>
<p>
-Proposals for projects which are the result of a company wanting to off
-load it (for various reasons) will be under greater scrutiny by the
-Jakarta PMC for inclusion because the offloading of software generally
-is the result of lack of interest in it by the people submitting the
-proposal (for various reasons). This lack of interest translates into
-the notion that the project won't receive the support that it will need
-in order to be successful under the Jakarta umbrella. Often, we will
-recommend that the project go off on its own for a while and then
-re-submit the proposal at a later date after it has been in the wild for
-a while.
+<strong>Scope.</strong> Jakarta products are generally server-side
+software solutions written for the Java platform. Proposals for products
+outside this venue will have greater difficulty in being accepted.
+</p>
+
+</section>
+
+<section name="Warning Signs">
+
+<p>
+These are anti-patterns that we have found detrimental to the success of
+a proposal. Some of these are lesson learned from the school of
+hard-knocks, others are taken from proposals which have been rejected in
+the past. All will raise a red flag, making it unlikely that a proposal
+will be accepted.
+</p>
+
+<p>
+<strong>Orphaned products.</strong> Products which have lost their
+corporate sponsor (for whatever reason) do <strong>not</strong> make good candidates.
+These products will lack a development community and won't
+have the support needed to succeed under the Jakarta umbrella.
</p>
<p>
@@ -105,92 +115,135 @@
<source>
FooProduct is currently a production quality product, and in
-fact is being used on a live website. It was developed as a
+fact is being used a live website. It was developed as a
product by FooCompany, with the intention that we would sell
it. However, due to various economic factors such as the
decline in FooProduct's intended market and the
recent difficulties in obtaining venture capital, we have
-decided that at this time it is not feasible for is to
+decided that at this time it is not feasible for us to
continue in that direction.
</source>
+
+<p>
+The alleged quality of a product is not the prime criteria. To be
+accepted, we must believe that a product will attract volunteers to
+extend and maintain it over the long term. A product like this,
+arriving with no volunteer developers or open source community, does
+not further <a href="mission.html">Jakarta's mission</a>, and would
+not be accepted.
+</p>
+
+<p>
+We generally recommend that an orphaned product start with an
+independent host, and consider making a proposal after it has started
+to build a community.
+</p>
+
+<p>
+<strong>Inexperience with open source.</strong> We often receive
+proposals that start with "We will open our software if you
+choose to accept it." This is the wrong way to approach the proposal
+process. A closed source project does not have an open community, and
+so we have no way to tell if the developers can work in an open source
+environment. Products that have lived on their own and have started
+to develop their own community, have a much better chance of being
+accepted.
+</p>
+
+<p>
+If the product's developers have not worked with open source before,
+it is recommended that they spend some time contributing to an existing
+open source project before trying to manage one of their own. Since
+Jakarta subprojects are managed by their own Committers, it is
+important that a new product supported by people who understand
+how open source works.
+</p>
+
+<p>
+<strong>Homogenous developers.</strong> Apache communities attract
+developers with diverse backgrounds. Products with a tightly-knit
+team of developers may have difficulty shepherding new developers
+into the fold. It is vital that we believe the developers will
+discuss development issues openly with the community, and
+<strong>not</strong> make decisions behind closed doors. We are
+especially wary of products with developers who all share a
+common employer or geographic location.
+</p>
+
+<p>
+<strong>Reliance on salaried developers.</strong> Jakarta has strong ties
+to the business community. Many of our developers are encouraged by their
+employers to work open source projects as part of their regular job.
+We feel that this is a Good Thing, and corporations should be entitled to
+contribute to open source, same as anyone else. However, we are wary of
+products which rely strongly on developers who only work on open source
+products when they are paid to do so. A product at Jakarta must continue
+to exist beyond the participation of individual volunteers. We believe the
+best indicator of success is when developers volunteer their own time to
+work open source projects.
+</p>
+
+<p>
+<strong>No ties to other Apache products</strong>. Products
+<strong>without</strong> a tie to any existing Apache product, and that have
+strong dependencies on alternatives to Apache products, do not make good
+candidates. Many Apache products are related through common licenses,
+technologies, and through their volunteers. Products without licensing,
+technology, or volunteers in common will have trouble attracting a
+strong community.
+</p>
+
+<p>
+<strong>A fascination with the Apache brand.</strong> The
+<a href="http://apache.org/LICENSE">Apache Software License</a> is quite
+liberal and allows for the code to used in commercial products. This
+can induce people to donate a commercial codebase to the ASF, allow it
+developed as open source for a time, and then convert it back to
+commercial use. While this would legal under the Apache Software
+License, we are wary of proposals that seem to be more interested in
+exposure than community.
+</p>
+
+</section>
+
+<section name="Subproject Alternatives">
+
+<p>
+If your product is a JSP tag library, you should contact the
+<a href="../taglibs/index.html">Jakarta Taglibs</a> subproject before
+proposing a new subproject.
+</p>
+
+<p>
+Other subprojects at Jakarta also host useful components within their own codebases.
+<a href="../avalon/index.html">Avalon</a>, <a href="../commons/index.html">Commons</a>,
+and <a href="../turbine/index.html">Turbine</a> all have significant sub-systems which
+also could be products in their own right. See the
+<a href="../index.html">Jakarta home page</a> for a description of
+all our subprojects. If your product might a good fit within an existing subproject,
+contact the subproject's committers through their
+<a href="mail.html">mailing list</a>.
+</p>
+
+<p>
+If your product is XML related, be sure to also visit the
+<a href="http://xml.apache.org/">Apache XML Project</a> to see if it would be a good fit
+there.
+</p>
+
+</section>
+
+<section name="Who Decides">
+
<p>
-A statement like this in a proposal, will undoubtedly raise red flags
-(and potentially negative responses) with the Jakarta PMC because it
-clearly shows that the company could not find a market for the product
-and is looking to give the product an extended life or use the high
-visibility of the Jakarta project to bring people to work on it. While
-the product may have quite a lot of development put into it over a
-number of years (or not), it certainly doesn't fit well into the culture
-of the Jakarta project simply because we do not want to be a place where
-someone tries to place their wares in the hopes of a better life for it.
-Even worse off is the idea of trying to use the visibility of the
-Jakarta project for your own gains. We want to know up front that the
-project will have a strong future and that is primarily based on the
-project having a strong developer and user community.
-</p>
-
-<p>
-On the same thread, think of the possibility of a product which was
-developed commercially, failed or didn't have the support behind it,
-then donated to the Jakarta project and then pulled back in commercially
-by the same company after many people spend their time donating to
-the project. It would be as if everyone in the open source community
-gave their work away for free and the only people who would benefit is
-the company. Of course the people who were working on it would still be
-able to use it, but any additions that the company makes after that
-would not necessarily need to be contributed back under the ASF License
-and the community would probably end up split and hurt as a result. The
-Jakarta PMC is wary of such tactics (pre-meditated or not).
-</p>
-
-<p>
-Design, developer, user documentation, example code, and a reference
-implementation definitely increase -- but not guarantee -- the chances
-of Jakarta acceptance of non-established projects.
-</p>
-
-<p>
-The Jakarta PMC will be much more open to accepting a project which is
-already open source than to accepting a project which is currently
-closed source. We often receive proposals that start with "We will open
-our project if you choose to accept it." This is the wrong way to
-approach the Jakarta PMC. A closed source project does not have a
-developer community. The project only has the developers who worked on
-it, which clearly does not satisfy our most important criteria.
-Therefore, unless those same developers actively participate in the
-development of existing Jakarta projects a general level of developer
-trust has not been established and the Jakarta PMC has nothing to base
-their criteria on. Again, placing the project in the wild for a bit to
-develop a community and then coming back and giving a proposal will give
-a much higher chance of being accepted.
-</p>
-
-<p>
-The Jakarta PMC will be much more open to accepting a project for which
-the people behind the project have some degree of open source
-experience. In other words, if the submitter of the proposal does not
-have open source experience (both as a participant as well as a
-committer), then maybe spending some time contributing to existing open
-source projects would be beneficial to us all before going ahead with
-the proposal. Doing so will lower the amount of (very limited) resources
-that the Jakarta PMC needs allocate to deal with educating someone on
-how to run an open source project in a highly visible environment.
-</p>
-
-<p>
-Final acceptance is based on the rules defined in our <a
-href="management.html">PMC Bylaws</a> which state that "Creation of a
-new subproject requires approval by 3/4 vote of the PMC." The voting
-should happen on the general@jakarta <a href="mail.html">mailing
-list</a>.
-</p>
-
-<p>
-It should be noted that all projects which are currently under the
-Jakarta project are considered grand fathered into the Jakarta project
-and may or may not have met all of the criteria listed above (hindsight
-is 20/20).
+Final acceptance is based the rules defined in the <a
+href="management.html">Project Management Committee Bylaws</a> which
+state that "Creation of a new subproject requires approval by 3/4 vote
+of the PMC." The proposal for a new subproject must submitted to the
+Jakarta General <a href="mail.html">mailing list</a>, where the PMC
+conducts business. All discussion regarding the proposal will occur
+the General list, including the final vote.
</p>
</section>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>