: I would guess the number of people/organizations using Lucene vs. contributing : to Lucene is much greater. : : The contributers work in head (should IMO). The users can select a particular : version of Lucene and code their apps accordingly. They can also back-port : features from a later to an earlier release. If they have limited development : resources, they are probably not working on Lucene (they are working on their : apps), but they can update their own code to work with later versions - which : they would probably rather do than learning the internals and contributing to : Lucene.
i think we have a semantic disconnect on the definition of "community" I am including any and all people/projects that use Lucene in anyway -- wether or not they contribute back or not. If there are 1000 projects using lucene as a library, and each project requires 5 man hours of work to upgrade from version X to version Y becuse of a non-backwards compatible change, but it would only take 2 man hours of work for those projects to backport / rip out the one or two features of version Y they really want to cram them into their code base then the community as a whole is paying a really heavy cost for version Y ... regardless of wether each of those 1000 projects invest the 5 hours or the 2 hours ... in the first extreme we're all spending a cumulative total of 5000 man hours. in the second case we're spending 2000 man hours, and now we've got 1000 apps that are runing hacked up unofficial offshoots of version X that will never be able to upgrade to version Z when it comes out -- the community not only becomes very fractured but lucene as a whole gets a bad wrap, because everybody talks about how they still run version X with local patches instead of using version Y -- it makes new users wonder "what's wrong with version Y?" ... "if upgrading is so hard that no one does it do i really wnat to use this library?" It may seem like a socialist or a communist or a free love hippy attitude, but if contributors and committers take extra time to develop more incrimental releases and backwards compatible API transitions it may cost them more time upfront, but it saves the community as a whole a *lot* of time in the long run. By all means: we should move forward anytime really great improvements can be made through new APIs and new features -- but we need to keep in mind that if those new APIs and features are hard for our current user base to adapt to, then we aren't doing the community as a whole any favors by throwing the baby out with the bath water and prematurely throwing away an old API in order to support the new one. Trade offs must be made. Sometimes that may mean sacrificing committer man hours; or performance; or API cleanliness; in order to reap the benefit of a strong, happy, healthy, community. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
