On Thu, 2010-11-18 at 15:00 +0100, Karell Ste-Marie wrote: > I think that in the end, there should be at least 3 projects for Lucene: > 1. The Lucene algorithms, in a platform-neutral language - let the search > engine gurus implement how this should be done without having to worry about > imperative programming and the hacks to get there - either a compiler or a > manual model would be used to implement these algorithms > 2. Lucene - Architecture of the project(s) - perhaps a lot of UML here in a > format where it can be fed to quickly produce skeleton files > 3.x. Lucene - language-specific versions
Speaking as a computer scientist, this looks like a text book example of a solid multi-level development workflow. Perfect for a well-defined hierarchy of dependable workers. Speaking as a rookie contributor to Lucene (I wrote some code for https://issues.apache.org/jira/browse/LUCENE-1990), I very much doubt that I would have contributed if that workflow was in place. Let me try and explain why. LUCENE-1990 was an isolated and fairly simple task: Do some bit fiddling to pack integers and perform some tests to find the best solution. It was fun to do and I think the implementation works well (no conditionals or heavy math in the core get/set methods) and should work just about the same in other languages as it is nearly pure math and arrays. Theoretically the easily abstractable nature of this plays very well with the top-down approach that you present. The problem is that step 1 (the algorithm in the platform-neutral language) requires me to learn that language and learn the extra steps necessary to contribute in such manner. I also need to know enough about step 2 to decide whether I had to update some diagrams and in general doing work that I find boring. I can see that you are "C.I.O. - BrainBank Inc" and a quick look at your website tells me that handling complex multi-level integration is second nature to you. I am a bear of very little brain and organizations and politics bother me. Hacker's Delight is 7 cm from my left hand (I measured with my multitool): I'll come up with algorithms, I'll discuss them, I'll implement them, I'll test them, I'll even write JavaDocs, I'll do it all for free - although most of it in on the company dime. And I'll have fun doing it. Ask me to step outside of my coding comfort zone and the chance of me volunteering will drop sharply. My message is that a fundamental change of participation requirements for the Lucene project means that some participants will not play along anymore and other people will be attracted to the project. This might turn out to be a very good thing for Lucene or it might seriously hamper development. My gut feeling says the latter, but then again, I'm biased by being firmly in the low-level group. Regards, Toke Eskildsen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
