<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/atom10full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:thr="http://purl.org/syndication/thread/1.0" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0">
    <title>Inopia</title>
    
    
    <link rel="alternate" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/" />
    <id>tag:typepad.com,2003:weblog-1706008</id>
    <updated>2011-07-02T03:13:00+02:00</updated>
    <subtitle>Thoughts on the future of the Web</subtitle>
    <generator uri="http://www.typepad.com/">TypePad</generator>
    <atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/atom+xml" href="http://feeds.feedburner.com/typepad/1217752903s700/inopia_in_web_space" /><feedburner:info uri="typepad/1217752903s700/inopia_in_web_space" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://hubbub.api.typepad.com/" /><entry>
        <title>My Data, Your Service - The thin red line of User Data Access APIs (LinkedIn shuts out BranchOut and Others)</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/Puxxs5cCyxo/my-data-your-service-the-thin-red-line-of-data-access-apis.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2011/07/my-data-your-service-the-thin-red-line-of-data-access-apis.html" thr:count="2" thr:updated="2011-07-05T10:41:19+02:00" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea883401538f94af45970b</id>
        <published>2011-07-02T03:13:00+02:00</published>
        <updated>2011-07-02T03:25:00+02:00</updated>
        <summary>Today's news that Linked in has shut off API access to Branch Out, BeKnown, Visible.Me and a number of others once again illustrates the tension between openning data and controlling monetization (in a similar way to Twitter's service changes recently)....</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="APIs" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Data Portability" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Interoperability" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Mashups" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Web 3.0" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Web Services" />
        
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><p><a href="http://webspace.typepad.com/.a/6a00e553e776ea8834014e89880738970d-pi" style="float: right;"><img alt="IStock_000012386748XSmall" class="asset  asset-image at-xid-6a00e553e776ea8834014e89880738970d" src="http://webspace.typepad.com/.a/6a00e553e776ea8834014e89880738970d-320wi" style="margin: 0px 0px 5px 5px;" title="IStock_000012386748XSmall" /></a> <br />Today's news that Linked in has shut off <a href="http://techcrunch.com/2011/07/01/linkedin-cuts-off-api-access-to-branchout-monsters-beknown-and-others-for-tos-violations/" target="_self">API access</a> to Branch Out, BeKnown, Visible.Me and a number of others once again illustrates the tension between openning data and controlling monetization (in a similar way to <a href="http://webspace.typepad.com/inopia_in_web_space/2011/03/twitter-client-restrictions-bad-for-everybody-including-twitter-.html" target="_self">Twitter's service changes recently</a>). LinkedIn's reason for shutting down the access is primarily that these companies may be planning premium services which draw on LinkedIn's data (and potentially be a threat to LinkedIn's own monetisation plans).</p>
<p> </p>
<p>It would be easy to say that this is a mistake on LinkedIn's part (because of the chilling effect it will almost certainly have on usage of the API) or that it's a no-brainer since other companies are getting (free) access to LinkedIn's prized asset. However, there is another factor to take into account which is neatly put in BranchOut's response to LinkedIn:</p>
<blockquote>
<p><em>"we believe user data should be owned by the user, and that people should be allowed to share their data with the new services and contexts that provide the most utility."</em></p>
</blockquote>
<p>While this may appear a little self serving, LinkedIn profiles <strong>are</strong> curated by the owners - LinkedIn is effectively the channel for these profiles to reach an audience. Although LinkedIn's terms of service may have all manner of restrictions within them and LinkedIn adds a large amount of value this still raises the question - is LinkedIn an effective channel for distribution of my profile information if it chooses to exclude a broad range of uses of it's API?</p>
<p>In other words, as a LinkedIn user one of my greatest utilities is that I can point people to my profile, have them find me and connect to keep in touch. This is not disimilar to Tweets on Twitter - the fact that Twitter pushes tweets to others by many channels is one of it's major value adds. Shuting off API access actually reduces that value and might make me seek alternatives. </p>
<p>So how can this circle be squared? </p>
<p>I'd argue that rather than shutting off access, LinkedIn should instead;</p>
<ul>
<li>Put a <strong>price</strong> on this access above a certain volume.</li>
<li>Potentially even as a <strong>%age of revenue</strong> that value added services earn.</li>
<li>Set rules such as "no caching" beyond a strict time limit to ensure data cannot be entirely replicated.</li>
<li>See these services as a value add that will actually drive <strong>more users</strong> to add profiles to LinkedIn because distribution is wider.</li>
<li>Set clear rules of engagement and not change them over time.</li>
</ul>
<p>Might some of the services conflict with LinkedIn's own plans? Possibly, but as long as the price is right, this may even be a net gain. </p>
<p>Facebook seems to be ahead of both LinkedIn and Twitter in this respect - it's <a href="http://techcrunch.com/2011/07/01/zynga-and-facebook-pray-they-dont-alter-the-deal-any-further/" target="_self">30/70% revenue split with Zynga</a> and other games already ensures that there is always cashback for innovation that draws on it's platform.</p>
<p>BranchOut's statement that the loss of API Access is not a big deal ring a little hollow, however LinkedIn's actions certainly mean that people may begin to seek other places to host their professional profiles that allow more distribution.</p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2011/07/my-data-your-service-the-thin-red-line-of-data-access-apis.html</feedburner:origLink></entry>
    <entry>
        <title>Twitter client restrictions - bad for everybody (including Twitter) </title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/iEfXkDrpq9Q/twitter-client-restrictions-bad-for-everybody-including-twitter-.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2011/03/twitter-client-restrictions-bad-for-everybody-including-twitter-.html" thr:count="0" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea88340147e32b8431970b</id>
        <published>2011-03-12T16:36:11+01:00</published>
        <updated>2011-03-12T16:36:46+01:00</updated>
        <summary>It's a shame to see Twitter putting restrictions on client development via their API (more on GigaOm here). Obviously there's speculation as to what the business reasons might be - and the effect on the ecosystem - the move seems...</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="APIs" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Interoperability" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Web 3.0" />
        
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><p>It's a shame to see Twitter putting restrictions on <a href="http://techcrunch.com/2011/03/11/twitter-ecosystem-guidelines/" target="_self">client development via their API</a> (more on GigaOm <a href="http://gigaom.com/2011/03/11/twitter-to-client-developers-well-take-it-from-here/" target="_self">here</a>). Obviously there's speculation as to what the business reasons might be - and the effect on the ecosystem - the move seems more than likely to be about controlling advertising real estate. The original post is <a href="https://groups.google.com/forum/?hl=en_US&amp;pli=1#!topic/twitter-api-announce/yCzVnHqHIWo" target="_self">here</a>. </p>
<p>The post makes some valid points about privacy and no doubt Twitters transition to the consumer mainstream has promted some of this, but it still seems to be unfortunate step.</p>
<p>Quote from Ryan Carver (via <a href="http://techcrunch.com/2011/03/11/twitter-ecosystem-guidelines/" target="_self">techcrunch</a>): </p>
<blockquote>
<p>“<em>We need to move to a less fragmented world, where every user can experience Twitter in a consistent way.  This is already happening organically – the number and market share of consumer client apps that are not owned or operated by Twitter has been shrinking</em>,” he writes.</p>
</blockquote>
<p>While that might make some sense - mostly likely because it gives Twitter closer control over the Ad real estate associated with the last milimetre to the customer - the twitter client is (almost) the new browser. No doubt this is a major driver - Facebooks monetisation prospects w.r.t. Twitter are simply so much greater simply because most people experience Facebook on almost entirely Facebook controlled real estate. </p>
<p>Promoted tweets may be one way of advertising but they are annoying for users and interupt the application itself - whereas "out of band" ads on the side of a device attract less ire and can be omni-present. </p>
<p>The question is - does this make good business sense? and does it signal bad news for "open API" strategies?</p>
<p>The twitter team are smart and no doubt a lot of thought has gone into this change and the perceived economic benefits must have outweighed the risks/negatives (developer anger, loss of innovation and goodwill). However firstly it seems unlikely that this means bad news for the open strategy (that's what got twitter here in the first place and this restricts one dimension of the APIs usage), further for a couple of reasons I think it's a bad move for twitter itself: </p>
<ul>
<li>The loss of developer trust and confidence is not to be underestimated - and although this would seem not to affect "niche" clients for specialist devices/environments (which Twitter will never likely cover), people will be much less free with their innovation.</li>
<li>The move defacto forces existing twitter clients to integrate other services in addition to twitter - when many might have been content to stay twitter only. </li>
<li>Twitter is betting on it's clients being one of the "goto" apps on any device going forward (alongside facebook, the email client, google search etc.) but this is by no means a given - particularly if the number of twitter client options drops. Over time there is a significant risk the facebook and others squeeze twitter into the background (particularly if they offer a channel to twitter).  </li>
</ul>
<p>There seems to me to be no good reason why Twitter could not have continued to innovate heavily on it's own clients while giving everybody else free reign - if they were better, they'd get more audience. In fact it's precisely the biggest reach clients like TweetDeck which Twitter hasn't restricted. </p>
<p>So given there is money to be made from ads and the last milimeter to the user, what should Twitter do other than what it has? In my view the right strategy would be to permit and even encourage client innovation but to add revenue share restrictions and requirements on openning up ad real-estate where possible. E.g. </p>
<ol>
<li>Allow development of twitter clients and use of the API.</li>
<li>Provide additional APIs for advertising feeds (potentially provided by 3rd party ad networks).</li>
<li>Require clients seeing any kind of volume to either carry ad inventory or pay pay volume fees. </li>
</ol>
<p>This is obviously harder to enforce than a blanket "ban", however Twitter's current approach is likely to lead to a "smaller" pie with more for twitter rather than a "larger pie" with more creativity in terms of business models. </p>
<p>Hopefully in time the decision will get reversed and API innovation will flow once more!</p>
<p> </p>
<p> </p></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2011/03/twitter-client-restrictions-bad-for-everybody-including-twitter-.html</feedburner:origLink></entry>
    <entry>
        <title>What is an API? Your guide to the Internet Business (R)evolution</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/qaNJQRSBCwo/what-is-an-api-your-guide-to-the-internet-business-revolution.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2011/03/what-is-an-api-your-guide-to-the-internet-business-revolution.html" thr:count="0" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea8834014e86ab5722970d</id>
        <published>2011-03-12T15:49:25+01:00</published>
        <updated>2011-03-12T15:49:25+01:00</updated>
        <summary>There's a new whitepaper up on the 3scale website - What is an API? Your guide to the Internet Business (R)evolution - definitely worth checking out. It's always tough to find the right metaphors to explain the value of APIs,...</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="APIs" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Interoperability" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Mashups" />
        
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><p>There's a new whitepaper up on the 3scale website - <a href="http://www.3scale.net/2011/03/11/what-is-an-api-your-guide-to-the-internet-business-revolution/" target="_self" title="What is an API?">What is an API? Your guide to the Internet Business (R)evolution</a> - definitely worth checking out. It's always tough to find the right metaphors to explain the value of APIs, so we've given it a shot. </p>
<p>Dion Hinchcliffe summarizes it best:</p>
<blockquote>
<p>“We are nearing the time when opening our supply chains across the Web isn’t just a good idea, it will be essential for competitive survival"</p>
</blockquote>
<p>A nice timely reminder since just a couple of days ago programmableweb crossed <a href="http://bit.ly/gSfCbb" target="_self">3000 APIs</a> in their directory - impressive and more to come no doubt!</p></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2011/03/what-is-an-api-your-guide-to-the-internet-business-revolution.html</feedburner:origLink></entry>
    <entry>
        <title>Services, Apps and the API Powered Web</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/hg9pg7JHNG0/services-apps-and-the-api-powered-web.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2010/11/services-apps-and-the-api-powered-web.html" thr:count="0" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea88340147e038fa86970b</id>
        <published>2010-11-29T01:18:43+01:00</published>
        <updated>2010-11-29T01:18:43+01:00</updated>
        <summary>Last week I had the opportunity to do a series of talks on fun subjects for the open informatics program at CTU in Prague. It was a good opportunity to reflect on some of the trends different people in the...</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><p>Last week I had the opportunity to do a series of talks on fun subjects for the open informatics program at CTU in Prague. It was a good opportunity to reflect on some of the trends different people in the API, Web Services, Apps world are picking up, so for one of the talks I tried to pull together some thoughts on APIs, Apps and the Web (embedded below).</p>
<p>There are some great presentation on this subject already out there (check out Sam Ramji's <a href="http://www.slideshare.net/samramji/darwins-finches-20th-century-business-and-apis" target="_self">Darwin's Finches</a> for example), but as more APIs emerge it's also becoming clearer just how fast this innovation is happening. </p>
<p>I've also included some of the API business model material we use with our customers are 3scale - hopefully that provides an insight on what people are doing with APIs.</p>
<div id="__ss_5938127" style="width: 425px; text-align: left; padding-left: 60px;"><strong style="display: block; margin: 12px 0 4px;"><a href="http://www.slideshare.net/stevenwillmott/services-apps-and-the-api-powered-web" title="Services, Apps and the API Powered Web">Services, Apps and the API Powered Web</a></strong>
<object height="355" id="__sse5938127" width="425">
<param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=service-apps-and-the-api-powered-web-101127161929-phpapp02&amp;stripped_title=services-apps-and-the-api-powered-web&amp;userName=stevenwillmott" />
<param name="allowFullScreen" value="true" />
<param name="allowScriptAccess" value="always" /><embed allowfullscreen="true" allowscriptaccess="always" height="355" name="__sse5938127" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=service-apps-and-the-api-powered-web-101127161929-phpapp02&amp;stripped_title=services-apps-and-the-api-powered-web&amp;userName=stevenwillmott" type="application/x-shockwave-flash" width="425" />
</object>
</div>
<div style="padding-top: 5px; padding-right: 0px; padding-bottom: 12px; text-align: left; padding-left: 60px;" />
<div style="padding-top: 5px; padding-right: 0px; padding-bottom: 12px; padding-left: 0px; text-align: left;">Many thanks again to the team at CTU for the invitation and the chance to spend some time deep diving into these topics!</div>
<div style="padding-top: 5px; padding-right: 0px; padding-bottom: 12px; padding-left: 0px; text-align: center;" />
<div style="padding-top: 5px; padding-right: 0px; padding-bottom: 12px; padding-left: 0px; text-align: center;" />
<div style="padding-top: 5px; padding-right: 0px; padding-bottom: 12px; padding-left: 0px; text-align: center;" />
<div style="padding-top: 5px; padding-right: 0px; padding-bottom: 12px; padding-left: 0px; text-align: center;" />
<div style="padding-top: 5px; padding-right: 0px; padding-bottom: 12px; padding-left: 0px; text-align: center;" />
<div style="padding-top: 5px; padding-right: 0px; padding-bottom: 12px; padding-left: 0px; text-align: center;" />
<div style="padding: 5px 0 12px;" />
<div style="padding: 5px 0 12px;" />
<script src="http://b.scorecardresearch.com/beacon.js?c1=7&amp;c2=7400849&amp;c3=1&amp;c4=&amp;c5=&amp;c6=" />
<script src="http://b.scorecardresearch.com/beacon.js?c1=7&amp;c2=7400849&amp;c3=1&amp;c4=&amp;c5=&amp;c6=" /></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2010/11/services-apps-and-the-api-powered-web.html</feedburner:origLink></entry>
    <entry>
        <title>API First, Mobile Second, Web Third</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/ubgRqAgONag/api-first-mobile-second-web-third.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2010/11/api-first-mobile-second-web-third.html" thr:count="0" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea88340147e033302a970b</id>
        <published>2010-11-27T23:56:00+01:00</published>
        <updated>2010-11-27T23:56:00+01:00</updated>
        <summary>Great post by Scott Switzer and wholeheartedly agree - an API is becoming genuinely essential to launching a online company - and for companies starting from scratch, the API should be first on the drawing board. </summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><blockquote>
<p>Fred Wilson wrote a post about how companies build their mobile presence first, and their web presence second, showing a shift in how people use the internet.</p>
<p>I would probably modify this idea, with the following:</p>
<p><em>API First, Mobile Second, Web Third</em></p>
<p>The most important consumer of your product in this age is not necessarily a person, but a machine.</p>
</blockquote>
<p><small>via <a href="http://www.switzer.org/post/1660159298/a-vc-mobile-first-web-second-continued">www.switzer.org</a></small></p>
<p>Great post by Scott Switzer and wholeheartedly agree - an API is becoming genuinely essential to launching a online company - and for companies starting from scratch, the API should be first on the drawing board. </p></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2010/11/api-first-mobile-second-web-third.html</feedburner:origLink></entry>
    <entry>
        <title>What Foursquare should do to compete with Facebook - "Go Public"</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/4dnL0-s0af0/what-foursquare-should-do-to-compete-with-facebook-go-public-1.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2010/08/what-foursquare-should-do-to-compete-with-facebook-go-public-1.html" thr:count="3" thr:updated="2010-09-01T14:23:21+02:00" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea88340133f32eb76f970b</id>
        <published>2010-08-29T00:39:06+02:00</published>
        <updated>2010-08-29T00:39:06+02:00</updated>
        <summary>I'm sure the foursquare team has their strategy well in hand after the announcement of Facebook places and maybe this is way off base anyway, but I was suprised to see little real press analysis on what paths they might...</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        <category scheme="http://www.sixapart.com/ns/types#category" term="Mashups" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Web 3.0" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Web Services" />
        <category scheme="http://www.sixapart.com/ns/types#category" term="Web/Tech" />
        
        <category scheme="http://sixapart.com/ns/types#tag" term="facebook" />
        <category scheme="http://sixapart.com/ns/types#tag" term="foursquare" />
        <category scheme="http://sixapart.com/ns/types#tag" term="places" />
        <category scheme="http://sixapart.com/ns/types#tag" term="twitter" />
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><p>I'm sure the foursquare team has their strategy well in hand after the announcement of Facebook places and maybe this is way off base anyway, but I was suprised to see little real press analysis on what paths they might take (instead is was mainly doom and gloom - (<a href="http://thenextweb.com/location/2010/08/19/why-i-deleted-foursquare-for-good/" style="color: blue !important; text-decoration: underline !important; cursor: text !important; ">TNW</a>, <a href="http://edition.cnn.com/2010/TECH/social.media/08/19/cashmore.facebook.places/index.html#fbid=Pzir1CdTnxm&amp;wom=false" style="color: blue !important; text-decoration: underline !important; cursor: text !important; ">CNN</a>)). But it seems to me there are clear paths and one of the them could be to yank the steering wheel to one side and "Go Public" (not in the IPO sense - in the social network model sense!). </p><p /><p>To explain this, one of the things that always struck me as the *key* difference between twitter and facebook is: twitter is public broadcast, facebook is group narrowcast. I.e. twitter has asymmetric relations, facebooks are symmetric.</p><p>So facebook (although there is a public mode) requires both parties to friend.</p><p>This makes twitter and facebook fundamentally different - and I think means that twitter can and will continue to grow very strongly. Because of the type of data shared on facebook it's simply difficult for them to push asymetric relationships.</p><p>On location I could see the same thing happening. The "normal" way of thinking about location is "I share with my friends" - symmetric relationships. This also makes sense for security in some sense.</p><p>So it seems to me that if foursquare is able to push it's asymetric relationships - i.e. anybody can follow anyone for location information:</p><p /><ul>
<li>it would make a big change to the service </li>
<li>but it would give it a much different utility to facebook.</li>
</ul>
<br />broadcasting location publically has the chance to create chance meetings, to interact with locations / brands in a way narrowcasting to friends doesn't. Also facebook is unlikely to open the privacy settings much (or make the defaults public) because it is already embroilled in various privacy issues.<p /><p>An example would be, people checking into a bar in Barcelona - they might post on facebook so their friends know, but they might also post on foursquare so "everybody" knows (basically this is equivalent to posting "I'm at Harry's Bar in Barcelona" on Twitter). Facebook places may allow you to do this also but the focus is different and theres a big risk of confusion between public and private settings. </p><p>Basically a foursquare which focused on a twitter like public broadcast of location could provide a much different platform to facebook places and become the basis of different types of location aware services. You may post there "less" but you'll post there when there is some real utility to doing so like meeting new people in a bar, collecting coupons &amp; points, getting timely information etc. </p><p /><p /><p /><p /><p /><p /><p /></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2010/08/what-foursquare-should-do-to-compete-with-facebook-go-public-1.html</feedburner:origLink></entry>
    <entry>
        <title>P ≠ NP-- Greg and Kat’s blog</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/rYtl4XVYgwk/p-np---greg-and-kats-blog.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2010/08/p-np---greg-and-kats-blog.html" thr:count="0" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea88340133f2ef138a970b</id>
        <published>2010-08-09T01:53:41+02:00</published>
        <updated>2010-08-09T01:53:41+02:00</updated>
        <summary>P ≠ NP August 7th, 2010, 8:21 pm UTC by Greg An email I was recently forwarded (a couple of steps removed) from Vinay Deolalikar from HP Labs: Dear Fellow Researchers, I am pleased to announce a proof that P...</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><blockquote><h2><a href="http://gregbaker.ca/blog/2010/08/07/p-n-np/" rel="bookmark" title="Permanent Link to P ≠ NP">P ≠ NP</a></h2>
			<div class="aboutpost">August 7th, 2010, 8:21 pm UTC by Greg</div>
			
			<div class="entry">
				<p>An email I was recently forwarded (a couple of steps removed) from <a href="http://www.hpl.hp.com/personal/Vinay_Deolalikar/">Vinay Deolalikar</a> from HP Labs:</p>
<blockquote><p>Dear Fellow Researchers,</p>
<p>I am pleased to announce a proof that P is not equal to NP, which is attached in 10pt and 12pt fonts.</p>
<p>The proof required the piecing together of principles from multiple areas within mathematics.  The major effort in constructing this proof was uncovering a chain of conceptual links between various fields and viewing them through a common lens.  Second to this were the technical hurdles faced at each stage in the proof.</p>
<p>This work builds upon fundamental contributions many esteemed researchers have made to their fields. In the presentation of this paper, it was my intention to provide the reader with an understanding of the global framework for this proof.  Technical and computational details within chapters were minimized as much as possible.</p>
<p>This work was pursued independently of my duties as a HP Labs researcher, and without the knowledge of others. I made several unsuccessful attempts these past two years trying other combinations of ideas before I began this work.</p>
<p>Comments and suggestions for improvements to the paper are highly welcomed.</p></blockquote>
<p>The paper is about 100 pages, and looks serious (but being a decade away from last thinking about complexity, I am unable to give any more useful evaluation than that).  I’ll refrain from posting the paper itself.</p>
<p>Deciding <a href="http://en.wikipedia.org/wiki/P_versus_NP_problem">P ≠ NP</a> is a <a href="http://www.claymath.org/millennium/">Millennium Prize Problem</a> and I don’t think I’d get much argument to say it is the biggest open problem in computing science.</p>
<p>Update: I see someone else has uploaded <a href="http://www.scribd.com/doc/35539144/pnp12pt">the paper</a>. I should point out that in the email thread I got, <a href="http://en.wikipedia.org/wiki/Stephen_Cook">Stephen Cook</a> said “This appears to be a relatively serious claim to have solved P vs NP.</p></div></blockquote>

<p><small>via <a href="http://gregbaker.ca/blog/2010/08/07/p-n-np/">gregbaker.ca</a></small></p>

<p>Would be stunning if the proof is validated.  Although it wont radically alter out day to day as much as a P=NP result would have (Q mass panic since every encryption system out there would be breakable - and vast amounts of computational problems would become soluble!), it's still a big deal.</p>

<p>The synopsis of the proof sounds intuitive though I have no idea on many of the details. I like the idea of interconnectedness at great distance in the solution space causing the breakdown in linear algorithms. Seems like the right kind of idea that might also help people figure out if quantum computing can ever bridge this gap and how it might do so.</p></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2010/08/p-np---greg-and-kats-blog.html</feedburner:origLink></entry>
    <entry>
        <title>Why locking your content to one format or device is a bad idea (Even for Amazon)</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/ebMsNrsdxyQ/why-locking-your-content-to-one-format-or-device-is-a-bad-idea-even-for-amazon.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2010/07/why-locking-your-content-to-one-format-or-device-is-a-bad-idea-even-for-amazon.html" thr:count="0" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea88340133f285c15f970b</id>
        <published>2010-07-24T16:21:52+02:00</published>
        <updated>2010-07-24T16:23:45+02:00</updated>
        <summary>Wylie's agreement this week with with Amazon to allow Amazon exclusive rights to publish eBook versions of it's classics on the kindle (techcrunch) has a lot of publishers up in arms because of it's potential to fragment the eBook market. On the one hand it's arguably just another sign of the disruption electronic publishing is likely to wreak on the publishing industry but on the other it also seems like a spectacularly bad idea in the medium and long term</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        
        <category scheme="http://sixapart.com/ns/types#tag" term="Amazon" />
        <category scheme="http://sixapart.com/ns/types#tag" term="API" />
        <category scheme="http://sixapart.com/ns/types#tag" term="eBooks" />
        <category scheme="http://sixapart.com/ns/types#tag" term="publishing" />
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><p>Wylie's agreement this week with with Amazon to allow Amazon exclusive rights to publish eBook versions of it's classics on the kindle (<a href="http://www.crunchgear.com/2010/07/22/amazon-strikes-sweet-exclusive-deal-good-for-them-bad-for-consumers/">techcrunch</a>) has a lot of publishers up in arms because of it's potential to fragment the eBook market. On the one hand it's arguably just another sign of the disruption electronic publishing is likely to wreak on the publishing industry but on the other it also seems like a spectacularly bad idea in the medium and long term. Although it's not the fist such deal, the trend seems to be changing from one off's like <a href="http://www.crunchgear.com/2009/02/09/rumor-stephen-king-to-launch-kindle-exclusive-today/">Stephen King's UR</a> to larger catalogues.</p><p>It's also logical that super-star owners will seek to make deals directly with distributers as far up the value chain as possible.</p><p>The exclusivity deal itself though, firstly smacks somewhat of impotence in the face of Apple's iPad - trying to leverage exclusive content to defend the Kindle's market position. It signals that this market fragmentation is "the best option" now - which is a shame.</p><p>However before authors and publishers go down this route they should think about where the real clearing houses for electronic books may end up. and owners of Book stores about which audiences they can serve:</p><p>APIs now allow seamless and highly flexible delivery of content in raw form - a perfect opportunity to restructure how user receive content, how they consume it (a multitude of readers apps could now emerge) and how they pay - it should be irrelevant where you buy a book (the content and presentation) from - the experience should be the same. </p><p>Even worse if content is tied to a specific device you'll need many devices to read what you want to read and (worse) innovation in the reader device market will stall almost before it started, because the biggest platforms will be the only ones with noteworthy content.</p><p /><ul>
<li>This is bad for publishers since their patch to an audience is fragmented</li>
<li>This is bad for readers since they can't consume content in the form they want despite technology allowing that for the first time.</li>
<li>It is also bad for Amazon and Apple in the long run since they will fail to win all deals and they wont create a sufficient device ecosystem around their sales channel.</li>
</ul>
<p>Publishers would be well advised to stay away from single channel sales until those channels genuinely support access to the majority of the world reader audience. It seems to me that:</p><p /><ul>
<li>Amazon's best strategy would be to open it's eBook distribution store to as many platforms as possible (iPad is already covered) but Nook and others - to make it unattractive for anybody to do exclusive deals which exclude them.</li>
<li>Further, amazon doing exclusives now when they address few 3rd party readers risks killing an ecosystem which they later may need.</li>
<li>Apple's best strategy would be to do the same with iBooks - open to as many platforms as possible, to also make it unattractive to do exclusive deals with Amazon.</li>
</ul>
<p>In fact - how about this: an open DRM standard for eBooks which works across all reader devices which all eBook stores (let's root for <a href="http://en.wikipedia.org/wiki/EPUB">ePUB</a>) support and APIs for those stores. Apple would hate it (see iTunes / ACC), Amazon would in theory loose an advantage - but in practice very likely gain heavily from it (at the expense of API and not having to develop it's own hardware exclusively).</p><p>With the world heading for open ecosystems of content and the chance <a href="http://" /><a href="http://webspace.typepad.com/inopia_in_web_space/2010/07/applying-software-patterns-to-the-cloud-and-the-internet-operating-system.html">to decouple data, algorithms and viewing experiences</a> it would be a shame if publishers ended up locking book content into closed ecosystems. If Amazon precipitates this they could loose more than they gain by crippling the ecosystem.</p></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2010/07/why-locking-your-content-to-one-format-or-device-is-a-bad-idea-even-for-amazon.html</feedburner:origLink></entry>
    <entry>
        <title>Applying Software Patterns to the Cloud and the Internet Operating System</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/s_wx98qblG4/applying-software-patterns-to-the-cloud-and-the-internet-operating-system.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2010/07/applying-software-patterns-to-the-cloud-and-the-internet-operating-system.html" thr:count="0" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea88340134857ece2b970c</id>
        <published>2010-07-17T15:58:04+02:00</published>
        <updated>2010-07-17T15:57:51+02:00</updated>
        <summary>The MVC for the Cloud meme got me thinking about other principles that might apply to programming the Web as a whole. A lot of the principle's we routinely apply to web apps to great effect seem to have analogies...</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        
        <category scheme="http://sixapart.com/ns/types#tag" term="Cloud" />
        <category scheme="http://sixapart.com/ns/types#tag" term="DRY" />
        <category scheme="http://sixapart.com/ns/types#tag" term="Internet Operating System" />
        <category scheme="http://sixapart.com/ns/types#tag" term="MVC" />
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><p>The <a href="http://webspace.typepad.com/inopia_in_web_space/2010/07/mvc-for-the-cloud.html">MVC for the Cloud</a> meme got me thinking about other principles that might apply to programming the Web as a whole. A lot of the principle's we routinely apply to web apps to great effect seem to have analogies when taken beyond individual apps. While MVC seems a clear fit, here are some others:</p><p /><ul>
<li>DRY - Don't Repeat Yourself!</li>
<li>Dynamic Languages</li>
<li>Convention over Configuration</li>
<li>Data and Control Abstraction</li>
<li>Continuous Integration</li>
</ul>
<p>Taken together with MVC these also make a lot of sense applied to the cloud. On the first one, I think it's fair to say we're already getting there:</p><p /><ul>
<li><strong><a href="http://en.wikipedia.org/wiki/Don't_repeat_yourself">DRY</a> (or DIE)</strong>: the last 20 years have seen an amazing ecosystem of open source software become available and most programming frameworks have a truly awesome ecosystem of plugins and code available to make the core frameworks more powerful. Now this is starting to be replicated at the service level - there are very few reasons now to develop your own credit card processing, email sending, exchange rate checking etc. systems - these are all freely available via external services which can be integrated by API. The trend seems to be accelerating with even user authentication management (Facebook Connect), file storage (Amazon S3), and a large volume of external data sources (event databases, weather, finance etc.) all starting to become externally available. It's becoming the rule that before you code anything or gather anything it makes sense to say "Is there an API for that?".</li>
</ul>
This isn't an argument that there should be only ONE API for it - diversity is crucial, but one perhaps the may just be ONE unified common interface. For the next, if we look hard enough I'd say the Web is already the best example of a runtime computing system based on <strong>dynamic languages</strong>: <p /><p /><ul>
<li>There is no fixed type system: While <a href="http://www.w3.org/TR/soap/">SOAP</a> Web Services have taken hold within the enterprise, on the Internet REST is King and there are few formal specifications used for API Interfaces (<a href="http://www.w3.org/TR/wsdl">WSDL</a>, <a href="http://www.w3.org/Submission/wadl/">WADL</a> and others do see use - but it's still sparse) - although this will change over time and we encourage our customers at 3scale to provide good specs for their APIs, we're a long way from a formal type system since there are no shared object definitions which are commonly agreed. (Semantic Web efforts are helping change this is also - but I suspect they'll take a long time to break through).</li>
<li>Even if there were a fixed type system there would still be no notion of "compilation" in the cloud for applications which span multiple services because different services are operated by different companies and individuals and could change at any time.</li>
<li>End services can also be written in almost any web language from C++ or Ada to Django or Java - even if everything could be frozen and "compiled" there would be no way to do it in the traditional sense. </li>
</ul>
<p>"It's about the Interface Stupid" might apply well here because amazingly things still work - today's API providers are realizing the importance of taking care of their interfaces over time. In the long run, at 3scale we see this as evolving into a Contract First environment where we don't just see languages like WSDL &amp; WADL define what an interface does functionally, but what the precise commitments are from the provider to the users of their services (see some great work on this in the European Commission funded <a href="http://ist-contract.org/">IST-CONTRACT project</a> btw).</p><p>Seeing the Cloud as a big Operating System based on dynamic languages means the following two memes are all the more important, but are only just emerging:</p><p /><ul>
<li><a href="http://en.wikipedia.org/wiki/Convention_over_configuration"><strong>Convention over Configuration</strong></a>: Frameworks such as Ruby on Rails have a huge advantage over other web development frameworks by using the idea that if a set of "normal ways of doing things" was established then in many cases there would be no need to maintain complex configuration files everywhere (JSPs - we're looking at you..), what are often a few logical lines of code in a rails app required multiple lines in other configuration files in a JSP driven App. In the cloud it's fair to say this idea is slowly emerging - c.f. the adoption of Twitter's API structure by a range of other services. REST itself is also something which follows a Convention pattern with it's 7 core operations applied to RESTfull data objects. We're a still a long way from being able to integrate 3rd party services almost without checking the documentation. </li>
<li><strong>Data and Control Abstraction</strong>: within modern programming frameworks ORM (<a href="http://en.wikipedia.org/wiki/Object-relational_mapping">Object Relational Mappings</a>) provide a powerful layer of abstraction over database entries that allow developers to think in terms of objects rather than lower level structures. Again in the cloud REST helps us generate some of this abstraction - new <a href="http://nosql-database.org/">NoSql</a> database even make some mappings even clearer (check out this amazing app - <a href="http://www.quirkey.com/blog/2009/09/15/sammy-js-couchdb-and-the-new-web-architecture/">Jquery + CouchDB - look no middle layer</a>.). Web APIs are by their very nature an abstraction of data and functionality - without this layer we would be writing raw SQL queries into linkedIn's database rather than using their API. What hasn't yet emerged is a standard model for representing many of the objects which are being shared - again something progress of the Semantic Web may change.</li>
</ul>
<p /><p><a href="http://www.programmableweb.com/">Programmable Web</a> now lists nearly 5000 mashups of 2000+ Public APIs - this is a huge number of integrations - and is testament to the hardworking developers than made this happen (each one of those links took a lot of debugging) - conventions and abstractions can come fast enough to make this all easier. Those 5000 mashups also highlight something which relates to the last of the 5 memes I picked on - continuous integration:</p><p /><ul>
<li><strong><a href="http://www.extremeprogramming.org/rules/integrateoften.html">Continuous Integration</a></strong>: applying continuous integration to software development is a no brainer for almost any complex system - the technique relies on the creation of batteries of software tests for all aspects of the software application which can be executed in an automated fashion (often the tests are written even before the application code) and runs these tests on any new build of the system when it becomes available. This means that if new code breaks the development build there's immediate awareness of the problem and it can be fixed. Continuos Integration allows a dev team to keep track of how the code matches up to how it is supposed to behave at all time (we keep 3scale's <a href="https://hudson.dev.java.net/">Hudson</a> Installs pretty busy :-) ). In the cloud context, we're still only taking baby steps towards an equivalent of automated testing and continuous integration. Most tests are still before deployment only and after that we hand of to far less detailed monitoring systems - despite the fact that many apps depend on external services. Continuous Integration will likely eventually need to be really continuous and operate at runtime against live deployed systems - not just pre-deploy time.</li>
</ul>
<p /><p>All in all, we're likely to want to replicate all the power and flexibility we have available for building individual applications to Applications which depend on Multiple cloud services. The scope of the problem changes - but the metaphors still seem to be highly valid. </p><p>I especially like the dynamic languages and DRY analogies - it's great to see the heterogeneity of available Web APIs and amazing to see that stable applications still emerge - Web API interfaces provide a critical glue to make this work and it's interesting to see that they are emerging "bottom up", rather than via top down de jure standards. </p><p /></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2010/07/applying-software-patterns-to-the-cloud-and-the-internet-operating-system.html</feedburner:origLink></entry>
    <entry>
        <title>MVC for the Cloud</title>
        <link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/typepad/1217752903s700/inopia_in_web_space/~3/IXe33tM4I3c/mvc-for-the-cloud.html" />
        <link rel="replies" type="text/html" href="http://webspace.typepad.com/inopia_in_web_space/2010/07/mvc-for-the-cloud.html" thr:count="2" thr:updated="2010-07-10T21:25:44+02:00" />
        <id>tag:typepad.com,2003:post-6a00e553e776ea88340134855797d2970c</id>
        <published>2010-07-10T18:24:43+02:00</published>
        <updated>2010-07-10T18:29:18+02:00</updated>
        <summary>While planning for a talk at Cloud Expo Europe a few weeks ago I was thinking about appropriate metaphors for the way APIs are changing the web. Although the title was APIs as glue for the Cloud, I think the core metaphor behind it deserves some explanation: MVC for the Cloud.</summary>
        <author>
            <name>Steven Willmott</name>
        </author>
        
        <category scheme="http://sixapart.com/ns/types#tag" term="API" />
        <category scheme="http://sixapart.com/ns/types#tag" term="Cloud" />
        <category scheme="http://sixapart.com/ns/types#tag" term="Internet Operating System" />
        <category scheme="http://sixapart.com/ns/types#tag" term="Model View Controller" />
        <category scheme="http://sixapart.com/ns/types#tag" term="MVC" />
        
<content type="xhtml" xml:lang="en-US" xml:base="http://webspace.typepad.com/inopia_in_web_space/">
<div xmlns="http://www.w3.org/1999/xhtml"><p>While planning for a talk at <a href="http://cloudexpo-europe.com/" title="Cloud Expo Europe">Cloud Expo Europe</a> a few weeks ago I was thinking about appropriate metaphors for the way APIs are changing the web. Although the title was APIs as glue for the Cloud, I think the core metaphor behind it deserves some explanation: <a href="http://www.slideshare.net/3scale/apis-the-glue-of-cloud-computing" title="Model View Controller metaphor for APIs and the Web"><strong>MVC for the Cloud</strong></a>. I thought I'd add some notes here as to what this might mean.</p><p>MVC or <a href="http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller">Model View Controller</a> is an architectural pattern for software that seperates out three import things - Models (or Data), Views (visualisation of that data) and Controllers (operations on the data). Since it's invention at Xerox Parc in the late 70's, MVC has a had a huge impact on software engineering and nowhere more so that on Web Applications - there are MVC frameworks for almost every Web programming language and framework out there. </p><p /><p>
<a href="http://webspace.typepad.com/.a/6a00e553e776ea8834013485579747970c-pi"><img alt="MVC" border="0" class="asset asset-image at-xid-6a00e553e776ea8834013485579747970c " src="http://webspace.typepad.com/.a/6a00e553e776ea8834013485579747970c-320pi" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 0px; margin-left: auto; " title="MVC" /></a></p><p>What I'd call "1st generation" MVC was applied to desktop applications and gave great new flexibility at design and build time but separating these three elements out and allowing independent work on all three pieces. When the software shipped everything got baked together and the end user had no knowledge how the underlying system was stitched together.</p><p>Moving to Web Applications there is a "2nd generation" of MVC which takes this even further - M, V and C can even stay separate at deploy time for a web app - this means developers of SAAS apps can independently work on and update their data models, views and controllers without affecting the other components - again all without the user needing to know. We can even allow users to switch interfaces "views" according to their needs - and keep exactly the same underlying logic and data models. Advanced testing frameworks and continuous deployment make it increasingly feasible to decouple almost everything. </p><p /><h2>Cloudscale MVC</h2><p /><p>However, arguably we're seeing the birth of a "3rd generation" (or is that a <a href="http://techcrunch.com/2010/05/23/the-third-disruptive-wave-tcdisrupt/">third wave</a>?) of MVC which has the potential to have an every broader and deeper impact - <strong>Cloud (or Web) scale MVC</strong> - all enabled by APIs. To explain this: MVC models have to date been though of as applying to single software applications (desktop or web), but the metaphor extends much further. Namely:</p><p /><ul>
<li>Models (Data): can mean any data anywhere, held by any company.</li>
<li>Views (Interfaces): can mean any view onto some data or function - i.e. an iPhone app, a mashup with other data, produced by the owners of that data / function or by somebody else.</li>
<li>Controllers (Logic): can mean any piece of business logic applied to data, again by the owners of the data or by somebody else. </li>
</ul>
<p>The implications of this are enormous - instead of a world in which individual applications/services are silos which have M+V+C locked inside of them the MVC connections a can perfectly well exist between applications and between companies. Better stated a company with great data assets can enable access to this data to aggressively grow an ecosystem of partners who provide exiting views (often coupled to audiences) and transformations of this data. </p><p /><p /><font size="4"><span style="font-size: 15px; line-height: 18px; "><strong><font size="3"><span style="font-size: 13px; font-weight: normal; line-height: 15px;"><br /></span></font></strong></span></font><p>Looking at some examples:</p><p /><ul>
<li>Companies such as the <a href="http://www.nytimes.com/">New York times</a>, <a href="http://www.bloomberg.com/">Bloomberg</a> or <a href="http://weather.weatherbug.com/">Weatherbug</a> have great data - it's often real time, often broader, deeper and unique value over their competitors. </li>
<li>Companies such as <a href="http://animoto.com/">Animoto</a>, <a href="http://www.shazam.com/">Shazam</a> and <a href="http://twitter.com/">Twitter</a> provide amazing functionality which transforms data - Animoto turns images into video, Shazzam turns audio into metadata, Twitter organises a huge global conversation. </li>
<li>Companies such as <a href="http://ww.yahoo.com/" /><a href="http://">Yahoo!</a> and <a href="http://www.tweetdeck.com/">Tweetdeck</a> provide views on data and structure it in clever ways. Further in the case of Yahoo they bring it to a huge Audience. </li>
</ul>
<p>I'd also include <a href="http://www.apple.com/">Apple</a> in the later category - creating devices which end up in the hands of millions and aggregate/transform applications and content into convenient forms for apple users. Some companies (potentially the New York Times falls into this category) have assets in more than one place - in the NYT's case great data, but also a loyal audience which trusts its brand. </p><p>APIs are the key strategic asset which is needed to make this happen. Using APIs companies are now <em>no longer forced to provide all parts of the value chain of their service themselves</em> - in fact, it has <em>huge value</em> to partner with others and focus on one's core strength. Today companies can likely still be victorious in their market segment without partnering up - but as the Internet evolves it seems likely that: </p><p /><ul>
<li>The companies with the best data should partner with those who can reach the widest (relevant) audience and who can best transform / manipulate and integrate that data.</li>
<li>The companies with the best algorithms and processes should seek the best data partners.</li>
<li>The companies which provide smart interfaces - be they in software, hardware or in terms of audience should bring in the best data and functionality from wherever they can find it.</li>
</ul>
<p>Such changes might require changes in business models and strategy, but increasingly they look like a natural evolution of the Web economy. As Data and Services move to the cloud the opportunities for focus and re-use of core valuable assets is a potentially huge untapped benefit for many companies. </p><p /><h2>APIs and the Internet Operating System</h2><p /><p>APIs are the natural glue which can make Cloud scale MVC happen since they allow a complete decoupling of the different elements needed for meaningful applications. What's also interesting is that MVC generally doesn't exist without a fourth element - an MVC framework which provides the structure within which everything comes together. </p><p>At the software level, this 4th element is represented by frameworks such as <a href="http://rubyonrails.org/">Rails</a>, <a href="http://www.djangoproject.com/">Jango</a>, <a href="http://cakephp.org/">Cake</a>, <a href="http://www.springsource.org/">Spring's Java MVC framework </a>or any of the other many frameworks. At the cloud scale the equivalent seems to be something akin to the <a href="http://radar.oreilly.com/2010/03/state-of-internet-operating-system.html">Internet Operating System</a> postulated by TIm O'Reilly and others which argues that many core internet functions such as Search, Media Access, Location, Communication and others are morphing from standalone services into a commonly available infrastructure which others can rely on - again often through the use of APIs. </p><p>This metaphor seems spot on - common substrates such as twitter messaging and google search are clearly becoming the basis of many thousands of new applications. The idea extends further to services such as <a href="http://developers.facebook.com/docs/guides/web">Facebook connect</a> and <a href="http://apiwiki.twitter.com/Sign-in-with-Twitter">Twitter connect</a> which are quickly becoming a standard way to set up user authentication for new Web applications (just as <a href="https://www.paypal.com/">Paypal</a> has largely become for payments). (Of course in some cases there are concerns about how much power some of the players behind such services may ultimately have, but leaving this aside, they arguable provide the means for a whole new economy of applications.</p><p>The Internet Operating System seems to be clearly emerging and taking the analogy further - is beginning to make it possible to build compound applications which string together data and services from many places to create user experiences.</p><p /><h2>Back to MVC</h2><p /><p>Although there are ton of possible metaphors for the way the Web is evolving, the MVC metaphor seems to be a good fit for what is happening not only at the architectural level (and what might be happening "on top of" the Internet Operating System) but also at the business level. </p><p>It seems a fair bet that web companies over the next few years will need to establish what their core value and differentiator is (M, V or C?) and aggressively establish partnering channels to links themselves into strong partner ecosystems. This also creates opportunities for a wealth of new applications which combine data, functionality and views/audiences in new ways.</p><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /><p /></div>
</content>



    <feedburner:origLink>http://webspace.typepad.com/inopia_in_web_space/2010/07/mvc-for-the-cloud.html</feedburner:origLink></entry>
 
</feed><!-- ph=1 -->

