The Solr Bias
It’s perfectly rational for Solr’s competitors that use Lucene to argue against any changes that they see benefiting Solr. While perfectly rational and understandable on their part, it should not be allowed to have an impact on the actual development of Lucene and Solr, nor the merge designed to benefit both projects. Ongoing development of Lucene and Solr is about mutually beneficial improvement and promotion.
What may not be quite as immediately obvious is the fact that many a developer also harbors this bias. A developer who has custom code based on Lucene, may have had a coworker brainstorm or a manager ask “could we just use Solr?”. That developer may be 100% right and Solr may be the wrong solution, but the mere fact that they were forced to argue for their solution and against Solr can introduce a bias. Of course, even in those cases where Solr could be a fit, “Not Invented Here” syndrome can rear its ugly head.
I started off the Lucene/Solr merge with a more idealistic and care free attitude, not caring what things were called or where code was located, as long as we could improve both Lucene and Solr. I felt that if we could “get over the hump” and achieve a “one project, two downloads” philosophy among most of the committers, things would work out fine. That was naive. As long as the projects are still viewed as so separate by others, there will naturally exist a bias, a persistent force, acting to suppress Solr and even pushing on some of the committers. This bias, while sometimes rational and stems from self-interest, lacks technical merit and thus tends to manifest via other arguments such as the all powerful, always applicable, “users will be confused”.
The solution is to accept that the bias exists, and simply adopt frameworks and language to reduce it. For example, when factoring out a module, instead of “moving” it from Solr to Lucene, it should be a joint lucene/solr module. Simple changes in language like this will act to undercut the bias over time, as developers using the Java APIs will now be using both. This simple name change and way of thinking will no doubt cause much hand wringing and indirect attacks due to the existing bias, but developers interested in better products should simply push through that.