> 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 already. > > 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: <mailto:lucene-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:lucene-dev-help@;jakarta.apache.org>
