Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <579683616.54989.1306814087420.JavaMail.tomcat@hel.zones.apache.org>
References: <28083189.52511287972498990.JavaMail.jira@thor>
	<579683616.54989.1306814087420.JavaMail.tomcat@hel.zones.apache.org>
Date: Tue, 31 May 2011 13:40:07 -0400
Message-ID: <BANLkTi=Hgi1mn7spxcnpnXxp3aEK8+JOhA@mail.gmail.com>
Subject: Re: [jira] [Commented] (SOLR-2193) Re-architect Update Handler
From: Michael McCandless <lucene@mikemccandless.com>
To: dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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)
<jira@apache.org> 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

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org