lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lucy Wiki] Update of "LucyIncubatorProposal" by MarvinHumphrey
Date Wed, 30 Jun 2010 04:38:25 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lucy Wiki" for change notification.

The "LucyIncubatorProposal" page has been changed by MarvinHumphrey.
The comment on this change is: Fill out a few of the Known Risks..
http://wiki.apache.org/lucy/LucyIncubatorProposal?action=diff&rev1=17&rev2=18

--------------------------------------------------

  A third priority of ours is to be bound by existing Apache institutions, for the protection
of all our stakeholders.
  
  == Known Risks ==
- 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.
  
  === Orphaned products ===
- A public commitment to future development.
+ All three initial committers have been associated with the project for several years across
multiple jobs.  However, at this time, the project would probably not survive the departure
of the the founder, Marvin Humphrey, so there is a risk of being orphaned.  Marvin has no
plans to leave, but as a community we have been actively working to make him dispensable.
  
- Recruiting a diverse development community and strong user base takes time. Apache needs
to be confident that the proposers are committed. 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.
- 
- 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.
- 
- 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.
  
  === Inexperience with Open Source ===
  
@@ -76, +70 @@

  
  
  === Homogenous Developers ===
+ Our community is geographically dispersed, with members in San Diego, Oakland, and Minneapolis.
 We all work for different organizations.
- 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.
- 
- 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. 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.
- 
- 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 <http://www.dancres.org/blitz/>, and Mark is veteran of much Jini-based
development, including commercial work at Virgil <http://www.virgil.nl> as well as leading
the open source Cheiron <http://www.cheiron.org> project.
- 
- 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.
  
  === Reliance on Salaried Developers ===
- All three initial committers associated with the project for several years across multiple
jobs.
+ Marvin Humphrey is currently employed primarily to work on this project and to support applications
that use it.
  
  === Relationships with Other Apache Products ===
  When Lucy was conceived, we envisioned that our eventual sub-communities (Perl, Ruby, etc)
would approach using and extending the library in distinct ways, and that we would be able
to harness the creative tension between the different cultures to drive innovation.  Lucy
and Lucene have that kind of a relationship today, and multiple significant novelties have
either cross-pollinated or arisen while discussing competing approaches.  (e.g. object conservation
during indexing, per-segment search.)

Mime
View raw message