<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" 
      xmlns:thr="http://purl.org/syndication/thread/1.0">
  <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php" />
  <link rel="self" type="application/atom+xml" href="http://www.readwriteweb.com/atom.xml" />
  <id>tag:,2009:/1/tag:www.readwriteweb.com,2008://1.6169-</id>
  <updated>2009-10-30T14:11:39Z</updated>
  <title>Comments for So You&apos;re Launching a Platform: After Ubiquitous APIs - What&apos;s the Next Frontier?</title>
  
  <generator uri="http://www.sixapart.com/movabletype/">Movable Type 4.23-en</generator>
  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169</id>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.readwriteweb.com/cgi-bin/mt/mt-atom.cgi/weblog/blog_id=1/entry_id=6169" title="So You're Launching a Platform: After Ubiquitous APIs - What's the Next Frontier?" />
    <published>2008-04-23T18:34:21Z</published>
    <updated>2008-04-23T20:48:36Z</updated>
    <title>So You&apos;re Launching a Platform: After Ubiquitous APIs - What&apos;s the Next Frontier?</title>
    <summary>We&apos;re here at the Web 2.0 Expo in San Francisco and are getting inundated with press releases about new APIs and developer platforms, many from companies we&apos;ve never even heard of in the first place. How long ago was it that the forward-looking thinkers argued that APIs and platforms would soon be available everywhere? That...</summary>
    <author>
      <name>Marshall Kirkpatrick</name>
      <uri>http://www.readwriteweb.com</uri>
    </author>
    
    <category term="Analysis" />
    
    <content type="html" xml:lang="en" xml:base="http://www.readwriteweb.com/">
      <![CDATA[<p><img alt="web20logo.jpg" src="http://www.readwriteweb.com/images/web20logo.jpg">We're here at the <a href="http://sf.web2expo.com/">Web 2.0 Expo</a> in San Francisco and are getting inundated with press releases about new APIs and developer platforms, many from companies we've never even heard of in the first place.  How long ago was it that the forward-looking thinkers argued that APIs and platforms would soon be available everywhere?  </p>

<p>That time is clearly fast approaching and it makes us wonder: now that this matter is settled, what comes next?  We asked a variety of people here and around the web what they thought will define the next frontier, what will build on the emerging foundation of ubiquitous APIs.   We got some interesting answers.</p>]]>
      <![CDATA[<p>Readers who appreciate this discussion may also enjoy our previous post titled "<a href="http://www.readwriteweb.com/archives/apis_platforms_pros_and_cons.php">APIs and Developer Platforms: A Discussion of the Pros and Cons</a>."  </p>

<p>For now though, let's acknowledge that there are scores and scores of companies that have considered the pros and cons and decided to launch APIs.  Answers to our question about the future ranged from the technical to the social, political and economic.   They often fell into a small number of big-picture trains of thought.  <strong>We hope you'll share your thoughts on the future in comments.</strong></p>

<p>The most interesting replies to the question - "what comes next after APIs become ubiquitous?" can be summarized as follows:</p>

<ul><li>Business models</li>
<li>Filtering for information overload</li>
<li>Standards and interoperability</li>
<li>Outsourcing API services</li>
<li>Backlash</li></ul>

<p>Backlash is included in our list because there is definitely some push back.  Some folks think APIs are for suckers.  We don't agree but those responses were interesting as well.</p>

<h2>Business models</h2>

<p>Perhaps inspired by a touch of cynicism, many of the people we talked to said that finding business models was the next frontier for an API enabled web.  </p>

<p>Nick Gonzales of ad network <a href="http://socialmedia.com">Social Media</a> said that the early rush to build apps on the Facebook platform should be considered the exception more than the rule.  He says it was remarkably easy to build apps on that platform but that hasn't helped developers make money outside of Facebook. It hasn't been the kind of opportunity that many big companies have taken advantage of yet, either.  </p>

<p>What he believes may be necessary in order for big money to be made is long term agreements between platforms and developers, assuring continuity of availability and opportunities to monetize.</p>

<p>Gonzales addresses monetization from an ad network perspective, but other business model options include premium access to APIs or - more likely in this author's opinion - APIs leveraged for lead generation.</p>

<h2>Filtering for information overload</h2>

<p>It's one thing to smash together different streams of data, but making sure the results are user friendly is another matter.  Many people we talked to said they wanted APIs and platforms to increase their capacity for determining relevance.  </p>

<p>Student entrepreneur <a href="http://abhishake.wordpress.com/">Abhishek Nayak</a> put it well when he called for a future characterized by "better platforms like <a href="http://friendfeed.com">FriendFeed</a>, to make sense of all the information and noise from your social networks."  Blogger Eric Eldon of <a href="http://venturebeat.com">VentureBeat</a> felt similarly when asked what comes next.  "FriendFeed will rule," was his three word answer to the question.  How incredible is it that such a young startup has gained Twitter-like metaphor power already?  </p>

<p>Ian Kennedy of Yahoo's <a href="http://mybloglog.com">MyBlogLog</a> predicted that filtering and duplication removal will be big. Software consultant Lokkju Brennr got even more specific: "It will have to be actual natural language parsing," he told us, "combine that with all those APIs, and you have knowledge, instead of just data."</p>

<p>All of those are fun things to think about and bring to mind the semantic web technologies we write about here often as well.</p>

<h2>Standards and interoperability</h2>

<p>The most obvious answer to this question as far as we're concerned is that the next step is to make ubiquitous APIs standards-based and able to work together.  </p>

<p>Tech consultant and co-founder of the Yahoo! Developer Network <a href="http://blog.jeffreymcmanus.com/about/">Jeffrey McManus</a> disagreed with the assessment of APIs being truly widespread but said "the next step is to make them not suck and support them well."</p>

<p>Probably the easiest way to do that is to build them on existing standards. Though many of those are still half-baked pipe dreams today, that's not true in every case.  See Anil Dash of SixApart, for example, <a href="http://www.dashes.com/anil/2008/04/atom-wins-the-unfied-cloud-database-api.html">who says</a> that "AtomPub has become the standard for accessing cloud-based data storage."</p>

<p>Florida venture capitalist <a href="http://www.floridaventureblog.com/">Dan Rua</a> puts it this way:  "after ubiquitous APIs comes category subsystems/adapters, allowing for write once, run with any similar service type abstraction."</p>

<p>One of the most interesting replies we got to our question was from Aaron Fulkerson of <a href="http://mindtouch.com">MindTouch</a>.  Aaron says that the next step is for developers to engineer for concurrent processing; to make APIs not just interoperable but intelligently orchestrated to be called in concert.    The idea here is to create multi-step or functional mashups.  He didn't just come up with that off the top of his head on the floor of the Web 2.0 Expo - it turns out that Mindtouch offers an Open Source framework to accomplish exactly what he's describing as the flavor of the future.</p>

<p>Fulkerson wasn't alone in his hopeful prediction, either, though.  Ruby geek <a href="http://lifeofaudrey.com">Audrey Eschright</a> called for something similar: "Real innovation in the services built on top?" she asked rhetorically. "Not just content mashups, but new kinds of tools."</p>

<p>That sounds great to me.</p>

<h2>Outsourcing API services</h2>

<p>One of the companies we write about often here is <a href="http://mashery.com">Mashery</a>, a startup that manages APIs for companies who want to offer them but prefer to outsource their management to knowledgeable experts.  Mashery reports rapid growth and could represent a key part of the future.</p>

<p>We hear whispers about a number of beyond-stealth startups, too, that are aimed at solving the scalability problems faced by some of the most popular APIs on the web.  That's not at all a dry matter - commoditization of solutions to the biggest technical bottlenecks in making APIs work would open up a whole new world of possibilities.</p>

<p>While this may be the most hard-business vision of the next frontier, it's also one of the visions I get most giddy about.  Any time I get giddy it's probably a good idea to talk about...</p>

<h2>Backlash</h2>

<p>Many people we talked to said that the next step was likely to be one going backwards, away from the frothy wave of "Me Too" APIs and platform announcements.</p>

<p>We heard this from some people we really didn't expect it from.  David Janes, creator of a sophisticated lifestreaming app for groups called <a href="http://onaswarm.com">Onaswarm</a> summarized his feelings thusly: "How about a return to using well-known protocols (as opposed to APIs) for doing well-understood tasks, i.e. publishing and posting data. E.g. RSS/MetaweblogAPI or Atom/APP...It's insane...I've had more than my fill of working with these APIs."  When I pinged him to confirm those lines - he said that it would more accurately explain how he felt about the APIs he's been working with if there were some obscenities sprinkled into his quote.  That from a man who has put his hand into the dragon's mouth.  If you will.</p>

<p>Similar sentiments were expressed by Len Kirby, engineering director at <a href="http://flock.com">Flock</a>.  Flock is a social browser that brings together a large number of social data streams and functionality from all around the web.  None the less, Kirby is no fanboy of the latest wave of APIs and platforms.  </p>

<p>He told us that he thinks the next step in fact may be going back to predictability based on finished standards; as opposed to the half-baked protocols of industry luminaries that didn't finish developing proposed standards.  Tempering his vitriol just a touch, this manager at a company built on Mozilla technology also shared some sympathy.  "Just like any visionaries there's only so much time to make things real and [for example, coming out of] Mozila and RDF there's been a lot of very good things - but time to market rules."  Kirby made sure to affirm as well that Flock really does love Mozilla.</p>

<p>Everyone's got a soft spot for inventors, but a substantial number of people are pushing back on the deafening roar of announcements about new frameworks for invention.</p>

<p>That said, you won't likely hear any of those voices blogging here at ReadWriteWeb!  We think that today's crush of APIs and platforms is just the beginning, that we're at a turning point of innovation.  We love it and intend to chronicle the next steps as best we can.</p>

<p>Here at the Web 2.0 Expo there's plenty of opportunity to discuss what that future might look like.  Internet time traveler <a href="http://hinchcliffeandco.com/">Dion Hinchcliffe</a> counted nine major web mashup announcements at the event before lunch today and asked if critical mass had been reached.  If that's not true yet, all indications are that it certainly will be soon.</p>]]>
    </content>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52877</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52877" />
    <title>Comment from Clay Newton on 2008-04-23</title>
    <author>
        <name>Clay Newton</name>
        <uri>http://remarkd.com</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://remarkd.com">
        <![CDATA[<p>When you think about <a href="http://pipes.yahoo.com" rel="nofollow">http://pipes.yahoo.com</a> or <a href="http://popfly.com" rel="nofollow">http://popfly.com</a> what you are really looking at is the foundation for a web based IDE. At a point where APIs are robust, well documented and relatively ubiquitous, an IDE is critical for sourcing out the production of apps. Sure, there will alway be the deep wonks who can author the appropriate containers for API based services using their existing environments, but a really robust IDE would increase productivity and consistency within and across orgs.</p>

<p>Additionally, I think the future is destined to include some way to gather and analyze the data that is generated by the intersection of multiple APIs. As an example, I would like to have data around clickthrus & eyeballs for items that are in my FriendFeed, Twitter, Fb and blogs. There's no way to monitor stuff fluidly. There will be apps in the future that allow me to filter and analyze this data. On top of that, I can imagine have a fully integrated BI (business intelligence) application devoted to tracking this stuff.</p>]]>
    </content>
    <published>2008-04-23T19:23:27Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52880</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52880" />
    <title>Comment from Nagaraj Hubli on 2008-04-23</title>
    <author>
        <name>Nagaraj Hubli</name>
        <uri>http://www.nagarajhubli.info</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://www.nagarajhubli.info">
        <![CDATA[<p>We have progressed a lot in a way web applications are built and portrayed.. using flash, flex, silverlight and what not.. I personally feel that we are leaving behind the accessibility standards.. which is what I think we should be looking forward to.</p>

<p>We need to innovate in the areas which would help people with disabilities to see and feel what web 2.0 is about.</p>

<p>Rather than just having some screen readers thrown at them, we should try to get something which is revolutionary.</p>

<p>.... I was visualizing the evolution of web, and trying to think where it might take us to.. and I thought of VEB 1.0 (Voice Enabled Browsing), its more like hands free browsing... users voice commands should act like events on the web/application.</p>

<p>example - user should be able to control the video player using voice commands.. and similarly voice controlled components should be placed across the web.</p>]]>
    </content>
    <published>2008-04-23T19:39:14Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52881</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52881" />
    <title>Comment from Ken Kaczmarek on 2008-04-23</title>
    <author>
        <name>Ken Kaczmarek</name>
        <uri>http://www.kirix.com/</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://www.kirix.com/">
        <![CDATA[<p>It appears that standards/interoperability and backlash are really just two-sides of the same coin... it just depends on how optimistic you are.  :)</p>

<p>I personally think the trend toward APIs is a really beneficial thing, but it will take a little bit of time in the oven for some of them until they are fully-baked (and for some to be put into the oven in the first place).  We've seen some great applications built on services with APIs, such as on Twitter and Facebook, but we've also seen a lot of APIs that are far from trivial to deal with.  </p>

<p>APIs should not preclude other standard technologies (RSS, etc.), but seek to enhance them by awarding better data access to those who have the gumption to dig in.</p>]]>
    </content>
    <published>2008-04-23T19:41:36Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52882</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52882" />
    <title>Comment from Casey Cuddy on 2008-04-23</title>
    <author>
        <name>Casey Cuddy</name>
        <uri>http://caseycuddy.com/</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://caseycuddy.com/">
        <![CDATA[<p>As a business-side guy, my concern with the proliferation of APIs focuses on the business model of its provider, and the domino effect resulting from failure. What can be done with an API downstream is secondary to the viability of its provider. Unless the provider can monetize its service, any downstream developer that leverages the API is at risk. In order to hedge this risk downstream apps should have contingency plans for the integration of an alternate API from a copycat service, although the domino effects of a primary provider's failure in its segment could be significant.</p>

<p>However, as VC funding dries up in subsequent rounds for those apps that have not achieved "mass market", downstream developers should anticipate fees for access to APIs, or the "premium" access MK mentions herein. Such fees will be a sign of trouble, IMO, and therefore should be negotiated as a share of the downstream provider's revenue, if possible. This "teamwork" strategy should also be reflected in both provider's product development efforts, for once an API is offered & leveraged, immediate dependencies arise, and it initiates an immediate "informal" partnership.</p>

<p>M&A poses another risk. Recent talk of "Vulture Capital Funds" anticipates fire sales which will often be made to very large, market dominating (proprietary tech?) companies. To expect that an API would remain accessible post-acquisition is short-sighted, IMO.</p>

<p>It's apparent that I am in the "Backlash" camp, although I think this is as much about strategy as it is about code. If API providers view downstream developers as extensions of product development efforts, then significant cost and operational benefits emerge. The sum of the whole becomes more valuable than that of its parts, which can then be leveraged to access funding, and perhaps even in finding a workable, non-ad supported "mass market" revenue model.</p>]]>
    </content>
    <published>2008-04-23T20:05:44Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52883</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52883" />
    <title>Comment from Kelly Guimont on 2008-04-23</title>
    <author>
        <name>Kelly Guimont</name>
        <uri></uri>
    </author>
    <content type="html" xml:lang="en" xml:base="">
        <![CDATA[<p>I think the next thing to watch for is the creation of the piece that allows me to have my own ID **and friend list** that is liberated from the account creating/populating process. OpenID is getting there by letting me have one sign in for many sites, and Vidoop (for example) is getting closer. But I want a place where I store my name/email/profile/friends and when I go to the next Twitter/Facebook/Brightkite/?? I can just check some boxes. Use this name and email, these people are already on here so add them to my list, and done. Whoever can do that in a basic enough format to allow anyone building new services to hook into it will forever have my allegiance. </p>]]>
    </content>
    <published>2008-04-23T20:09:45Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52884</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52884" />
    <title>Comment from Don Park on 2008-04-23</title>
    <author>
        <name>Don Park</name>
        <uri></uri>
    </author>
    <content type="html" xml:lang="en" xml:base="">
        <![CDATA[<p>one thing to remember is that every site has an 'API'. its called HTTP. thats why semantic markup (like microformats) is useful. the same HTML results do double-duty of being human readable and machine readable.</p>]]>
    </content>
    <published>2008-04-23T20:18:46Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52891</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52891" />
    <title>Comment from Jeffrey McManus on 2008-04-23</title>
    <author>
        <name>Jeffrey McManus</name>
        <uri>http://blog.jeffreymcmanus.com/</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://blog.jeffreymcmanus.com/">
        <![CDATA[<p>Replace all web APIs with RSS feeds? Yeah, good luck with that, champ.</p>

<p>HTTP is not an API, it's a communications protocol. It isn't at the right level of the stack for application development, anyway.</p>]]>
    </content>
    <published>2008-04-23T22:01:44Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52893</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52893" />
    <title>Comment from Xavier on 2008-04-23</title>
    <author>
        <name>Xavier</name>
        <uri>http://www.commentag.com/blog</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://www.commentag.com/blog">
        <![CDATA[<p>"Filtering for information overload", that's exactly what we do at <a href="http://www.commentag.com" rel="nofollow">http://www.commentag.com</a> by mixing UGT (User Generated Tags) and Web Semantic (to auto suggest tags).</p>

<p>What do you think of it?<br />
What kind of API would you like such service to have?</p>]]>
    </content>
    <published>2008-04-23T22:18:21Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52905</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52905" />
    <title>Comment from Dan York on 2008-04-23</title>
    <author>
        <name>Dan York</name>
        <uri>http://blogs.voxeo.com/</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://blogs.voxeo.com/">
        <![CDATA[<p>Nice piece, Marshall.  On the one hand, as someone who has long been advocating opening up APIs and letting users/customers have access to them even if you're not sure exactly what they will do with them, I'm delighted by the trend and I look forward to seeing more and more APIs become available.</p>

<p>However, I share the concern that you and several other commenters wrote about - just throwing up an "API" without much thought and without looking to see if an existing API is already out there that will do what you need doesn't help anyone.  We just wind up with a mess of zillions of different APIs that developers have to try to understand in order to use.</p>

<p>Folks looking at coming up with an API for their product or service should first look at the long list of existing APIs at sites like <a href="http://www.programmableweb.com/apis/directory" rel="nofollow">http://www.programmableweb.com/apis/directory</a> (currently listing 732 APIs). If they can find one there that does what they need, they should use it.  Even better if they can find an API based on an open standard. If *none* of the APIs will work, *then* - and only then - should they create some new API.</p>

<p>I'd love to see that happen more, but I'm also skeptical...</p>

<p>Please do keep these great pieces coming,<br />
Dan</p>]]>
    </content>
    <published>2008-04-24T00:02:46Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52917</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52917" />
    <title>Comment from Vivek Bhaskaran on 2008-04-23</title>
    <author>
        <name>Vivek Bhaskaran</name>
        <uri>http://blog.questionpro.com</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://blog.questionpro.com">
        <![CDATA[<p>I am here also @ the Web 2.0 conference and after listening to a couple of talks about Online Worlds (Second Life Cloans etc.) and how big brands have "immersed" themselves into the world -- Where brands like Scion _built_ an app (within a virtual world) to allow users to build and customize their own scion within the virtual world. They talked about this kind of immersion vs. a banner ad display for a Scion ad does not even compare.</p>

<p>I think the next frontier will be where brands will create applications/tools/services that part of our social infrastructure. Think of it as product placement for applications and social media. Yes, beacon was a disaster, but think of it this way -- If Coke innovated a twitter like service (before twitter) they can subtly influence behavior and brand recall and association. </p>]]>
    </content>
    <published>2008-04-24T05:02:19Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52926</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52926" />
    <title>Comment from alan p on 2008-04-24</title>
    <author>
        <name>alan p</name>
        <uri>http://www.broadstuff.com</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://www.broadstuff.com">
        <![CDATA[<p>Nice post - rather than leave a comment it drove me to write a whole blog post, over here:</p>

<p><a href="http://broadstuff.com/archives/880-Platforms-as-a-Me-Too.html" rel="nofollow">http://broadstuff.com/archives/880-Platforms-as-a-Me-Too.html</a></p>]]>
    </content>
    <published>2008-04-24T10:17:45Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52934</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52934" />
    <title>Comment from vanderwal on 2008-04-24</title>
    <author>
        <name>vanderwal</name>
        <uri>http://vanderwal.net/random/</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://vanderwal.net/random/">
        <![CDATA[<p>Having announcements around mashups strikes me as very funny as mashups are just things you do. It sounds like the 90s version of we added JavaScript to our site or our site is dynamic. This is the web, this is what is normal. </p>

<p>Loved the post. Ian Kennedy nailed what I see as the greatest need for next steps, filtering and aggregating duplicates to minimize the flood caused by repetitious echoes - or as Cliff on Cheers said, "your being redundant, repeating yourself, and saying things over and over again". </p>]]>
    </content>
    <published>2008-04-24T13:59:54Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:52951</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c52951" />
    <title>Comment from Thomas on 2008-04-24</title>
    <author>
        <name>Thomas</name>
        <uri></uri>
    </author>
    <content type="html" xml:lang="en" xml:base="">
        <![CDATA[<p>I thought Mozilla was a defacto standard.</p>]]>
    </content>
    <published>2008-04-24T18:20:52Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:53251</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c53251" />
    <title>Comment from Jim Donovan on 2008-04-28</title>
    <author>
        <name>Jim Donovan</name>
        <uri>http://jimdonovan.net.nz</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://jimdonovan.net.nz">
        <![CDATA[<p>Not exactly a world-changing list, is it? More like bug0fixing.</p>]]>
    </content>
    <published>2008-04-28T19:38:00Z</published>
  </entry>

  <entry>
    <id>tag:www.readwriteweb.com,2008://1.6169-comment:53613</id>
    <thr:in-reply-to ref="tag:www.readwriteweb.com,2008://1.6169" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php"/>
    <link rel="alternate" type="text/html" href="http://www.readwriteweb.com/archives/after_apis.php#c53613" />
    <title>Comment from Burak Arikan on 2008-05-01</title>
    <author>
        <name>Burak Arikan</name>
        <uri>http://burak-arikan.com</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://burak-arikan.com">
        <![CDATA[<p>unbelievable istabul</p>]]>
    </content>
    <published>2008-05-02T00:14:40Z</published>
  </entry>

</feed>