<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Forced Upgrades</title>
	<atom:link href="http://blog.simeonov.com/2008/06/06/forced-upgrades/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.simeonov.com/2008/06/06/forced-upgrades/</link>
	<description>Simeon Simeonov on entrepreneurship, innovation &#38; venture capital</description>
	<lastBuildDate>Thu, 19 Jan 2012 15:31:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Facebook&#8217;s Terms of Service Change: A Line in The Sand &#171; HighContrast</title>
		<link>http://blog.simeonov.com/2008/06/06/forced-upgrades/#comment-17769</link>
		<dc:creator><![CDATA[Facebook&#8217;s Terms of Service Change: A Line in The Sand &#171; HighContrast]]></dc:creator>
		<pubDate>Mon, 16 Feb 2009 23:17:02 +0000</pubDate>
		<guid isPermaLink="false">http://simeons.wordpress.com/?p=274#comment-17769</guid>
		<description><![CDATA[[...] note: this ties to the broader issue of forced upgrades in SaaS, PaaS and IaaS (the broad set of cloud-based services). It shows how not just software [...]]]></description>
		<content:encoded><![CDATA[<p>[...] note: this ties to the broader issue of forced upgrades in SaaS, PaaS and IaaS (the broad set of cloud-based services). It shows how not just software [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simeon Simeonov</title>
		<link>http://blog.simeonov.com/2008/06/06/forced-upgrades/#comment-17339</link>
		<dc:creator><![CDATA[Simeon Simeonov]]></dc:creator>
		<pubDate>Wed, 18 Jun 2008 23:36:43 +0000</pubDate>
		<guid isPermaLink="false">http://simeons.wordpress.com/?p=274#comment-17339</guid>
		<description><![CDATA[Tony, yes, backward compatibility is a multi-edged sword. Many of the current mashup APIs are not versioned (not even their URLs) so it&#039;ll be interesting to see how things evolve.]]></description>
		<content:encoded><![CDATA[<p>Tony, yes, backward compatibility is a multi-edged sword. Many of the current mashup APIs are not versioned (not even their URLs) so it&#8217;ll be interesting to see how things evolve.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tony Confrey</title>
		<link>http://blog.simeonov.com/2008/06/06/forced-upgrades/#comment-17338</link>
		<dc:creator><![CDATA[Tony Confrey]]></dc:creator>
		<pubDate>Wed, 18 Jun 2008 19:39:34 +0000</pubDate>
		<guid isPermaLink="false">http://simeons.wordpress.com/?p=274#comment-17338</guid>
		<description><![CDATA[As someone who has hopped on a plane with a bunch of mag tapes to do on-site upgrades I can appreciate the value of the on-line upgrade model! Many have pointed out (for example Paul Graham: http://www.paulgraham.com/road.html) that web apps break the old mold of upgrades as a large and distinct activity.

The downside comes when there&#039;s coupling amongst applications, as there is increasingly with mashups and aggregations of web services. When an interface on which I depend changes then I&#039;m potentially screwed. I take the point that systems built on platform- and infrastructure-as-a-service offerings have this coupling problem in the extreme. 

The solution is to keep systems as loosely coupled as possible and to provide backward compatibility of interfaces. I think as an ecosystem forms on top of a given platform it will be essential for platform provider to support some kind of backward compatibility. Your Vista example can be extended. Microsoft has always taken great pains to maintain backward compatibility (albeit at the expense of simplicity, performance and other important factors).

There are lots of ongoing battles to see where we will collectively define platform layers in our software stacks. History has shown that platform providers who foster the largest community of ISVs tend to win out. Stranding masses of developers on a no-longer-supported set of interfaces is not a good way to go about building that community. So over time I think you&#039;ll see fewer &#039;forced upgrades&#039;. 

It&#039;ll be interesting to see how it all evolves...

(BTW the MHT link seems to be broken)]]></description>
		<content:encoded><![CDATA[<p>As someone who has hopped on a plane with a bunch of mag tapes to do on-site upgrades I can appreciate the value of the on-line upgrade model! Many have pointed out (for example Paul Graham: <a href="http://www.paulgraham.com/road.html" rel="nofollow">http://www.paulgraham.com/road.html</a>) that web apps break the old mold of upgrades as a large and distinct activity.</p>
<p>The downside comes when there&#8217;s coupling amongst applications, as there is increasingly with mashups and aggregations of web services. When an interface on which I depend changes then I&#8217;m potentially screwed. I take the point that systems built on platform- and infrastructure-as-a-service offerings have this coupling problem in the extreme. </p>
<p>The solution is to keep systems as loosely coupled as possible and to provide backward compatibility of interfaces. I think as an ecosystem forms on top of a given platform it will be essential for platform provider to support some kind of backward compatibility. Your Vista example can be extended. Microsoft has always taken great pains to maintain backward compatibility (albeit at the expense of simplicity, performance and other important factors).</p>
<p>There are lots of ongoing battles to see where we will collectively define platform layers in our software stacks. History has shown that platform providers who foster the largest community of ISVs tend to win out. Stranding masses of developers on a no-longer-supported set of interfaces is not a good way to go about building that community. So over time I think you&#8217;ll see fewer &#8216;forced upgrades&#8217;. </p>
<p>It&#8217;ll be interesting to see how it all evolves&#8230;</p>
<p>(BTW the MHT link seems to be broken)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

