lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Lucy Wiki] Update of "LucyIncubatorProposal" by MarvinHumphrey
Date Sun, 27 Jun 2010 01:57:14 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: Add link to original template.  Flesh out "Relationships" section,
add stubs for "Apache Brand", "Salaried Devs", "Affiliations"..


  ## page was renamed from GraduationPlan
+ For reference, see the original template at []
  == Abstract ==
  A short descriptive summary of the project. A short paragraph, ideally one sentence in length.
@@ -114, +117 @@

  === Reliance on Salaried Developers ===
+ All three initial committers associated with the project for several years across multiple
- 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.
- Apache is about people, not corporations. We hope that developers continue to be involved
with Apache no matter who their current employer happens to be.
- 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.
- 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.
- 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.
- 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.
  === Relationships with Other Apache Products ===
- 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.
+ 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.)
+ Still, Lucy is a loose port and its core differs in fundamental ways from that of Lucene.
 The biggest difference is that for Lucy, "the OS is our JVM":  Lucene Searcher objects build
up optimized data structures at search-time in process RAM, while Lucy writes its data structures
to disk at index-time and reads them via memory-mapped IO at search-time.  This affords Lucy
several advantages, such as fast process launch, low process RAM requirements, and OO design
flexibility because Lucy's "cheap Searcher" objects are lightweight, thin wrappers around
the system IO cache.
- This is a an opportunity to talk about existing links. It is also the right place to talk
about potential future links and plans.
- Apache allows different projects to have competing or overlapping goals. However, this should
mean friendly competition between codebases and cordial cooperation between communities.
- 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.
- 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.
- 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.
  === A Excessive Fascination with the Apache Brand ===
- 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.
+ Lucy's past sins:
- 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.
- 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.
+   * Failed to release early and often.
+   * Failed to build community.
+ Proposal is intended to address those deficiencies.
- 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.
- 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.
  == Documentation ==
@@ -222, +207 @@

  == Affiliations ==
+ Marvin Humphrey is employed by Eventful, Inc and works primarily on this project.
- Little bit of a controversial subject. Committers at Apache are individuals 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.
- 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.
- This is best done in a separate section away from the committers list.
- Only the affiliations of committers on the initial bootstrap list are relevant. These committers
have not been added by the usual meritocratic process. 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.
  == Sponsors ==

View raw message