<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Lucene and the Corporate Environment</title>
	<atom:link href="http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/feed/" rel="self" type="application/rss+xml" />
	<link>http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/</link>
	<description>Thoughts on Apache Lucene, Mahout, Solr, Tika and Nutch</description>
	<lastBuildDate>Sat, 10 Sep 2011 20:15:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: An example of Open Source we use &#8211; Apache Lucene &#124; elnblog.com</title>
		<link>http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/comment-page-1/#comment-6790</link>
		<dc:creator>An example of Open Source we use &#8211; Apache Lucene &#124; elnblog.com</dc:creator>
		<pubDate>Mon, 20 Jul 2009 17:18:27 +0000</pubDate>
		<guid isPermaLink="false">http://lucene.grantingersoll.com/?p=227#comment-6790</guid>
		<description>[...] This blog post includes the following very relevant thought: Apache Lucene/Solr is used in more companies than a large majority, if not all, of the commercial vendors out there combined [...]</description>
		<content:encoded><![CDATA[<p>[...] This blog post includes the following very relevant thought: Apache Lucene/Solr is used in more companies than a large majority, if not all, of the commercial vendors out there combined [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Douglass</title>
		<link>http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/comment-page-1/#comment-6783</link>
		<dc:creator>Robert Douglass</dc:creator>
		<pubDate>Sun, 19 Jul 2009 21:50:05 +0000</pubDate>
		<guid isPermaLink="false">http://lucene.grantingersoll.com/?p=227#comment-6783</guid>
		<description>This is a sentiment I see in other open source projects too. It somehow has to do with the fact that a product that the engineers can download and use for free often sneaks in the back door and becomes part of the landscape. A proprietary package has to go through a formal vetting process, and hardly ever arrives unnoticed. And yes, the open source products often deliver more value, albeit with less fanfare.

You said something, though, that helped me put a finer point on why the Drupal integration with Solr is so cool: &quot;The fact is, that modeling is required by all the vendors due to the nature of search.&quot; Yes! And in Drupal, you do the modeling while you build your site, and Drupal then conveys this model to Solr automatically, so in most cases, the site builder doesn&#039;t need to pick a special model for the search - it&#039;s already there as a result of deciding how to build the site. Thanks for stating it so succinctly.

(the Drupal module: http://drupal.org/project/apachesolr )</description>
		<content:encoded><![CDATA[<p>This is a sentiment I see in other open source projects too. It somehow has to do with the fact that a product that the engineers can download and use for free often sneaks in the back door and becomes part of the landscape. A proprietary package has to go through a formal vetting process, and hardly ever arrives unnoticed. And yes, the open source products often deliver more value, albeit with less fanfare.</p>
<p>You said something, though, that helped me put a finer point on why the Drupal integration with Solr is so cool: &#8220;The fact is, that modeling is required by all the vendors due to the nature of search.&#8221; Yes! And in Drupal, you do the modeling while you build your site, and Drupal then conveys this model to Solr automatically, so in most cases, the site builder doesn&#8217;t need to pick a special model for the search &#8211; it&#8217;s already there as a result of deciding how to build the site. Thanks for stating it so succinctly.</p>
<p>(the Drupal module: <a href="http://drupal.org/project/apachesolr" rel="nofollow">http://drupal.org/project/apachesolr</a> )</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: grant_ingersoll</title>
		<link>http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/comment-page-1/#comment-6776</link>
		<dc:creator>grant_ingersoll</dc:creator>
		<pubDate>Sat, 18 Jul 2009 17:13:30 +0000</pubDate>
		<guid isPermaLink="false">http://lucene.grantingersoll.com/?p=227#comment-6776</guid>
		<description>Sure, I get where the &quot;packaging&quot; thing comes from, especially in concerns to pure, Java Lucene, which is just a library, i.e. a bunch of APIs.  However, the point I&#039;m trying to make is these people who throw out the &quot;packaging&quot; argument make it sound like it is so hard to do and that you need to have a PHd in Information Retrieval to implement Lucene or Solr and that, simply isn&#039;t true, as is evidenced by the VERY LARGE number of people who have already done it. 

I&#039;ve seen plenty of installations of &quot;packaged&quot; vendors now that I feel comfortable saying Solr, in most cases, requires roughly the same amount of work, if not less than any of them.</description>
		<content:encoded><![CDATA[<p>Sure, I get where the &#8220;packaging&#8221; thing comes from, especially in concerns to pure, Java Lucene, which is just a library, i.e. a bunch of APIs.  However, the point I&#8217;m trying to make is these people who throw out the &#8220;packaging&#8221; argument make it sound like it is so hard to do and that you need to have a PHd in Information Retrieval to implement Lucene or Solr and that, simply isn&#8217;t true, as is evidenced by the VERY LARGE number of people who have already done it. </p>
<p>I&#8217;ve seen plenty of installations of &#8220;packaged&#8221; vendors now that I feel comfortable saying Solr, in most cases, requires roughly the same amount of work, if not less than any of them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jukka Zitting</title>
		<link>http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/comment-page-1/#comment-6775</link>
		<dc:creator>Jukka Zitting</dc:creator>
		<pubDate>Sat, 18 Jul 2009 16:31:42 +0000</pubDate>
		<guid isPermaLink="false">http://lucene.grantingersoll.com/?p=227#comment-6775</guid>
		<description>&gt; given all the people that have gotten past it

Agreed, though as shown by the original statement and the trackback above, not everyone is in this position either for real or perceived reasons. And often those people can and want to work around the issue by throwing money at it.

In such cases it&#039;s often more attractive to throw that money to an established vendor with a &quot;packaged&quot; solution, than to hire someone to set up a custom system based on open source project. Even when the latter would be technically superior and much cheaper!

So yeah, while the notion of &quot;packaging&quot; may well be overrated, there&#039;s still a good point here. Instead of &quot;really succeed&quot; in the quote above, I&#039;d say &quot;better succeed&quot;.</description>
		<content:encoded><![CDATA[<p>&gt; given all the people that have gotten past it</p>
<p>Agreed, though as shown by the original statement and the trackback above, not everyone is in this position either for real or perceived reasons. And often those people can and want to work around the issue by throwing money at it.</p>
<p>In such cases it&#8217;s often more attractive to throw that money to an established vendor with a &#8220;packaged&#8221; solution, than to hire someone to set up a custom system based on open source project. Even when the latter would be technically superior and much cheaper!</p>
<p>So yeah, while the notion of &#8220;packaging&#8221; may well be overrated, there&#8217;s still a good point here. Instead of &#8220;really succeed&#8221; in the quote above, I&#8217;d say &#8220;better succeed&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: grant_ingersoll</title>
		<link>http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/comment-page-1/#comment-6774</link>
		<dc:creator>grant_ingersoll</dc:creator>
		<pubDate>Sat, 18 Jul 2009 12:34:26 +0000</pubDate>
		<guid isPermaLink="false">http://lucene.grantingersoll.com/?p=227#comment-6774</guid>
		<description>Yeah, Jukka, I know.  My point is mostly that this notion of &quot;packaging&quot; seems to be a bit overrated, given all the people (and that number is very high) that somehow have gotten past it, and like me when I started on Lucene, they aren&#039;t necessarily IR experts by training.

Lucene, of course, is a very different beast from Solr.  Lucene is and will always be a Java library.  Of course that takes more work.

As for all the other bullet points, Lucid (http://www.lucidimagination.com) offers all of them.</description>
		<content:encoded><![CDATA[<p>Yeah, Jukka, I know.  My point is mostly that this notion of &#8220;packaging&#8221; seems to be a bit overrated, given all the people (and that number is very high) that somehow have gotten past it, and like me when I started on Lucene, they aren&#8217;t necessarily IR experts by training.</p>
<p>Lucene, of course, is a very different beast from Solr.  Lucene is and will always be a Java library.  Of course that takes more work.</p>
<p>As for all the other bullet points, Lucid (<a href="http://www.lucidimagination.com" rel="nofollow">http://www.lucidimagination.com</a>) offers all of them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jukka Zitting</title>
		<link>http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/comment-page-1/#comment-6773</link>
		<dc:creator>Jukka Zitting</dc:creator>
		<pubDate>Sat, 18 Jul 2009 07:17:48 +0000</pubDate>
		<guid isPermaLink="false">http://lucene.grantingersoll.com/?p=227#comment-6773</guid>
		<description>I would interpret &quot;packaging&quot; as being more than just the arrangement of bits and the wrapping around it. Deploying and maintaining a search engine is hardly a trivial operation, and having a proper deployment project followed by maintenance service tied up with the &quot;purchase&quot; of the product is really valuable in environments where people don&#039;t have the luxury of the time to really understand the technology or to hang around on mailing lists asking questions and picking up advice.

So, here&#039;s how I would package an &quot;enterprise search&quot; product based on Apache Lucene:

* The bits from official Apache Lucene releases
* Set of useful extra tools and plugins (proprietary and/or open source)
* Good integration for a smooth OOTB experience
* Guides for getting started with, using and administering the search engine
* List of supported platforms with recommended scale (backed by an organized QA process)
* Option to do a deployment project (at cost X/day) with a (certified?) Lucene search expert
* Option for a maintenance service (at costs per level) backed by an organized support team with a ticketing system

That&#039;s quite a bit added value on top of the plain open source project, and I&#039;m sure there are many places that are happy to pay for that value.

As far as I can tell, Lucid seems to be on a good track to providing all of these items. When do we see a product coming out?</description>
		<content:encoded><![CDATA[<p>I would interpret &#8220;packaging&#8221; as being more than just the arrangement of bits and the wrapping around it. Deploying and maintaining a search engine is hardly a trivial operation, and having a proper deployment project followed by maintenance service tied up with the &#8220;purchase&#8221; of the product is really valuable in environments where people don&#8217;t have the luxury of the time to really understand the technology or to hang around on mailing lists asking questions and picking up advice.</p>
<p>So, here&#8217;s how I would package an &#8220;enterprise search&#8221; product based on Apache Lucene:</p>
<p>* The bits from official Apache Lucene releases<br />
* Set of useful extra tools and plugins (proprietary and/or open source)<br />
* Good integration for a smooth OOTB experience<br />
* Guides for getting started with, using and administering the search engine<br />
* List of supported platforms with recommended scale (backed by an organized QA process)<br />
* Option to do a deployment project (at cost X/day) with a (certified?) Lucene search expert<br />
* Option for a maintenance service (at costs per level) backed by an organized support team with a ticketing system</p>
<p>That&#8217;s quite a bit added value on top of the plain open source project, and I&#8217;m sure there are many places that are happy to pay for that value.</p>
<p>As far as I can tell, Lucid seems to be on a good track to providing all of these items. When do we see a product coming out?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lucene / Solr still needs hackers to get up and running &#124; Productification</title>
		<link>http://lucene.grantingersoll.com/2009/07/17/lucene-and-the-corporate-environment/comment-page-1/#comment-6770</link>
		<dc:creator>Lucene / Solr still needs hackers to get up and running &#124; Productification</dc:creator>
		<pubDate>Sat, 18 Jul 2009 02:23:16 +0000</pubDate>
		<guid isPermaLink="false">http://lucene.grantingersoll.com/?p=227#comment-6770</guid>
		<description>[...] read an article posted on the Lucene blog - &#8220;Lucene and the Corporate Environment&#8221; If the list of companies using Lucene are not “corporate” environments, then I don’t [...]</description>
		<content:encoded><![CDATA[<p>[...] read an article posted on the Lucene blog &#8211; &#8220;Lucene and the Corporate Environment&#8221; If the list of companies using Lucene are not “corporate” environments, then I don’t [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

