lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uri Boness <>
Subject RE: [OT] who are jteam ?
Date Thu, 03 Dec 2009 21:15:19 GMT
Hi Guys,

Let me pour some light on JTeam and the work we're doing with Spatial Solr.

We've been working with local lucene/solr for quite some time now (about a
year and half or more). Actually when we started, only local lucene was
available and only later local solr came out. We've been implementing
geo-location search using this functionality in several projects and in each
one we had to develop quite a bit of extra code and fix bugs.

As we state in our website, we're great believers in open source in general
(our company is partly the driving force behind the Spring Framework... our
founders are also the founders of SpringSource) and in Solr/Lucene in
particular. We believe in contributing to open source and in collaborative
transparent development.

>From early on we tried to drive local solr in the community using Solr JIRA,
and if you look carefully, some of the latest patches in the relevant issue
(SOLR-773) were contributed by us (Chris Male). We tried to follow all the
discussion in this issue and provide patches for the different approaches
that were proposed. Unfortunately, there was very little activity on this
issue for quite some time and the same goes for the local lucene project
(both on SF and the patches in Lucene JIRA). It was even the case were some
of the committers started complaining that there is no real owner for these

So we tried to push it for quite some time but in the meantime we also
needed to further develop these patches due to continuous demand from some
of our clients and the community as a whole (after all, it is the second
most voted on feature in Solr, right after the Field Collapsing which also
happens to be pushed and heavily developed by us - by Martijn). The problem
obviously rose from the nature of this functionality - it's a patch. This
meant that clients that wanted to use it needed to have their own patched
version of Solr and I believe I don't need to explain that they were not
very amused by this fact.. in a way it put Solr in a bad light...  So we
took a decision to implement the exact same solution that we've committed as
patches but this time make it a proper plugin - one that can be jar'ed,
dropped in Solr lib directory and configured in solrconfig.xml... without
patching involved.

I'm sure you all know the balance game between open source and commercial
work. It is/was very hard for us to put and invest so much time in something
without getting paid for the time spent. This is the reason we decided to at
least sell support over this functionality. The plug-in itself is open
source and is available for anyone to download. We're not hiding anything.
The fact is, that a lot of companies just need support for these kind of
issues, specially when it still not provided by Solr and they need to find
their way in Solr JIRA to have it (not many people can or like to do that).
I see no problem with this model, in a way this is our commercial aspect of
this open source work that we're doing, I see no problem with it - this is
how SpringSource, JBoss, and Lucid (and many many other companies) do it. By
the end of the day we all need to put some food on the table.

So to make things a bit clearer. We're not taking any ownership on work that
is not ours, and in fact we try to commit all our work back to the community
under the Apache2 license. We tried to commit this code base to Solr and
we'll continue this efforts. We would be *extremely* happy if at least some
of it will be committed as we believe we did cleaned it up quite a bit and
made it much more extensible (BTW, mainly on the lucene part). We've been
active in the discussions in the JIRA issues and we'll continue to be
active... actually we were just about to have another major patch put in
Lucene's JIRA with all our code base. (probably will happen in the upcoming
week). I really recommend everyone that is interested to have a look at the
patches we're providing and we're always open for discussion on how these
can be integrated with the current committed code base and with the road map
of this functionality in general.

Feedback is more than welcome!


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message