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".. http://wiki.apache.org/lucy/LucyIncubatorProposal?action=diff&rev1=2&rev2=3 -------------------------------------------------- ## page was renamed from GraduationPlan + + For reference, see the original template at [http://incubator.apache.org/guides/proposal.html] + == 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 jobs. - 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 ==
