Dear all, I have been following this discussion from afar and basically by mere luck because I happened to be subscribed to the general lucene list. I do not understand much about the main topic of this thread, because I know next to nothing about how open source development really works, and even less about Apache projects per se. I doubt that an expression of interest by a mere user will change much to the debate, but I wanted to nevertheless express a strong interest in what I perceive as being an underlying topic.
We are a small company providing services in the area of document management and textual information retrieval. We are extremely interested in a package such as Lucene, but which would have a Perl binding. In searching for such things over the years, I have encountered the names Clucene, Plucene, Lucy, and Kinosearch (as well as Lucene itself and Solr, and more distantly Xapian). I had however almost given up, because it seemed to me that not very much was happening regarding the first four named, nor in terms of a unicode-capable C (and consequently Perl) interface. I had a bit the impression that these things were quite dead. The current thread would seem to indicate that this is not really so, and to us that in itself is very good news. By reading the messages on this thread, I still don't really understand what is really going on however. Would someone care to explain what the current status is, in simple words ? As a small company, we would be interested in contributing within the limits of our capacities. Unfortunately, those do not include a high level of C programming skills. But we are specialists in "unstructured, textual" information indexing and retrieval, so at the very least we could help in testing with real-world data. We also have applications largely based on Apache and Perl, currently interfacing a high-quality proprietary text indexing and retrieval system through a self-developed Perl interface. Our basic interest lies in, over time, finding an alternative to that proprietary system. But we are much less interested in a Java-based solution, because that would really mean a huge investment for us, to rewrite much of our existing code into Java, which we are not so fond of.
