lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Goetz <>
Subject Re: Development plans for Lucene?
Date Wed, 30 Oct 2002 19:31:46 GMT
> The reason why the project is not very active from the development
> point of view is, in my opinion, in part because only 1 person knows
> Lucene inside out, and that person is busy on other projects.  I am
> talking about Doug Cutting.
> The stability of the core is another reason, like Peter Carlson
> mentioned.

I think this is a slightly more complicated issue than "Doug is busy."  
I think there is a philosophy issue here as well. 

Doug, forgive and correct me if I mis-state what I think your thoughts
and motivations are here.

One of the core values that made Lucene successful in the first place
is its minimalism.  Lucene is very clean, compact, and amazingly
small.  Doug has been, rightly so, very skeptical of new additions
that are not part of the core functionality.  There are lots of good
ideas floating around to make Lucene more useful (crawler, library of
file-format handlers, etc), but I think that Doug and several other
contributors would really rather see these _not_ be part of the Lucene
core.  They are valuable, but peripheral to Lucene's core task --
maintaining and searching the index.

I think the "Doug is busy" argument basically boils down to "Doug
thinks this project is mostly done."  And I would tend to agree.
Could it be improved?  For sure.  Is it missing major pieces?  I don't
think so.

There are lots of great projects that have limited development
activity -- like BCEL.  That's because they work great at what they do

> > I'm not sure why there's not a lot of immediate developer interest,
> > but 
> > my guess is exactly what you've described, that a lot of people feel 
> > that the core API is well developed and there's nowhere else to go.
> > 
> > I'm not entirely convinced of that, and I'd venture to guess that if
> > we 
> > were to take a poll, there are a lot of features outside of the core
> > API 
> > that [potential] users would love to see implemented in the software.

Depends who you polled!

> > Alternatively, I know there are some great projects in the sandbox
> > and 
> > contrib that would be great candidates for inclusion into Lucene
> > proper.

True, but I think some of these are better off as being their own
projects or sub-projects, rather than part of the core.  Its more of a
question of visibility.  One way to make them more visible/credible is
to put them in the core, but that's not the only way to do so, and I'm 
not sure that's the best way.

I think many of these ideas would be better served by combining them
into a Lucene-based application framework, combining finding files to
index (crawling), digesting them (format stripping), etc.  It wouldn't
have to be part of Lucene proper to be a very useful, flexible
package.  In fact, the issues at the application level are very
different from the issues at the core search level and call for a
different set of skills and perspectives.

I think that a good goal for the core would be to encourage developers
to build searching frameworks around Lucene so that no developer
actually has to use Lucene directly (not to suggest that Lucene is by
any means unpleasant to use directly.)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message