<?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"
	>
<channel>
	<title>Comments on: Google and the Future of Package Management</title>
	<atom:link href="http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/feed/" rel="self" type="application/rss+xml" />
	<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/</link>
	<description>because technology is just another ecosystem</description>
	<pubDate>Tue, 02 Dec 2008 07:35:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: &#187; Google to the rescue: FETCH! With Ruff Ruffman CQ2</title>
		<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-178558</link>
		<dc:creator>&#187; Google to the rescue: FETCH! With Ruff Ruffman CQ2</dc:creator>
		<pubDate>Tue, 09 Oct 2007 15:48:22 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-178558</guid>
		<description>[...] which I don&#8217;t understand, with package management; but Stephen O&#8217;Grady tells me it is, so it [...]</description>
		<content:encoded><![CDATA[<p>[...] which I don&#8217;t understand, with package management; but Stephen O&#8217;Grady tells me it is, so it [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeffrey W. Baker</title>
		<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-116764</link>
		<dc:creator>Jeffrey W. Baker</dc:creator>
		<pubDate>Wed, 04 Jul 2007 17:27:45 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-116764</guid>
		<description>You know, disintermediation might sound good when you say it, but I think it's a bad idea.  The nice thing about the Ubuntu or Debian process is there exists a layer of people capable of making the decision that some software is not good enough to expose to the average user.  If the software fails to build on some architectures, it won't make it in.  If the software has some grave bug (removing another package's files, for example) then it won't go in.  The package maintainers are responsible for timely security fixes that sometimes even the upstream provider won't fix.

I wouldn't trust Google with that role because their incentives are not properly aligned with my goals as a user, and they don't have any track record of performing that function.</description>
		<content:encoded><![CDATA[<p>You know, disintermediation might sound good when you say it, but I think it&#8217;s a bad idea.  The nice thing about the Ubuntu or Debian process is there exists a layer of people capable of making the decision that some software is not good enough to expose to the average user.  If the software fails to build on some architectures, it won&#8217;t make it in.  If the software has some grave bug (removing another package&#8217;s files, for example) then it won&#8217;t go in.  The package maintainers are responsible for timely security fixes that sometimes even the upstream provider won&#8217;t fix.</p>
<p>I wouldn&#8217;t trust Google with that role because their incentives are not properly aligned with my goals as a user, and they don&#8217;t have any track record of performing that function.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Donnie Berkholz</title>
		<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-113611</link>
		<dc:creator>Donnie Berkholz</dc:creator>
		<pubDate>Sat, 30 Jun 2007 05:08:42 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-113611</guid>
		<description>Sun Studio's Linux version is available as a big pack of RPMs. 75 or so.</description>
		<content:encoded><![CDATA[<p>Sun Studio&#8217;s Linux version is available as a big pack of RPMs. 75 or so.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: &#187; News to know: iPhone alternatives; Desktop virtualization diaries; Hacker&#8217;s road to riches &#124; Between the Lines &#124; ZDNet.com</title>
		<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-113036</link>
		<dc:creator>&#187; News to know: iPhone alternatives; Desktop virtualization diaries; Hacker&#8217;s road to riches &#124; Between the Lines &#124; ZDNet.com</dc:creator>
		<pubDate>Fri, 29 Jun 2007 11:55:44 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-113036</guid>
		<description>[...] Stephen O&#8217;Grady: Google and the Future of Package Management [...]</description>
		<content:encoded><![CDATA[<p>[...] Stephen O&#8217;Grady: Google and the Future of Package Management [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daily links - 29.06.2007 : TrendPlex</title>
		<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-113015</link>
		<dc:creator>Daily links - 29.06.2007 : TrendPlex</dc:creator>
		<pubDate>Fri, 29 Jun 2007 11:38:57 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-113015</guid>
		<description>[...] Google and the Future of Package Management [...]</description>
		<content:encoded><![CDATA[<p>[...] Google and the Future of Package Management [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dalibor Topic</title>
		<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-112994</link>
		<dc:creator>Dalibor Topic</dc:creator>
		<pubDate>Fri, 29 Jun 2007 10:39:21 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-112994</guid>
		<description>I think, like the Google Pack, Google could actually take over the (presumably financially interesting) role of being the default channel for ISVs for the cross-platform  software management experience. But, like Google Pack, I doubt this will go very far beyond the initial splash. 

Google has a similar problem like many proprietary software makers wrt their Linux offers: getting the software out there in a way that does not make the users suffer. They could go to distributions directly, but in Google's case, that would almost certainly be a failure, given that the Picasa EULA requires distributors to do some rather outlandish things, like having to bind their organizations to Google's EULA, or mandating that a single copy (+ one backup copy) of the software exists, which makes mirroring of the distribution pointless, etc. The proprietary distribution model with a single, controlled point of distribution, and the Linux distribution model with many autonomous points of distribution, don't play well with each other, and licenses that try to enforce the former model can't really fit into the later.

One major problem with the routing around the distributions in order to preserve restrictive licensing is that one's own packages can't rely on the distributions caring about them (because they don't know they exist), i.e. in the long run stuff breaks, because the underlying package dependencies change, and then users suffer from a bad upgrade/installation experience, quite unlike magic. The external proprietary software repositories for Fedora, for example, have long suffered from such 'platform drift' effects.

The LSB is supposed to make that problem go away for ISVs, I guess.  I have no idea how well it does, as I've never heard of an LSB-compliant package being advertised as such. So I guess it's not being marketed to me, as an end user. :)

On the other hand, the Linux channel is the only channel where ISVs can 'make a deal' with the channel operators, and try to establish their products as part of the 'magic' out-of-the-box experience of the platform. Neither Microsoft nor Apple are really interested in that. Cutting themselves free from the necessity to cooperate with distributions can be an initially appealing proposition, but in general that also means being cut off from the user support channels that distributions offer, and requires an investment in one's own infrastructure. 

Whether that makes sense is a matter of the community &#38; branding strategy, I guess.</description>
		<content:encoded><![CDATA[<p>I think, like the Google Pack, Google could actually take over the (presumably financially interesting) role of being the default channel for ISVs for the cross-platform  software management experience. But, like Google Pack, I doubt this will go very far beyond the initial splash. </p>
<p>Google has a similar problem like many proprietary software makers wrt their Linux offers: getting the software out there in a way that does not make the users suffer. They could go to distributions directly, but in Google&#8217;s case, that would almost certainly be a failure, given that the Picasa EULA requires distributors to do some rather outlandish things, like having to bind their organizations to Google&#8217;s EULA, or mandating that a single copy (+ one backup copy) of the software exists, which makes mirroring of the distribution pointless, etc. The proprietary distribution model with a single, controlled point of distribution, and the Linux distribution model with many autonomous points of distribution, don&#8217;t play well with each other, and licenses that try to enforce the former model can&#8217;t really fit into the later.</p>
<p>One major problem with the routing around the distributions in order to preserve restrictive licensing is that one&#8217;s own packages can&#8217;t rely on the distributions caring about them (because they don&#8217;t know they exist), i.e. in the long run stuff breaks, because the underlying package dependencies change, and then users suffer from a bad upgrade/installation experience, quite unlike magic. The external proprietary software repositories for Fedora, for example, have long suffered from such &#8216;platform drift&#8217; effects.</p>
<p>The LSB is supposed to make that problem go away for ISVs, I guess.  I have no idea how well it does, as I&#8217;ve never heard of an LSB-compliant package being advertised as such. So I guess it&#8217;s not being marketed to me, as an end user. <img src='http://redmonk.com/sogrady/wp/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>On the other hand, the Linux channel is the only channel where ISVs can &#8216;make a deal&#8217; with the channel operators, and try to establish their products as part of the &#8216;magic&#8217; out-of-the-box experience of the platform. Neither Microsoft nor Apple are really interested in that. Cutting themselves free from the necessity to cooperate with distributions can be an initially appealing proposition, but in general that also means being cut off from the user support channels that distributions offer, and requires an investment in one&#8217;s own infrastructure. </p>
<p>Whether that makes sense is a matter of the community &amp; branding strategy, I guess.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael R. Bernstein</title>
		<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-112937</link>
		<dc:creator>Michael R. Bernstein</dc:creator>
		<pubDate>Fri, 29 Jun 2007 07:37:36 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-112937</guid>
		<description>So, there is a natural infrastructure play here: Google can offer integrated repo mgmt. to their Google Code project hosting.</description>
		<content:encoded><![CDATA[<p>So, there is a natural infrastructure play here: Google can offer integrated repo mgmt. to their Google Code project hosting.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arcadian Visions &#187; Managing Google&#8217;s Packages</title>
		<link>http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-112918</link>
		<dc:creator>Arcadian Visions &#187; Managing Google&#8217;s Packages</dc:creator>
		<pubDate>Fri, 29 Jun 2007 06:32:40 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/06/28/google-and-the-future-of-package-management/#comment-112918</guid>
		<description>[...] O&#8217;Grady suggests that Google providing their own package repository may herald a future of ISV-managed repositories [...]</description>
		<content:encoded><![CDATA[<p>[...] O&#8217;Grady suggests that Google providing their own package repository may herald a future of ISV-managed repositories [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
