Google Git
Sign in
apache / incubator / 766f9906a15ef7548ed922f90c5412e569afbd64 / . / bob / guides / proposal.html
blob: 7c3c751df7b040beed8069afb5e9d4ad63841302 [file] [log] [blame]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="stylesheet" href="../style/bootstrap-1-3-0-min.css" type="text/css" />
<link rel="stylesheet" href="../style/style.css" type="text/css" />
<link rel="alternate" title="general@incubator.apache.org Archives" type="application/atom+xml" href="http://mail-archives.apache.org/mod_mbox/incubator-general/?format=atom" />
<title>A Guide To Proposal Creation - Apache Incubator</title>
</head>
<body>
<div class="container">
<div class="row">
<div class="span12">
<a href="http://www.apache.org/"><img src="http://incubator.apache.org/images/asf_logo_wide_small.png" alt="The Apache Software Foundation" border="0" style="margin-top: 2px" width="62%"/></a>
</div>
<div class="span4">
<a href="http://incubator.apache.org/"><img src="../images/egg-logo2.png" alt="Apache Incubator" border="0"/></a>
</div>
</div>
<div class="row"><div class="span16"><hr noshade="noshade" size="1"/></div></div>
<div class="row">
<div class="span4">
<form action="http://www.google.com/search" method="get">
<input value="incubator.apache.org" name="sitesearch" type="hidden"/>
<input size="20" name="q" id="query" type="text" value="search..."
onclick="if(this.value == 'search...') {this.value = ''}"/>
<input name="Search" value="Go" type="submit"/>
</form>
<div class="menuheader">General</div>
<menu compact="compact">
<li><a href="../index.html">Welcome</a></li>
<li><a href="../incubation/Process_Description.html">Incubation Overview</a></li>
<li><a href="../incubation/Incubation_Policy.html">Incubation Policy</a></li>
<li><a href="../guides/index.html">Incubation Guides</a></li>
<li><a href="../incubation/Roles_and_Responsibilities.html">Roles and Responsibilities</a></li>
<li><a href="../faq.html">General FAQ</a></li>
<li><a href="http://wiki.apache.org/incubator">Incubator Wiki</a></li>
<li><a href="../whoweare.html">Who We Are</a></li>
<li><a href="../sitemap.html">Site Map</a></li>
</menu>
<div class="menuheader">Status</div>
<menu compact="compact">
<li><a href="../projects/index.html">Project List</a></li>
<li><a href="../clutch.html">Clutch Report</a></li>
<li><a href="../ip-clearance/index.html">IP Clearance</a></li>
<li><a href="../history/index.html">Incubator History</a></li>
</menu>
<div class="menuheader">Entry Guides</div>
<menu compact="compact">
<li><a href="../guides/proposal.html">Proposal Guide</a></li>
</menu>
<div class="menuheader">Podling Guides</div>
<menu compact="compact">
<li><a href="../guides/committer.html">Podling Committers</a></li>
<li><a href="../guides/ppmc.html">Podling PMC (PPMC)</a></li>
<li><a href="../guides/mentor.html">Podling Mentor</a></li>
<li><a href="../guides/releasemanagement.html">Podling Releases</a></li>
<li><a href="../guides/branding.html">Podling Branding/Publicity</a></li>
<li><a href="../guides/sites.html">Podling Websites</a></li>
<li><a href="../guides/graduation.html">Graduation</a></li>
<li><a href="../guides/retirement.html">Retirement</a></li>
</menu>
<div class="menuheader">Other Guides</div>
<menu compact="compact">
<li><a href="../guides/participation.html">Participation</a></li>
<li><a href="../faq.html">General FAQ</a></li>
<li><a href="../guides/pmc.html">Incubator PMC (IPMC)</a></li>
<li><a href="../guides/chair.html">IPMC Chair</a></li>
<li><a href="../guides/lists.html">Mailing Lists</a></li>
<li><a href="../guides/website.html">Incubator Website</a></li>
</menu>
<div class="menuheader">ASF</div>
<menu compact="compact">
<li><a href="http://www.apache.org/foundation/how-it-works.html">How Apache Works</a></li>
<li><a href="http://www.apache.org/dev/">Developer Documentation</a></li>
<li><a href="http://www.apache.org/foundation/">Foundation</a></li>
<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsor Apache</a></li>
<li><a href="http://www.apache.org/foundation/thanks.html">Thanks</a></li>
</menu>
<!-- start Ads Server -->
<iframe src="http://www.apache.org/ads/buttonbar.html"
style="border-width:0; float: left" frameborder="0" scrolling="no"
width="135" height="265"></iframe>
<!-- end Ads Server -->
</div>
<div class="span12">
<h2 id='preamble'><img src="../images/redarrow.gif" />A Guide To Proposal Creation</h2>
<div class="section-content">
<h3 id='TOC'>Contents</h3>
<div class="section-content">
<ul>
<li><a href='#preamble'>
A Guide To Proposal Creation
</a>
<ul>
<li><a href='#TOC'>
Contents
</a>
</li>
<li><a href='#status'>
Status
</a>
</li>
<li><a href='#abstract'>
Abstract
</a>
</li>
<li><a href='#background'>
Background
</a>
</li>
<li><a href='#note-on-improvements'>
Continuous Improvement
</a>
</li>
<li><a href='#help-wanted'>
Help Wanted!
</a>
</li>
</ul>
</li>
<li><a href='#formulating'>
Formulating A Proposal
</a>
<ul>
<li><a href='#preparation'>
Preparation
</a>
</li>
<li><a href='#name'>
Project Name
</a>
</li>
<li><a href='#presentation'>
Presentation
</a>
</li>
<li><a href='#developing'>
Developing The Proposal
</a>
</li>
<li><a href='#vote'>
The Vote
</a>
</li>
</ul>
</li>
<li><a href='#proposal-template'>
Proposal Template
</a>
<ul>
<li><a href='#template-abstract'>
Abstract
</a>
</li>
<li><a href='#template-proposal'>
Proposal
</a>
</li>
<li><a href='#template-background'>
Background
</a>
</li>
<li><a href='#template-rationale'>
Rationale
</a>
</li>
<li><a href='#template-initial-goals'>
Initial Goals
</a>
</li>
<li><a href='#template-current-status'>
Current Status
</a>
<ul>
<li><a href='#template-meritocracy'>
Meritocracy
</a>
</li>
<li><a href='#template-community'>
Community
</a>
</li>
<li><a href='#template-core-developers'>
Core Developers
</a>
</li>
<li><a href='#template-alignment'>
Alignment
</a>
</li>
</ul>
</li>
<li><a href='#template-known-risks'>
Known Risks
</a>
<ul>
<li><a href='#template-orphaned-products'>
Orphaned products
</a>
</li>
<li><a href='#template-inexperience-with-open-source'>
Inexperience with Open Source
</a>
</li>
<li><a href='#template-homogenuous-developers'>
Homogenous Developers
</a>
</li>
<li><a href='#template-reliance-on-salaried-developers'>
Reliance on Salaried Developers
</a>
</li>
<li><a href='#template-other-producrs'>
Relationships with Other Apache Products
</a>
</li>
<li><a href='#template-brand-fascination'>
A Excessive Fascination with the Apache Brand
</a>
</li>
</ul>
</li>
<li><a href='#template-documentation'>
Documentation
</a>
</li>
<li><a href='#template-initial-source'>
Initial Source
</a>
</li>
<li><a href='#template-ip'>
Source and Intellectual Property Submission Plan
</a>
</li>
<li><a href='#template-external-dependencies'>
External Dependencies
</a>
</li>
<li><a href='#template-cryptography'>
Cryptography
</a>
</li>
<li><a href='#template-required-resources'>
Required Resources
</a>
<ul>
<li><a href='#template-mailing-lists'>
Mailing lists
</a>
</li>
<li><a href='#template-subversion-directory'>
Subversion Directory
</a>
</li>
<li><a href='#template-git-repository'>
Git Repository
</a>
</li>
<li><a href='#template-issue-tracking'>
Issue Tracking
</a>
</li>
<li><a href='#template-other-resources'>
Other Resources
</a>
</li>
</ul>
</li>
<li><a href='#template-initial-committers'>
Initial Committers
</a>
</li>
<li><a href='#template-affiliations'>
Affiliations
</a>
</li>
<li><a href='#template-sponsors'>
Sponsors
</a>
<ul>
<li><a href='#template-champion'>
Champion
</a>
</li>
<li><a href='#template-mentors'>
Nominated Mentors
</a>
</li>
<li><a href='#template-sponsoring-entity'>
Sponsoring Entity
</a>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
<h3 id='status'>Status</h3>
<div class="section-content">
<p>
This document provides guidance only. Policy is found <a href="../incubation/Incubation_Policy.html">here</a>.
</p>
</div>
<h3 id='abstract'>Abstract</h3>
<div class="section-content">
<p>
This document is descriptive, not normative. It describes approaches to
drawing up a proposal for submission. It is not an inflexible standard but
represents a consensus condensed from discussions on the
<a href="lists.html#general+at+incubator.apache.org">general mailing list</a>.
</p>
</div>
<h3 id='background'>Background</h3>
<div class="section-content">
<p>
<a href="entry.html">Entry</a> to the incubator is a democratic
<a href="../incubation/Process_Description">process</a> decided by a vote.
The proposal is the document upon which the
<a href="../incubation/Roles_and_Responsibilities.html#Sponsor">Sponsor</a> votes.
So, though it's neither necessary nor sufficient to have a good proposal,
a good proposal increases the chances of a positive result.
</p>
<p>
Proposals to the incubator generate attention. The
<a href="lists.html#general+at+incubator.apache.org">general mailing list</a> is open,
widely discussed and well indexed. It is a very public space.
The proposal is a manifesto.
A good proposal should target also the wider audience and not just the
<a href="../incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">
jury</a>.
Use this time to engage and inform potential
<a href="participation.html#developer">developers</a>
and <a href="participation.html#user">users</a>.
</p>
<p>
Much of the information will be reused in the
<a href="sites.html">Podling website</a>.
A good proposal should shape the future evolution of the project
but each proposal captures only the particular instant at birth.
It is understood that projects change and evolve.
</p>
</div>
<h3 id='note-on-improvements'>Continuous Improvement</h3>
<div class="section-content">
<p>
The <a href="../incubation/Process_Description.html">Incubation process</a> is continuously evolving.
Hopefully this will help newer projects to be even stronger and more successful then existing ones.
One consequence of this approach is that precedence is not always a reliable guide.
Another is that documentation may be a little outdated.
</p>
</div>
<h3 id='help-wanted'>Help Wanted!</h3>
<div class="section-content">
<p>
Help to improve the system by posting a patch for this document to the
<a href="https://issues.apache.org/jira/browse/INCUBATOR">incubator section</a>
of <a href="http://issues.apache.org/jira">JIRA</a>
or a comment to the <a href="lists.html#general+at+incubator.apache.org">general list</a>.
</p>
</div>
</div>
<h2 id='formulating'><img src="../images/redarrow.gif" />Formulating A Proposal</h2>
<div class="section-content">
<h3 id='preparation'>Preparation</h3>
<div class="section-content">
<p>
Start with research. The <a href="entry.html">incubator entry guide</a> is a good place to start.
Read the <a href="http://www.apache.org">Apache</a>
<a href="http://www.apache.org/foundation">documentation</a>.
</p>
<p>
<a href="lists.html">Subscribe</a> to the
<a href="lists.html#general+at+incubator.apache.org">general mailing list</a>.
Spend some time reviewing the
<a href="http://mail-archives.apache.org/mod_mbox/incubator-general/">mailing lists archives</a>.
The mailing lists are the canonical form of
<a href="http://www.apache.org/foundation/how-it-works.html#communication">communication</a>
and <a href="http://www.apache.org/foundation/how-it-works.html#decision-making">decision making</a>
at Apache. Documentation is an attempt to codify the consensus formed and record the decisions taken on list.
</p>
<p>
Before starting on the formal proposal, recruit a
<a href="../incubation/Roles_and_Responsibilities.html#Champion">Champion</a>. The Champion understands
Apache and should be able to help navigate the process.
</p>
<p>
Review <a href="http://wiki.apache.org/incubator/">recent proposals</a> and how they have been
<a href="http://mail-archives.apache.org/mod_mbox/incubator-general/">received</a>.
</p>
<p>
The incoming community needs to work together before presenting this
proposal to the incubator. Think about and discuss future goals and the reasons for coming to Apache.
Feel free to ask questions <a href="lists.html#general+at+incubator.apache.org">on list</a>.
</p>
<p>
Every proposal is different. There will always be some aspects which do not seem
to fit well into the <a href="#proposal-template">template</a>.
Use the template as a guide but do not feel constrained
by it. Adopt what works and change what doesn't. That's fine - in fact, it's expected.
</p>
<p>
Be sure to add your pproposal to <a href="http://wiki.apache.org/incubator/ProjectProposals">this list</a>.
</p>
</div>
<h3 id='name'>Project Name</h3>
<div class="section-content">
<p>
While it is important to ensure a
<a href="graduation.html#notes-names">suitable project name</a>
and product names sometime during incubation, it is not necessary
to do this prior to entering incubation. In fact, be careful not to
disrupt your proposal and entry process.
</p>
</div>
<h3 id='presentation'>Presentation</h3>
<div class="section-content">
<p>
Once the preparatory work is done, the proposal should be presented to the
incubator. Post the proposal in plain text in an email to the
<a href="lists.html#general+at+incubator.apache.org">mailing list</a>
whose subject is prefixed with <code>[PROPOSAL]</code>. You should be clear
that you want to discuss your proposal when submitting this mail.
</p>
<p>
If there is interest in the proposal, expect a lively debate to begin.
Approval is an open and
<a href="http://www.apache.org/foundation/voting.html">democratic</a>
<a href="entry.html#understanding">process</a>.
Discussion is an important part of opinion formation. A proposal
will require development if it is to gain the maximum level of support from the
<a href="../whoweare.html">electorate</a>.
</p>
</div>
<h3 id='developing'>Developing The Proposal</h3>
<div class="section-content">
<p>
Expect to work on improving the proposal on the list after presenting it.
No preparation can cover every question. It is usual for unexpected
and novel questions to be asked. This is often a sign of interest. So
(though it may sometimes feel like an ordeal)
approach these questions as a positive opportunity.
</p>
<p>
The <a href="http://wiki.apache.org/incubator/">wiki</a> is a good
development tool. Consider creating a wiki page containing the evolving proposal
content. Those who are interested should add themselves
to the watch list for the page so they can receive change notifications.
</p>
<p>
Developing the proposal on the wiki allows easy collaboration. This has disadvantages
as well as advantages. The wiki is just a tool to assist the easy development of the
final proposal (the one that will be voted upon). Not every change improves a proposal
and there is no requirement that every change is accepted by the proposers. Note that the incubator
asks all participants to abide by appropriate <a href="participation.html">netiquette</a>.
</p>
<p>
Effective management of this development is an exercise in community building.
The wiki is not an appropriate forum for debating changes. Discussion should be
gently moved onto the appropriate
<a href="lists.html#general+at+incubator.apache.org">mailing list</a>.
</p>
</div>
<h3 id='vote'>The Vote</h3>
<div class="section-content">
<p>
When the proposal seems finished and some sort of consensus has emerged, the
proposal should be put to a vote.
If the wiki is used to develop the proposal, please ensure that the wiki
matches the final proposal then add a notice to the wiki that development of
the document is now complete:
</p>
<div class="source"><code>
----
/!\ '''FINAL''' /!\
This proposal is now complete and has been submitted for a VOTE.
----
</code>
</div>
<p>
Embed the final proposal text or a link to a specific revision number of the
wiki proposal page in the email which kicks off the VOTE thread. If a change
is required after the vote has been called then the vote must be cancelled,
the change made, and the vote restarted. Alternatively, Mentors will advise
on how to make the change once the proposal has been accepted if this is
appropriate. Do not edit the wiki proposal unless you cancel the vote
thread.
</p>
</div>
</div>
<h2 id='proposal-template'><img src="../images/redarrow.gif" />Proposal Template</h2>
<div class="section-content">
<p>
The aim of presenting a template with examples and comments is educational.
Proposals are not required to adopt this format.
Every proposal is different. There may be sections which don't seem to be
useful. It's fine to miss them out and to add new ones that the proposal seems
to need. Best practice evolves. Innovation is acceptable.
</p>
<p>
The format is less important than the content.
</p>
<p>
In the following sections:
</p>
<div class="note">
<note>
<p>
Commentary is thus.
</p>
</note>
</div>
<div class="source"><code>
Examples are thus.
</code>
</div>
<h3 id='template-abstract'>Abstract</h3>
<div class="section-content">
<div class="note">
<note>
<p>
A short descriptive summary of the
project. A short paragraph, ideally one sentence in length.
</p><p>
The abstract should be suitable for reuse in
the board resolution used to create the official project upon graduation,
as the first paragraph on the podling <a href="sites.html">web site</a>
and in the <a href="http://projects.apache.org/create.html">DOAP</a> document.
</p>
</note>
</div>
<div class="source"><code>
Examples:
Geronimo will be a J2EE compliant container.
Heraldry will develop technologies around the emerging user-centric
identity space.
Yoko will be a CORBA server.
</code>
</div>
</div>
<h3 id='template-proposal'>Proposal</h3>
<div class="section-content">
<div class="note">
<note>
<p>
A lengthier description of the proposal. Should be reasonably declarative.
More discursive material should be included in the <a href="#template-rationale">rationale</a>
(or other later sections).
</p>
</note>
</div>
<div class="source"><code>
Example (XAP):
XAP is to provide an XML-based declarative framework for building,
deploying and maintaining rich, interactive, Ajax-powered web
applications. A basic principal of XAP is to leverage existing Ajax
...
</code>
</div>
</div>
<h3 id='template-background'>Background</h3>
<div class="section-content">
<div class="note">
<note>
<p>
Provides context for those unfamiliar with the problem space and history.
</p><p>
Explain terms whose meanings may be misunderstood (for example,
where there is not a single widely adopted definition).
<p>
</p>
This content should be capable of being safely ignored by domain experts.
It should probably find an eventual home on the Podling website.
</p>
</note>
</div>
<div class="source"><code>
Example (Heraldry):
To provide some background, the Higgins Project is being actively
developed within Eclipse and is a framework that will enable users
and enterprises to integrate identity, profile, and relationship
information across multiple systems. Using context providers,
existing and new systems such as directories, collaboration spaces
...
</code>
</div>
</div>
<h3 id='template-rationale'>Rationale</h3>
<div class="section-content">
<div class="note">
<note>
<p>
Explains why this project needs to exist and why should it be adopted by Apache.
This is the right place for discursive material.
</p>
</note>
</div>
<div class="source"><code>
Example (Beehive):
There is a strong need for a cohesive, easy-to-use programming model
for building J2EE applications. Developers new to Java are forced to
learn a myriad of APIs just to build simple applications; advanced
J2EE developers are forced to write tedious plumbing code; and tools
authors are limited in what they can do to simplify the experience
due to the underlying complexity.
</code>
</div>
</div>
<h3 id='template-initial-goals'>Initial Goals</h3>
<div class="section-content">
<div class="note">
<note>
<p>
A complex proposal (involving multiple existing code bases, for example)
may cause concerns about its practicality. A good way
to address these concerns is to create a plan that demonstrates the proposal
is feasible and has been carefully thought through.
</p>
<p>
Many projects will not need this section.
</p>
</note>
</div>
<div class="source"><code>
Example (Heraldry):
* Expansion of Yadis and OpenID libraries into additional languages
beyond the existing Python, Ruby, Perl, and PHP libraries
* OpenID authentication specification revision to fix known security
considerations, investigate compatibility with the DIX IETF
proposal, describe Yadis integration, and allow either an URL or
XRI be used as the End User's Identifier
...
</code>
</div>
</div>
<h3 id='template-current-status'>Current Status</h3>
<div class="section-content">
<div class="note">
<note>
<p>
This section (and the contained topics) describes
the candidate's current status and development practices.
This should be an honest assessment balancing these against Apache's
<a href="http://www.apache.org/foundation/">principles</a> and
<a href="http://www.apache.org/foundation/how-it-works.html#management">development ideals</a>.
</p><p>
For some proposals, this is a chance to demonstrate understanding
of the issues that will need to addressed before graduation.
For others, this is a chance to highlight the close match with Apache that already exists.
Proposals without an initial code base should just simply state that.
</p><p>
Some proposals name this section <em>criteria</em> (though the term is a little misleading).
</p>
</note>
</div>
<h4 id='template-meritocracy'>Meritocracy</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Apache is a
<a href="http://www.apache.org/foundation/how-it-works.html#meritocracy">meritocracy</a>.
</p><p>
Once a developer has submitted enough good patches then it should be
natural that they are elected to committer. It should be natural that active committers are elected
to the project management committee (PMC).
</p>
<p>
This process of renewal is vital to the long term health of Apache projects.
This is the right place to demonstrate that this process is understood
by the proposers.
</p>
</note>
</div>
<div class="source"><code>
Example (OFBiz):
OFBiz was originally created by David E. Jones and Andy Zeneski in
May 2001. The project now has committers and users from around the
world. The newer committers of the project joined in subsequent
years by initially submitting patches, then having commit privileges
for some of the applications, and then privileges over a larger
range of applications...
Example (Beehive):
We plan to do everything possible to encourage an environment that
supports a meritocracy. One of the lessons that the XMLBeans
committers have learned is that meritocracies don't just evolve
from good intentions; they require actively asking the community
for help, listing/specifying the work that needs to be done, and
keeping track of and encouraging members of the community who make
any contributions...
</code>
</div>
</div>
<h4 id='template-community'>Community</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Apache is interested only in communities.
</p><p>
Candidates should start with a
community and have the potential to grow and renew this community by
attracting new users and developers. Explain how the proposal fits this vision.
</p>
</note>
</div>
<div class="source"><code>
Example (Beehive):
BEA has been building a community around predecessors to this
framework for the last two years. There is currently an active
newsgroup that should help us build a new community at Apache...
Example (WebWork2):
The WebWork 2 community has a strong following with active mailing
lists and forums...
Example (WADI):
The need for a full service clustering and caching component in the
open source is tremendous as its use can be applied in many areas,
thus providing the potential for an incredibly large community...
</code>
</div>
</div>
<h4 id='template-core-developers'>Core Developers</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Apache is composed of <a href="http://www.apache.org/foundation/how-it-works.html#hats">individuals</a>.
</p>
<p>
It is useful to provide a brief introduction to the developers on the
<a href="#template-initial-committers">initial committers</a> list.
This is best done here (and not in that section). This section may be used to discuss
the diversity of the core development team.
</p>
</note>
</div>
<div class="source"><code>
Example (ServiceMix)
The core developers are a diverse group of developers many of which
are already very experienced open source developers. There is at
least one Apache Member together with a number of other existing
Apache Committers along with folks from various companies.
http://servicemix.org/Team
Example (WADI)
WADI was founded by Jules Gosnell in 2004, it now has a strong base
of developers from Geronimo, Castor, OpenEJB, Mojo, Jetty,
ActiveCluster, ActiveMQ, and ServiceMix.
</code>
</div>
</div>
<h4 id='template-alignment'>Alignment</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Describe why Apache is a good match for the proposal.
An opportunity to highlight links with Apache
<a href="http://projects.apache.org">projects</a>
and <a href="http://www.apache.org/foundation/how-it-works.html">development philosophy</a>.
</p>
</note>
</div>
<div class="source"><code>
Example (Beehive):
The initial code base is targeted to run within Tomcat, but the goal
is to allow the framework to run on any compliant Servlet or J2EE
container. The Web services component, based on JSR-181, will
leverage Axis. The NetUI component builds on top of Struts. The
underlying Controls component framework uses Velocity. There are
other projects that we will need to work with, such as the Portals
and Maven projects.
</code>
</div>
</div>
</div>
<h3 id='template-known-risks'>Known Risks</h3>
<div class="section-content">
<div class="note">
<note>
<p>
An exercise in self-knowledge.
Risks don't mean that a project is unacceptable.
If they are recognized and noted then they can be addressed during incubation.
</p>
</note>
</div>
<h4 id='template-orphaned-products'>Orphaned products</h4>
<div class="section-content">
<div class="note">
<note>
<p>
A public commitment to future development.
</p><p>
Recruiting a diverse development community and strong user base takes time.
Apache needs to be confident that the proposers are committed.
</p>
</note>
</div>
<div class="source"><code>
Example (Yoko):
The contributors are leading vendors in this space. There is no risk
of any of the usual warning signs of orphaned or abandoned code.
</code>
</div>
<br />
<div class="source"><code>
Example (Ivy):
Due to its small number of committers, there is a risk of being orphaned.
The main knowledge of the codebase is still mainly owned by Xavier Hanin.
Even if Xavier has no plan to leave Ivy development, this is a problem we
are aware of and know that need to be worked on so that the project become
less dependent on an individual.
</code>
</div>
<br />
<div class="source"><code>
Example (Tika):
There are a number of projects at various stages of maturity that implement
a subset of the proposed features in Tika. For many potential users the
existing tools are already enough, which reduces the demand for a more
generic toolkit. This can also be seen in the slow progress of this proposal
over the past year.
However, once the project gets started we can quickly reach the feature level
of existing tools based on seed code from sources mentioned below. After that
we believe to be able to quickly grow the developer and user communities based
on the benefits of a generic toolkit over custom alternatives.
</code>
</div>
</div>
<h4 id='template-inexperience-with-open-source'>Inexperience with Open Source</h4>
<div class="section-content">
<div class="note">
<note>
<p>
If the proposal is based on an existing open source project with a history of open development,
then highlight this here.
</p>
<p>
If the list of <a href="#template-initial-committers">initial committers</a> contains developers
with strong open source backgrounds then highlight this here.
</p>
<p>
Inexperience with open source is one reason why closed projects choose to apply for incubation.
Apache has developed over the years a store of experience in this area.
Successfully opening up a closed project means an investment of energy by all involved.
It requires a willingness to learn and to give back to the community. If the proposal is based
around a closed project and comes with very little understand of the open source space,
then acknowledge this and demonstrate a willingness to learn.
</p>
</note>
</div>
<div class="source"><code>
Example (Cayenne):
Cayenne was started as an open source project in 2001 and has
remained so for 5 years.
</code>
</div>
<br />
<div class="source"><code>
Example (Beehive):
Many of the committers have experience working on open source
projects. Five of them have experience as committers on other
Apache projects.
</code>
</div>
<br />
<div class="source"><code>
Example (Ivy):
While distributed under an open source license, access to Ivy was initially
limited with no public access to the issue tracking system or svn
repository. While things have changed since then - the svn repository is
publicly accessible, a JIRA instance has been setup since june 2005, many
new features are first discussed on the forum or JIRA - experience with a
true open source development model is currently limited.
However, Maarten has already a good experience with true open development
process, and bring his experience to the project.
</code>
</div>
<br />
<div class="source"><code>
Example (River):
The initial committers have varying degrees of experience with open source
projects. All have been involved with source code that has been released under
an open source license, but there is limited experience developing code with an
open source development process. We do not, however, expect any difficulty in
executing under normal meritocracy rules.
</code>
</div>
</div>
<h4 id='template-homogenuous-developers'>Homogenous Developers</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Healthy projects need a mix of developers. Open development requires a commitment
to encouraging a diverse mixture. This includes the art of working as part of
a geographically scattered group in a distributed environment.
</p>
<p>
Starting with a homogenous community does not prevent a project from entering incubation.
But for those projects, a commitment to creating a diverse mix of developers is useful.
Those projects who already have a mix should take this chance to highlight that they do.
</p>
</note>
</div>
<div class="source"><code>
Example (Beehive):
The current list of committers includes developers from several
different companies plus many independent volunteers. The committers
are geographically distributed across the U.S., Europe, and Asia.
They are experienced with working in a distributed environment.
</code>
</div>
<br />
<div class="source"><code>
Example (River)
Since the Jini Technology Starter Kit has been mainly developed to date by Sun
Microsystems, the vast majority of initial committers to the project are from
Sun. Over the years, Sun has received bug fixes and enhancements from other
developers which have been incorporated into the code. Our plan is to work with
these other developers and add them as committers as we progress. There are
three other initial committers (non Sun): Bill Venners, Dan Creswell, and Mark
Brouwer. Bill is the lead of the Service UI API work, Dan has been involved with
much Jini-based development, including an implementation of the JavaSpaces
service called Blitz &lt;http://www.dancres.org/blitz/&gt;, and Mark is veteran of
much Jini-based development, including commercial work at Virgil
&lt;http://www.virgil.nl&gt; as well as leading the open source Cheiron
&lt;http://www.cheiron.org&gt; project.
</code>
</div>
<br />
<div class="source"><code>
Example (Ivy):
With only two core developers, at least they are not homogenous! Xavier and
Maarten knew each other only due to their common interest in Ivy.
</code>
</div>
</div>
<h4 id='template-reliance-on-salaried-developers'>Reliance on Salaried Developers</h4>
<div class="section-content">
<div class="note">
<note>
<p>
A project dominated by salaried developers who are interested in the code
only whilst they are employed to do so risks its long term health.
</p><p>
Apache is <a href="http://www.apache.org/foundation/how-it-works.html#hats">about</a> people,
not corporations. We hope that developers continue to be involved with Apache
no matter who their current employer happens to be.
</p>
<p>
This is a right place to indicate the initial balance between salaried developers
and volunteers. It's also good to talk about the level of commitment of the developers.
</p>
</note>
</div>
<div class="source"><code>
Example (OpenJPA):
Most of the developers are paid by their employer to contribute to
this project, but given the anticipation from the Java community for
the a JPA implementation and the committers' sense of ownership for
the code, the project would continue without issue if no salaried
developers contributed to the project.
</code>
</div>
<br />
<div class="source"><code>
Example (River):
It is expected that Jini development will occur on both salaried time and on
volunteer time, after hours. While there is reliance on salaried developers
(currently from Sun, but it's expected that other company's salaried developers
will also be involved), the Jini Community is very active and things should
balance out fairly quickly. In the meantime, Sun will support the project in the
future by dedicating 'work time' to Jini, so that there is a smooth transition.
</code>
</div>
<br />
<div class="source"><code>
Example (Wicket):
None of the developers rely on Wicket for consulting work, though two -
Martijn and Eelco - are writing Wicket In Action (publisher Manning) in
their spare time. Most of the developers use Wicket for their day jobs,
some for multiple projects, and will do so for a considerable while as
their companies (specifically Topicus, Cemron and Teachscape) choose
Wicket as their development framework of choice.
</code>
</div>
</div>
<h4 id='template-other-producrs'>Relationships with Other Apache Products</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Apache projects should be open to collaboration with other open source projects both
within Apache and without. Candidates should be willing to reach outside their own little bubbles.
</p><p>
This is a an opportunity to talk about existing links. It is also the right place to
talk about potential future links and plans.
</p><p>
Apache allows different projects to have competing or overlapping goals. However, this should
mean friendly competition between codebases and cordial cooperation between communities.
</p><p>
It is not always obvious whether a candidate is a direct competitor to an existing
project, an indirect competitor (same problem space, different ecological niche) or are just
peers with some overlap. In the case of indirect competition, it is
important that the abstract describes accurately the niche. Direct competitors should expect
to be asked to summarize architectural differences and similarities to existing projects.
</p>
</note>
</div>
<div class="source"><code>
Example (OpenJPA):
Open JPA will likely be used by Geronimo, requires some Apache
products (regexp, commons collections, commons lang, commons pool),
and supports Apache commons logging.
</code>
</div>
<br />
<div class="source"><code>
Example (River)
Currently the only tie to Apache projects is the starter kit's use
of the Ant build tool. There are potential future ties (http server,
database backend, etc)that will be explored.
</code>
</div>
</div>
<h4 id='template-brand-fascination'>A Excessive Fascination with the Apache Brand</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Concerns have been raised in the past that some projects appear to have been proposed
just to generate positive publicity for the proposers. This is the right place
to convince everyone that is not the case.
</p><p>
This is also the right place to build bridges with the
community after past misdemeanors (for example, if any of those associated
with the proposal have - in the past - sort to associate themselves with the Apache brand in
factually incorrect ways) and promise good conduct for the future.
</p>
</note>
</div>
<div class="source"><code>
Example (CeltiXfire):
While we expect the Apache brand may help attract more contributors,
our interests in starting this project is based on the factors
mentioned in the Rationale section. However, we will be sensitive to
inadvertent abuse of the Apache brand and will work with the
Incubator PMC and the PRC to ensure the brand policies are respected.
</code>
</div>
<br />
<div class="source"><code>
Example (Wicket):
The ASF has a strong brand, and that brand is in itself attractive.
However, the developers of Wicket have been quite successful on
their own and could continue on that path with no problems at all.
We are interested in joining the ASF in order to increase our
contacts and visibility in the open source world. Furthermore, we
have been enthusiastic users of Apache from the earliest hour
(remember JServ anyone?), and feel honored at getting the
opportunity to join the club.
</code>
</div>
<br />
<div class="source"><code>
Example (OpenJPA):
We think that Open JPA is something that will benefit from wide
collaboration, being able to build a community of developers and
committers that outlive the founders, and that will be embraced
by other Apache efforts, such as the Geronimo project.
</code>
</div>
</div>
</div>
<h3 id='template-documentation'>Documentation</h3>
<div class="section-content">
<div class="note">
<note>
<p>
References to further reading material.
</p>
</note>
</div>
<div class="source"><code>
Examples (Heraldry):
[1] Information on Yadis can be found at:
http://yadis.org
http://www.openidenabled.com
[2] Information on OpenID can be found at:
http://www.openid.net
http://www.openidenabled.com
The mailing list for both OpenID and Yadis is located at:
http://lists.danga.com/mailman/listinfo/yadis
...
</code>
</div>
</div>
<h3 id='template-initial-source'>Initial Source</h3>
<div class="section-content">
<div class="note">
<note>
<p>
Describes the origin of the proposed code base. If the initial code arrives
from more than one source, this is the right place to outline the different
histories.
</p><p>
If there is no initial source, note that here.
</p>
</note>
</div>
<div class="source"><code>
Example (Heraldry):
OpenID has been in development since the summer of 2005. It currently
has an active community (over 15 million enabled accounts) and
libraries in a variety of languages. Additionally it is supported by
LiveJournal.com and is continuing to gain traction in the Open
Source Community.
Yadis has been in development since late 2005 and the specification
has not changed since early 2006. Like OpenID, it has libraries in
various languages and there is a large overlap between the two
communities. The specification is...
</code>
</div>
</div>
<h3 id='template-ip'>Source and Intellectual Property Submission Plan</h3>
<div class="section-content">
<div class="note">
<note>
<p>
Complex proposals (typically involving multiple code bases) may find it useful
to draw up an initial plan for the submission of the code here.
Demonstrate that the proposal is practical.
</p>
</note>
</div>
<div class="source"><code>
Example (Heraldry):
* The OpenID specification and content on openid.net from Brad
Fitzpatrick of Six Apart, Ltd. and David Recordon of VeriSign,
Inc.
* The domains openid.net and yadis.org from Brad Fitzpatrick of
Six Apart, Ltd. and Johannes Ernst of NetMesh, Inc.
* OpenID libraries in Python, Ruby, Perl, PHP, and C# from JanRain,
Inc.
...
* Yadis conformance test suite from NetMesh and VeriSign, Inc.
We will also be soliciting contributions of further plugins and
patches to various pieces of Open Source software.
</code>
</div>
</div>
<h3 id='template-external-dependencies'>External Dependencies</h3>
<div class="section-content">
<div class="note">
<note>
<p>
External dependencies for the initial source is important. Only some external dependencies
are allowed by Apache <a href="http://www.apache.org/legal/3party.html">policy</a>.
These restrictions are (to some extent) initially relaxed
for projects under incubation.
</p>
<p>
If the initial source has dependencies which would prevent graduation
then this is the right place to indicate how these issues will be resolved.
</p>
</note>
</div>
<div class="source"><code>
Example (CeltiXfire):
The dependencies all have Apache compatible licenses. These include
BSD, CDDL, CPL, MPL and MIT licensed dependencies.
</code>
</div>
</div>
<h3 id='template-cryptography'>Cryptography</h3>
<div class="section-content">
<div class="note">
<note>
<p>
If the proposal involves cryptographic code either directly or indirectly,
Apache needs to know so that the
<a href="http://www.apache.org/dev/crypto.html">relevant paperwork</a> can be obtained.
</p>
</note>
</div>
</div>
<h3 id='template-required-resources'>Required Resources</h3>
<div class="section-content">
<div class="note">
<note>
<p>
Resources that infrastructure will be asked to supply for this project.
</p>
</note>
</div>
<h4 id='template-mailing-lists'>Mailing lists</h4>
<div class="section-content">
<div class="note">
<note>
<p>
The minimum required lists are private@<em>{podling}</em>.incubator.apache.org
(for confidential <a href="ppmc.html">PPMC</a> discussions)
and dev@<em>{podling}</em>.incubator.apache.org lists.
<a href="ppmc.html#PPMC+Mail+List">Note</a>
that projects historically
misnamed the <em>private</em> list <em>pmc</em>. To
avoid confusion over appropriate usage it was
<a href="../official/mailing-lists.html#july-2005">resolved</a>
that all such lists be renamed.
</p><p>
If this project is new to open source, then starting with these minimum lists
is the best approach.
The initial focus needs to be on recruiting new developers.
Early adopters are potential developers.
As momentum is gained, the community may decide to create commit
and user lists as they become necessary.
</p><p>
Existing open source projects moving to Apache will probably want to adopt the
same mailing list set up here as they have already. However, there is no necessity
that all mailing lists be created during bootstrapping. New mailing lists can be
<a href="http://www.apache.org/dev/infra-contact">added</a>
by a <a href="http://www.apache.org/foundation/voting.html">VOTE</a>
on the Podling list.
</p>
<p>
By default, commits for <em>{podling}</em> will be emailed to
commits@<em>{podling}</em>.incubator.apache.org.
It is therefore recommended that this naming convention is adopted.
</p>
<p>
Mailing list options are described at greater length
<a href="http://wiki.apache.org/incubator/MailingListOptions">elsewhere</a>.
</p>
</note>
</div>
<div class="source"><code>
Example (Beehive):
* private@beehive.incubator.apache.org (with moderated subscriptions)
* dev@beehive.incubator.apache.org
* commits@beehive.incubator.apache.org
</code>
</div>
</div>
<h4 id='template-subversion-directory'>Subversion Directory</h4>
<div class="section-content">
<div class="note">
<note>
<p>
It is conventional to use all lower case, dash-separated (<code>-</code>) directory names.
The directory should be within the incubator directory space
(<a href="http://svn.apache.org/repos/asf/incubator">http://svn.apache.org/repos/asf/incubator</a>).
</p>
</note>
</div>
<div class="source"><code>
Example (OpenJPA):
https://svn.apache.org/repos/asf/incubator/openjpa
</code>
</div>
</div>
<h4 id='template-git-repository'>Git Repository</h4>
<div class="section-content">
<div class="note">
<note>
<p>
It is conventional to use all lower case, dash-separated (<code>-</code>) repository names.
The repository should be prefixed with incubator and later renamed assuming the project is promoted
to a TLP.
</p>
</note>
</div>
<div class="source"><code>
Example (Blur):
https://git-wip-us.apache.org/repos/asf/incubator-blur.git
</code>
</div>
</div>
<h4 id='template-issue-tracking'>Issue Tracking</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Apache runs <a href="https://issues.apache.org/jira/secure/Dashboard.jspa">JIRA</a>
and <a href="http://issues.apache.org/bugzilla/">Bugzilla</a>. Choose one. Indicate the
name by which project should be known in the issue tracking system.
</p>
</note>
</div>
<div class="source"><code>
Example (OpenJPA):
JIRA Open-JPA (OPEN-JPA)
</code>
</div>
</div>
<h4 id='template-other-resources'>Other Resources</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Describe here any other special infrastructure requirements necessary for the proposal.
Note that the infrastructure team usually requires a compelling argument
before new services are allowed on core hardware. Most proposals should not require this section.
</p>
<p>
Most standard resources not covered above (such as continuous integration)
should be added after bootstrapping.
The <a href="http://www.apache.org/dev">infrastructure documentation</a> explains
the process.
</p>
</note>
</div>
</div>
</div>
<h3 id='template-initial-committers'>Initial Committers</h3>
<div class="section-content">
<div class="note">
<note>
<p>
List of committers (stating name and an email address) used to bootstrap the community.
Mark each which has submitted a
<a href="http://www.apache.org/licenses/#clas">contributor license agreement</a> (CLA).
Existing committers should use their <code>apache.org</code> email address (since they
require only appropriate karma). Others should use the email address that is (or will be)
on the CLA. That makes it easy to match CLAs with proposed committers to the project.
</p>
<p>
It is a good idea to submit CLAs at the same time as the proposal.
Nothing is lost by having a CLA on file at Apache
but processing may take some time.
</p>
<p>
Note <a href="#developing">this</a> and
<a href="participation.html#committer">this</a>. Consider creating a separate
section where interested developers can express an interest (and possibly leave
a brief introduction) or ask them to post to the
<a href="lists.html#general+at+incubator.apache.org">general list</a>.
</p>
</note>
</div>
<div class="source"><code>
Example (OpenJPA):
Abe White (awhite at bea dot com)
Marc Prud'hommeaux (mprudhom at bea dot com)
Patrick Linskey (plinskey at bea dot com)
...
Geir Magnusson Jr (geirm at apache dot org) *
Craig Russell (clr at apache dot org) *
</code>
</div>
</div>
<h3 id='template-affiliations'>Affiliations</h3>
<div class="section-content">
<div class="note">
<note>
<p>
Little bit of a controversial
<a href="http://mail-archives.apache.org/mod_mbox/incubator-general/200608.mbox/%3c5c902b9e0608071114i4a63ed67r505691b8d53ce31@mail.gmail.com%3e">subject</a>.
Committers at Apache are <a href="http://www.apache.org/foundation/how-it-works.html#hats">individuals</a>
and work here on their own behalf. They are judged on their merits not their
affiliations. However, in the spirit of full disclosure, it is useful for
any current affiliations which may effect the perceived independence of the initial committers to be
listed openly at the start.
</p><p>
For example, those in salaried positions whose job is to work on the
project should list their affiliation. Having this list helps to judge how
much diversity exists in the initial list and so how much work there is to
do.
</p>
<p>
This is best done in a separate section away from the committers
list.
</p>
<p>
Only the affiliations of committers on the initial bootstrap list
are relevant. These committers have not been added by the usual
<a href="http://www.apache.org/foundation/how-it-works.html#meritocracy">meritocratic process</a>.
It is strongly recommended that the once a project is
bootstrapped, developers are judged by their contributions and not by their
background. This list should not be maintained after the bootstrap has been completed.
</p>
</note>
</div>
</div>
<h3 id='template-sponsors'>Sponsors</h3>
<div class="section-content">
<h4 id='template-champion'>Champion</h4>
<div class="section-content">
<div class="note">
<note>
<p>
The <a href="../incubation/Roles_and_Responsibilities.html#Champion">Champion</a> is
a person already associated with Apache who leads the proposal process. It is common
- but not necessary - for the Champion to also be proposed as a
<a href="#template-mentors">Mentor</a>.
</p>
<p>
A Champion should be found before the proposal is formally submitted.
</p>
</note>
</div>
</div>
<h4 id='template-mentors'>Nominated Mentors</h4>
<div class="section-content">
<div class="note">
<note>
<p>
Lists <a href="../incubation/Incubation_Policy.html#Mentor">eligible</a> (and willing)
individuals nominated as <a href="../incubation/Roles_and_Responsibilities.html#Mentor">Mentors</a>
[<a href="../incubation/Incubation_Policy.html#Mentor">definition</a>] for the candidate.
</p>
<p>
It is common for additional Mentors to <a href="participation.html#mentors">volunteer</a> their services
during the development of the proposal. The number of Mentors for a Podling is limited only by the
energy and interest of those eligible to Mentor. Three Mentors gives a quorum and allows
a Podling more autonomy. The current consensus is that three or more Mentors makes the
incubation process run more smoothly.
</p>
<p>
Note that since Mentors are appointed by the
<a href="../incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">
Incubator PMC</a>
at the end of the acceptance process, they have no formal role until the proposal is accepted.
But informal enthusiasm from nominee Mentors is taken as a good sign.
</p>
<p>
There is no restriction on the number of informal mentors (note the small <em>m</em>)
that a Podling may have. These can be very useful but have no formal role in the process.
</p>
</note>
</div>
</div>
<h4 id='template-sponsoring-entity'>Sponsoring Entity</h4>
<div class="section-content">
<div class="note">
<note>
<p>
The <a href="../incubation/Roles_and_Responsibilities.html#Sponsor">Sponsor</a>
is the organizational unit within Apache taking responsibility for this proposal.
The sponsoring entity can be:
</p>
<ul>
<li>the Apache Board</li>
<li>the Incubator</li>
<li>another Apache project</li>
</ul>
<p>
The PMC for the appropriate project will decide whether to sponsor (by a vote).
Unless there are strong links to an existing Apache project, it is recommended that the
proposal asks that the Incubator for sponsorship.
</p>
<p>
Note that the final destination within the Apache organizational structure
will be decided upon graduation.
</p>
</note>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="row"><div class="span16"><hr noshade="noshade" size="1"/></div></div>
<div class="row">
<div class="span16 footer">
Copyright &#169; 2009-2016 The Apache Software Foundation<br />
Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.<br/>
Apache Incubator, Apache, the Apache feather logo, and the Apache Incubator project logo are trademarks of The Apache Software Foundation.
</div>
</div>
</div>
</body>
</html>