Grant’s Grunts: Lucene Edition

The difficulty inherent in managing an open-source community | The Open Road – The Business and Politics of Open Source by Matt Asay – CNET News
To remedy this, our development team has made a wide range of improvements and fixes to the Lucene code. At one time the team tried repeatedly to contribute the code back to the Lucene project, only to have it fall on deaf ears.

Not that our team is necessarily much better. I’ve seen outside contributions make their way into the core Alfresco code, but I’ve also seen our developers turn up their noses at outside contributions. It either wasn’t up to the level of code quality that the engineers expected or simply wasn’t of interest to them.

This isn’t to criticize my engineers or on those within the Lucene community. It’s just to point out that open-source project leads and participants have their own priorities, priorities that outsiders may struggle to appreciate and embrace. To contribute code to a community effectively, you must become part of that community, which generally involves a great deal of time and effort.

I don’t think we necessarily have deaf ears nor do we turn up our noses at outsiders, but sometimes I think it is hard to keep up with a successful open source project.  We get lots of bugs, new features requests, etc. and many of them are incomplete.  Personally, I often look at a patch and if it doesn’t have unit tests, I move on to the next one (although I usually add a comment to such).  Matt, if you have specific issues you want looked at, ask on java-dev and make sure your patches are up to date.

If one wants their code back in Lucene, they can’t just patch and run.  Sometimes, it isn’t always obvious that there is a bug, either.  Also, does the patch have unit tests?  Is it back-compatible?  Did the contributor follow the How To Contribute page?  Can a committer easily apply the Patch Check List to your contribution? Did they follow up on it to see if there are any problems?  Often times, a simple question like “Is there anything else I can do to make this ready for committing?” is sufficient.  Additionally, we strongly believe the core should be kept under tight control, in other words, does your patch better belong as a contrib?

At the end of the day, we’re all volunteers.  That’s not an excuse, I willing choose to do what I do.  However, if you want your code in, make it easy for me to judge the quality of it.  Beyond that, our standards for becoming a committer are 3 or 4 good solid patches that show an understanding of what you are doing at a deep level in the core.  Than you can put in your own patches!