lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Revisions to Incubator proposal
Date Thu, 01 Jul 2010 17:08:29 GMT

We're on schedule.  We have a draft document, and it's looking good!

Even better, the exercise of drawing up this document has produced exactly the
benefits we hoped it would.  We have deepened our understanding of Apache
values, traditions, rules, and infrastructure.  We have refined our plan for
Lucy's growth.  

There is a possibility that this proposal won't be accepted.  But if that
happens, we have a contingency plan: leave Apache, yet continue to operate
according to many of the same procedures and values, possibly returning with a
new proposal at some later date.  We should seek to exploit any critiques that
we receive during the proposal process to help guide us, regardless of the
outcome -- just as we have attempted to make best use of the Lucene PMC's advice.

Having slept on the matter, here are some thoughts on the current proposal.

The first half of the Rationale seems fine...

    There is great hunger for a search engine library in the mode of Lucene
    which is accessible from various dynamic languages, and for one accessible
    from pure C. Individuals naturally wish to code in their language of
    choice. Organizations which do not have significant Java expertise may not
    want to support Java strictly for the sake of running a Lucene instance.
    Native applications can be launched much more quickly than JVMs. Lucy will
    meet all these demands. 

... but I'm dissatisfied with the second half:

    We acknowledge that Apache seems like a natural home for Lucy given that
    it is also the home of Lucene, and speculate that this may have been on
    the minds of the Lucene PMC when Lucy was green-lighted as a sub-project.
    More importantly, though, the Lucy development community strongly believes
    that The Apache Way is right for Lucy. 

First, this passage only asserts that we believe in The Apache Way rather than
demonstrating our understanding of it.  We should "show, not tell".  Second,
we should purge the PMC mind reading.  Who knows what they were thinking! :)
Third, I don't want to leave in any mention of Lucy belonging at Apache because
Lucene is there, too.  That's Lucy sponging off the Lucene brand, and it's not
a benefit to Apache.  We should just leave that unstated and stand on our

Here's the directive for Rationale from the proposal template:

    Explains why this project needs to exist and why should it be adopted by
    Apache. This is the right place for discursive material. 

We've covered "why this project needs to exist", but not "why it should be
adopted by Apache".  IMO the rest of the proposal does a fine job of
illustrating that point, but we need to do a better job here.  We should
examine the Rationale sections from other proposals to get a better sense of
how that might be best expressed.

The Community section does a fine job of identifying our challenges and
presenting a plan:

    Lucy currently has a small community, most members of which originated in the
    KinoSearch community.

    Lucy's chief challenge is growing its community, which it hopes to achieve
    through efforts in two areas: reaching a 1.0 release, and actively reaching
    out to its target audience, users and developers in the dynamic language
    communities who want a fast, scalable full-text search solution in their
    native language. 

Still, I think we deserve a little more credit.  We've taken a lot of flak
regarding the size of the Lucy community, but you know, if you consider how
the *KinoSearch* community has operated over the years, we haven't done so
bad.  Looking back at how Nate and I hashed out mmap support and the current
Query hierarchy, or how Chris Nandor and I collaborated on range queries, or
how Peter and I have intensified our collaboration over the last year, I see
healthy processes of negotiation and consensus building.

The one thing I don't think we've done well (and this is my fault) is handle
releases and backwards compatibility.  Father Chrysostomos put in an awful lot
of work creating a subclassable Highlighter, but later releases of KS broke
back compat on him.  Nevertheless, I think we have learned from how that
played out, and that the backwards compatibility policy we arrived at last
year goes a long way towards solving those problems.  

So, I'd like to take a look at what other projects have put in the Community
section, and maybe mod it to convey a more boffo outlook.

Another section that could stand some revision is External Dependencies.  IMO,
it provides too much detail.  We should just state that we require some CPAN
modules, but we have plans in place to eliminate them.

Lastly, it would be nice to cover our contingency plan of growing the
community and coming back with a bigger committer list at some later date.
However, I think that may arise naturally during the discussion, and it's
probably too big a topic to squeeze in.

Marvin Humphrey

View raw message