> 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 <luc...@mikemccandless.com> 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) > <j...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
