A weeks ago I wrote a call for help for Lucene.Net: not enough activity and not enough contributors. A lot happened since that post so I think it’s worth doing a little recap of what the situation is now.
What happened?
The newsletter thread received hundreds of emails, and lot of discussion on my post as well. Most of the discussions were about trying to understand the reason of such a lack of activity and committers, and try not to repeat the same errors: it turned out that most people think the reason is that Lucene.Net is “just” a line-by-line port of the the Java version, it feels obsolete (both because of the site not being updated and not official release, and because it is still a VS2005 project) , and because there are very strict rules that have to be followed inside the ASF.
The official position of the main committer
At the end, following the latest answer by one the first committers of the project, George Aroush, the final decision has been to try and revive the development on Lucene.Net in its current state, hosted in the ASF and being a line-by-line port of the Java version, by the end of 2010, as per request of the Board (otherwise the project will go in the Attic). And once this goal of keeping Lucene.Net alive is accomplished, they will start working on the 3.x version, and only then they will decide whether to keep the Java-like approach or making a more .NET-like API but still keeping the convenience of having the line-by-line port from the Java version.
Forking Lucene.Net
The email from George left a bad taste on my mouth, and apparently I was not the only one what that feeling. There are developers, especially the ones that could get involved, that care about which VCS you use, which version of the IDE you use, which development process and which conventions you use, and hate dealing with politics, boards, release voting and so on. Many probably just stepped away from the discussion (like I did), but other decided to go a step forward and forked Lucene.Net.
Actually there are two project (that I know of):
- Lucere.Net, which would like to build a “conceptual port” in order to have both the internals and the external API following the conventions and paradigm of .NET development and libraries. It was started by Troy Howard, one of the most active commenter on my post, which already setup also a google group.
- Aimee.net, which has a slightly less ambitious goal: just nettify the current Lucene.Net API, converting getter/setter methods to properties, using enums instead of classes-used-as-enums. And this project is backed by CodeProject.com
I have not time to contribute to these projects, but I’ll be following the developments and see where they go. Having a real .NET version of Lucene will not hurt :)
What to do?
For reasons I’ve not fully understood people are seeming me as a kind of authority in the Lucene.Net, and I got quite a few emails from people asking what they should do now that Lucene.Net is in such a bad situation. My personal opinion is that Lucene.Net, even if it doesn’t have official releases, is a solid library, which powers lot of projects, and you should keep on using it. Even if the project is not very appealing for developers to contribute to, from the end user point of view it is an awesome library, and it has all the features that you might need from a full-text search engine.
So, keep on using it, but also keep an eye on those two projects if you want a more idiomatic API and want to take advantage of all the goodness the latest versions .NET brought to the table.