husted 02/01/13 06:06:59
Modified: docs/site newproject2.html
Log:
Updates to proposed redraft of new product page.
Revision Changes Path
1.2 +65 -25 jakarta-site2/docs/site/newproject2.html
Index: newproject2.html
===================================================================
RCS file: /home/cvs/jakarta-site2/docs/site/newproject2.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- newproject2.html 12 Jan 2002 22:46:28 -0000 1.1
+++ newproject2.html 13 Jan 2002 14:06:59 -0000 1.2
@@ -145,16 +145,9 @@
<blockquote>
<p>
Not every software product is suited for life at Jakarta. Before proposing
-a new subproject, it is important to read this document carefully, to determine
+a new subproject, it is important to read this document carefully and determine
whether your product is a good fit.
</p>
- <p>
-Jakarta can host a product within a top-level subproject, or as a component
-in the Jakarta Commons. This document covers what is expected of a proposal for
-a top-level Jakarta subproject. The Jakarta Commons has a similar but different
-procedure for accepting new products. See the <a href="/commons/">Jakarta
-Commons</a> site for details.
-</p>
</blockquote>
</p>
</td></tr>
@@ -169,7 +162,12 @@
<tr><td>
<blockquote>
<p>
-<strong>Meritocracy.</strong> Before submitting a proposal, be sure to study
+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>
+<strong>Meritocracy.</strong> Before submitting a proposal, sure to study
the guidelines that <a href="guidelines.html">govern Jakarta projects</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
@@ -193,22 +191,30 @@
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 on source code and JavaDocs alone.
+products that rely source code and JavaDocs alone.
</p>
<p>
<strong>Core Developers.</strong> To considered, a product must have
-at least 2 active developers who are already involved with the codebase.
-This is an absolute minimum, and it is helpful for there to be more than
-two 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>
+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 active in a Jakarta subproject or
+other open source initiative.
+</p>
<p>
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 responsiblity for developing and releasing their own product.
+must take responsibility for developing and releasing their own product.
+</p>
+ <p>
+<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>
<strong>Scope.</strong> Jakarta products are generally server-side
@@ -229,7 +235,11 @@
<tr><td>
<blockquote>
<p>
-Here are some warning signs from proposals that have been rejected.
+These are anti-patterns that we have found detrimental to the sucess 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
@@ -269,16 +279,16 @@
</table>
</div>
<p>
-The alleged quality of a product is not the prime criteria. To be
+The alleged quality of a product is not the prime criteria. To
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.
+not accepted.
</p>
<p>
We generally recommend that an orphaned product start with an
-independant host, and consider making a proposal after it has started
+independent host, and consider making a proposal after it has started
to build a community.
</p>
<p>
@@ -287,7 +297,7 @@
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
+environment. Products that have lived their own, and have started
to develop their own community, have a much better chance of being
accepted.
</p>
@@ -296,17 +306,47 @@
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 be supported by people who understand
+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 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 both by technologies and
+through the volunteers who create the technologies. Products without
+technologies 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
<a href="http://barista.editthispage.com/2001/08/31";>convert
-it back to commercial use</a>. While this would be legal under the
+it back to commercial use</a>. While this would legal under the
Apache Software License, we are wary of proposals that seem to more
interested in exposure than community.
</p>
@@ -326,9 +366,9 @@
<p>
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 be submitted to the
+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 on
+conducts business. All discussion regarding the proposal will occur
the General list, including the final vote.
</p>
</blockquote>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
