lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Rutherglen <>
Subject Re: [jira] [Commented] (SOLR-2193) Re-architect Update Handler
Date Tue, 31 May 2011 17:46:04 GMT
> If Lucid did somehow conspire to "fight improvements to Solr", that
> would be severely detrimental to its own future.

The arguments were brought up previously regarding how in the name of
"stability" refactoring Solr does not occur.  It's a touchy subject
that yes can be technically justified, however in most cases comes
from Lucid staff.  This leads one on a rather short line to the
conclusion that they don't want the "Goose" tampered with.  Many times
it seems like the Spruce Goose however.

On Tue, May 31, 2011 at 10:40 AM, Michael McCandless
<> wrote:
> Taking some of Jason's concerns here (to the dev list)... we should
> stick to technical feedback on the issue:
> On Mon, May 30, 2011 at 11:54 PM, Jason Rutherglen (JIRA)
> <> wrote:
>> It's been clear for quite a while that you folks at "Lucid" are trying to
>> protect your golden goose, eg, Solr from changing much unless dictated by
>> your staff or a paying customer. I think in politics those are called
>> bribes?
> While Apache must always be vigilant to ensure that no commercial
> entity, neither Lucid nor for example my sponsor (IBM), abuses its
> influence over any project, I don't see any evidence that Lucid is
> doing so here.
> If Lucid did somehow conspire to "fight improvements to Solr", that
> would be severely detrimental to its own future.
> Apache very much needs corporations to have a stake in projects, so
> that these corporations sponsor individual's time/itch towards
> improving things.  As long as the needs of that sponsor generally
> align well with the needs of the project, as is happening here in my
> opinion, it's win/win.
> It's also a matter of personal integrity: if there is a severe
> conflict of interest, where the sponsor wants something changed but
> the committer realizes it goes against the project / the Apache way /
> etc., then the committer should simply say "no" to the sponsor.  If
> that becomes a pattern, the committer should move on to a different
> sponsor.
> I know the active Lucene/Solr committers well enough to know that they
> all possess this integrity, so I don't see any way Lucid could conspire
> here.
>> Hence a large part of the recent fracas regarding modularizing the
>> goose, whose 'resolution' has resulted in no changes.
> I don't think Lucid was somehow conspiring here; I think certain
> individuals simply had differences in opinion.  This is par for the
> course in open source ;)  If two people always agree, one is not
> needed... disagreement is healthy.
> And I disagree that there have been no changes; in fact, it's the
> reverse: the conclusion/consensus on that "refactoring" thread is that
> people who have the itch to refactor/poach are entirely free to do so,
> as long as it does not harm Lucene/Solr.  Refactoring/poaching is the
> bread and butter of open source, one of our basic rights.
> The refactoring of the analysis module is a great example.  More
> recently, the grouping module, and then the sudden fast iterations
> adding strong improvements to its capabilities, soon to bring grouping
> to 3.x Solr, is another.  The suggest module was factored out;
> function queries has an initial baby step patch.  There's an issue
> opened to factor out faceting.
> Mike McCandless
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message