<?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 for William Vambenepe&#039;s blog</title>
	<atom:link href="http://stage.vambenepe.com/comments/feed" rel="self" type="application/rss+xml" />
	<link>http://stage.vambenepe.com</link>
	<description>IT management in a changing IT world</description>
	<lastBuildDate>Mon, 26 Jul 2010 20:24:03 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on The Tragedy of the Commons in Cloud standards by Mike Leach</title>
		<link>http://stage.vambenepe.com/archives/1549#comment-109286</link>
		<dc:creator>Mike Leach</dc:creator>
		<pubDate>Mon, 26 Jul 2010 20:24:03 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1549#comment-109286</guid>
		<description>If there is the potential for a &quot;tragedy of the commons&quot; in the cloud, it would be that large cloud companies are building on open source (taking) and technically are not violating the GPL when not giving back their enhancements because &quot;redistribution&quot; doesn&#039;t extend to a server hosting context.

Fortunately, Google and other companies have built sufficient goodwill by giving back to the open source community in many different ways, so few developers want to force the issue (Most OS project leads are even hired to work at these companies). But still, many forks are being held close to the chest.

http://www.infoworld.com/t/applications/gpl-author-google-must-share-code-288</description>
		<content:encoded><![CDATA[<p>If there is the potential for a &#8220;tragedy of the commons&#8221; in the cloud, it would be that large cloud companies are building on open source (taking) and technically are not violating the GPL when not giving back their enhancements because &#8220;redistribution&#8221; doesn&#8217;t extend to a server hosting context.</p>
<p>Fortunately, Google and other companies have built sufficient goodwill by giving back to the open source community in many different ways, so few developers want to force the issue (Most OS project leads are even hired to work at these companies). But still, many forks are being held close to the chest.</p>
<p><a href="http://www.infoworld.com/t/applications/gpl-author-google-must-share-code-288" rel="nofollow">http://www.infoworld.com/t/applications/gpl-author-google-must-share-code-288</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Tragedy of the Commons in Cloud standards by Neill Turner</title>
		<link>http://stage.vambenepe.com/archives/1549#comment-109275</link>
		<dc:creator>Neill Turner</dc:creator>
		<pubDate>Mon, 26 Jul 2010 13:47:41 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1549#comment-109275</guid>
		<description>Well I don&#039;t really care about these low-level Cloud Standards. They will just become commodities. In fact the faster we can commoditize the Infrastructure as as Service (IaaS) layer the better. The real standards benefit will be in the Platform as a Service (PaaS) layer that will be built on top of the IaaS layer.
 -Think SQL database services that auto scale etc etc all you do is drop in your SQL.
 -Programming services where similarly you just drop in your code and it all runs. 
 -lots more.   
 These services will appear once the IaaS layer is commoditized and will have alot of business benefit. Currently there is too much variety in the IaaS clouds to build these. I expect a lot of effort going on in the IaaS layer will just go up the river when commoditization happens. I think Amazon understand this. They just create commodities as cheap, reliable, secure and scalable as possible. Everything else is irrelevant for Infrastructure as a Service.</description>
		<content:encoded><![CDATA[<p>Well I don&#8217;t really care about these low-level Cloud Standards. They will just become commodities. In fact the faster we can commoditize the Infrastructure as as Service (IaaS) layer the better. The real standards benefit will be in the Platform as a Service (PaaS) layer that will be built on top of the IaaS layer.<br />
 -Think SQL database services that auto scale etc etc all you do is drop in your SQL.<br />
 -Programming services where similarly you just drop in your code and it all runs.<br />
 -lots more.<br />
 These services will appear once the IaaS layer is commoditized and will have alot of business benefit. Currently there is too much variety in the IaaS clouds to build these. I expect a lot of effort going on in the IaaS layer will just go up the river when commoditization happens. I think Amazon understand this. They just create commodities as cheap, reliable, secure and scalable as possible. Everything else is irrelevant for Infrastructure as a Service.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Tragedy of the Commons in Cloud standards by William (@vambenepe on Twitter)</title>
		<link>http://stage.vambenepe.com/archives/1549#comment-109267</link>
		<dc:creator>William (@vambenepe on Twitter)</dc:creator>
		<pubDate>Mon, 26 Jul 2010 07:22:02 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1549#comment-109267</guid>
		<description>Andrew, I think there is a good argument to be made that this is indeed a &quot;prisoner&#039;s dilemma&quot; type of situation if we assume that preventing premature standardization increases the size of the &quot;Cloud market&quot; pie, which I can easily believe.

The &quot;duel&quot; suggestion makes me realize that it may be for the better that we failed to find a mutually convenient time and place to meet when you were in town a week ago...</description>
		<content:encoded><![CDATA[<p>Andrew, I think there is a good argument to be made that this is indeed a &#8220;prisoner&#8217;s dilemma&#8221; type of situation if we assume that preventing premature standardization increases the size of the &#8220;Cloud market&#8221; pie, which I can easily believe.</p>
<p>The &#8220;duel&#8221; suggestion makes me realize that it may be for the better that we failed to find a mutually convenient time and place to meet when you were in town a week ago&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Tragedy of the Commons in Cloud standards by Andrew Clay Shafer</title>
		<link>http://stage.vambenepe.com/archives/1549#comment-109266</link>
		<dc:creator>Andrew Clay Shafer</dc:creator>
		<pubDate>Mon, 26 Jul 2010 06:30:43 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1549#comment-109266</guid>
		<description>I thought about this more, and I don&#039;t want to belabor the point too much, but I still think the standards situation is more appropriately labeled an nxn prisoners dilemma.

My rationale is that a &#039;tragedy of the commons&#039; is typified by the depletion of a shared common resource while the &#039;prisoners dilemma&#039; is typified by the choices made changing the dynamics and consequences of the choices of others.

Your standards for choosing metaphors is clearly flawed.

I&#039;m suggest we settle this the gentlemanly way all standards debates should be... a duel with pistols.</description>
		<content:encoded><![CDATA[<p>I thought about this more, and I don&#8217;t want to belabor the point too much, but I still think the standards situation is more appropriately labeled an nxn prisoners dilemma.</p>
<p>My rationale is that a &#8216;tragedy of the commons&#8217; is typified by the depletion of a shared common resource while the &#8216;prisoners dilemma&#8217; is typified by the choices made changing the dynamics and consequences of the choices of others.</p>
<p>Your standards for choosing metaphors is clearly flawed.</p>
<p>I&#8217;m suggest we settle this the gentlemanly way all standards debates should be&#8230; a duel with pistols.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Standards Disconnect at Cloud Connect by William Vambenepe &#8212; The Tragedy of the Commons in Cloud standards</title>
		<link>http://stage.vambenepe.com/archives/1344#comment-109265</link>
		<dc:creator>William Vambenepe &#8212; The Tragedy of the Commons in Cloud standards</dc:creator>
		<pubDate>Mon, 26 Jul 2010 06:04:32 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1344#comment-109265</guid>
		<description>[...] More generally, my main point here has nothing to do with Benjamin, Sam and their OSCON debate, other than the fact that reading about it prompted me to type this blog entry. It&#039;s simply that there is a perversion in the IT standards landscape that makes it impossible for premature standardization *not* to happen. It&#039;s something I&#039;ve written before, e.g. in this post: [...]</description>
		<content:encoded><![CDATA[<p>[...] More generally, my main point here has nothing to do with Benjamin, Sam and their OSCON debate, other than the fact that reading about it prompted me to type this blog entry. It&#39;s simply that there is a perversion in the IT standards landscape that makes it impossible for premature standardization *not* to happen. It&#39;s something I&#39;ve written before, e.g. in this post: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Tragedy of the Commons in Cloud standards by Jayadeep Purushothaman</title>
		<link>http://stage.vambenepe.com/archives/1549#comment-109261</link>
		<dc:creator>Jayadeep Purushothaman</dc:creator>
		<pubDate>Mon, 26 Jul 2010 03:38:15 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1549#comment-109261</guid>
		<description>If you look at the Unix standardization efforts where every unix vendor was involved, the ultimate winner was Microsoft! And finally a de-facto standard evolved in the form of Linux! So I am not so sure about your thoughts here.</description>
		<content:encoded><![CDATA[<p>If you look at the Unix standardization efforts where every unix vendor was involved, the ultimate winner was Microsoft! And finally a de-facto standard evolved in the form of Linux! So I am not so sure about your thoughts here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Tragedy of the Commons in Cloud standards by Mike Leach</title>
		<link>http://stage.vambenepe.com/archives/1549#comment-109260</link>
		<dc:creator>Mike Leach</dc:creator>
		<pubDate>Mon, 26 Jul 2010 02:49:07 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1549#comment-109260</guid>
		<description>If we use Nicholas Carr&#039;s metaphor that the cloud will evolve like electric utilities, then we only need the 120V at 60Hz equivalent as a standard.

I would argue we already have that with TCP/IP running on x86. Anything else built on top of that is fair game in the cloud.</description>
		<content:encoded><![CDATA[<p>If we use Nicholas Carr&#8217;s metaphor that the cloud will evolve like electric utilities, then we only need the 120V at 60Hz equivalent as a standard.</p>
<p>I would argue we already have that with TCP/IP running on x86. Anything else built on top of that is fair game in the cloud.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Introducing the Oracle Cloud API by Tom Maguire</title>
		<link>http://stage.vambenepe.com/archives/1538#comment-109010</link>
		<dc:creator>Tom Maguire</dc:creator>
		<pubDate>Tue, 20 Jul 2010 15:10:41 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1538#comment-109010</guid>
		<description>partial update of a resource using PUT.... bad, bad, bad...

HTTP PUT the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. 

interpreting absence of attributes as non-update or perhaps removal.... bad, bad, bad</description>
		<content:encoded><![CDATA[<p>partial update of a resource using PUT&#8230;. bad, bad, bad&#8230;</p>
<p>HTTP PUT the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. </p>
<p>interpreting absence of attributes as non-update or perhaps removal&#8230;. bad, bad, bad</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Introducing the Oracle Cloud API by William (@vambenepe on Twitter)</title>
		<link>http://stage.vambenepe.com/archives/1538#comment-108962</link>
		<dc:creator>William (@vambenepe on Twitter)</dc:creator>
		<pubDate>Mon, 19 Jul 2010 08:30:07 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1538#comment-108962</guid>
		<description>Fixed. And thanks again for the great work Craig.</description>
		<content:encoded><![CDATA[<p>Fixed. And thanks again for the great work Craig.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on REST in practice for IT and Cloud management (part 1: Cloud APIs) by William Vambenepe &#8212; Introducing the Oracle Cloud API</title>
		<link>http://stage.vambenepe.com/archives/863#comment-108961</link>
		<dc:creator>William Vambenepe &#8212; Introducing the Oracle Cloud API</dc:creator>
		<pubDate>Mon, 19 Jul 2010 08:29:31 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=863#comment-108961</guid>
		<description>[...] from the get go in the slides and is, in my mind, a selling point for the specification. When I reviewed the main Cloud APIs available last summer (the first part in a &#8220;REST in practice for IT and Cloud [...]</description>
		<content:encoded><![CDATA[<p>[...] from the get go in the slides and is, in my mind, a selling point for the specification. When I reviewed the main Cloud APIs available last summer (the first part in a &#8220;REST in practice for IT and Cloud [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Introducing the Oracle Cloud API by Craig McClanahan</title>
		<link>http://stage.vambenepe.com/archives/1538#comment-108958</link>
		<dc:creator>Craig McClanahan</dc:creator>
		<pubDate>Mon, 19 Jul 2010 07:13:46 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1538#comment-108958</guid>
		<description>It&#039;s great to see the cloud computing technology concepts we slaved over in my last year at Sun live on, and grow with what looks like some very useful improvements.  But it would be even greater to see my name spelled correctly (not your fault ... Tim got it wrong in the comment you quoted :-).

Craig McClanahan</description>
		<content:encoded><![CDATA[<p>It&#8217;s great to see the cloud computing technology concepts we slaved over in my last year at Sun live on, and grow with what looks like some very useful improvements.  But it would be even greater to see my name spelled correctly (not your fault &#8230; Tim got it wrong in the comment you quoted :-).</p>
<p>Craig McClanahan</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Standards Disconnect at Cloud Connect by William Vambenepe &#8212; Introducing the Oracle Cloud API</title>
		<link>http://stage.vambenepe.com/archives/1344#comment-108955</link>
		<dc:creator>William Vambenepe &#8212; Introducing the Oracle Cloud API</dc:creator>
		<pubDate>Mon, 19 Jul 2010 06:14:14 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1344#comment-108955</guid>
		<description>[...] So why two documents? Because they serve different purposes. The Elemental Resource Model, submitted to DMTF, represents the technical foundation for the IaaS layer. It&#8217;s not all of IaaS, just its core. You can think of its scope as that of the base EC2 service (boot a VM from an image, attach a volume, connect to a network). It&#8217;s the part that appears in all the various IaaS APIs out there, and that looks very similar, in its model, across all of them. It&#8217;s the part that&#8217;s ripe for a simple standard, hopefully free of much of the drama of a more open-ended and speculative effort. A standard that can come out quickly and provide interoperability right out of the gate (for the simple use cases it supports), not after years of plugfests and profiles. This is the narrow scope I described in an earlier rant about Cloud standards: [...]</description>
		<content:encoded><![CDATA[<p>[...] So why two documents? Because they serve different purposes. The Elemental Resource Model, submitted to DMTF, represents the technical foundation for the IaaS layer. It&#8217;s not all of IaaS, just its core. You can think of its scope as that of the base EC2 service (boot a VM from an image, attach a volume, connect to a network). It&#8217;s the part that appears in all the various IaaS APIs out there, and that looks very similar, in its model, across all of them. It&#8217;s the part that&#8217;s ripe for a simple standard, hopefully free of much of the drama of a more open-ended and speculative effort. A standard that can come out quickly and provide interoperability right out of the gate (for the simple use cases it supports), not after years of plugfests and profiles. This is the narrow scope I described in an earlier rant about Cloud standards: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on CMDB in the Cloud: not your father&#8217;s CMDB by Coté&#39;s People Over Process &#187; Pouring new wine on old problems &#8211; IT Management &#38; Cloud Podcast #75</title>
		<link>http://stage.vambenepe.com/archives/1527#comment-108458</link>
		<dc:creator>Coté&#39;s People Over Process &#187; Pouring new wine on old problems &#8211; IT Management &#38; Cloud Podcast #75</dc:creator>
		<pubDate>Fri, 02 Jul 2010 17:53:05 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1527#comment-108458</guid>
		<description>[...] to be or not to be &#8211; William V. has a nice round-up of the sentiment. What&#8217;s going on with CMDBs, asset databases, discovery, topology mappings, [...]</description>
		<content:encoded><![CDATA[<p>[...] to be or not to be &#8211; William V. has a nice round-up of the sentiment. What&#8217;s going on with CMDBs, asset databases, discovery, topology mappings, [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on BPMN to BPEL: going to battle with one hand tied? by BPM &#124; BPMN and BPEL: there is no conflict &#124; VOSibilities</title>
		<link>http://stage.vambenepe.com/archives/177#comment-108121</link>
		<dc:creator>BPM &#124; BPMN and BPEL: there is no conflict &#124; VOSibilities</dc:creator>
		<pubDate>Mon, 21 Jun 2010 12:49:01 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/archives/177#comment-108121</guid>
		<description>[...] that Tom Baeyens’ linked to when he claimed that that “the translation step from BPMN to BPEL is very problematic to say the [...]</description>
		<content:encoded><![CDATA[<p>[...] that Tom Baeyens’ linked to when he claimed that that “the translation step from BPMN to BPEL is very problematic to say the [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The battle of the Cloud Frameworks: Application Servers redux? by Alison Kay</title>
		<link>http://stage.vambenepe.com/archives/1407#comment-108035</link>
		<dc:creator>Alison Kay</dc:creator>
		<pubDate>Thu, 17 Jun 2010 19:07:45 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1407#comment-108035</guid>
		<description>Interesting article! I am curious to see where cloud computing will be a few years from now. It&#039;s quite amazing when you look back only a year or two as compared to now, how many more people have become aware of the cloud. Thanks for sharing this!</description>
		<content:encoded><![CDATA[<p>Interesting article! I am curious to see where cloud computing will be a few years from now. It&#8217;s quite amazing when you look back only a year or two as compared to now, how many more people have become aware of the cloud. Thanks for sharing this!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.230 seconds -->
