<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
	>

<channel>
	<title>GigaOM &#187; Rip Gerber</title>
	<atom:link href="http://gigaom.com/tag/rip-gerber/feed/" rel="self" type="application/rss+xml" />
	<link>http://gigaom.com</link>
	<description></description>
	<lastBuildDate>Thu, 23 May 2013 18:21:58 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
<cloud domain='gigaom.com' port='80' path='/?rsscloud=notify' registerProcedure='' protocol='http-post' />
<image>
		<url>http://0.gravatar.com/blavatar/0db8f6557d022075dbbf010c54d46d93?s=96&#038;d=http%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.png</url>
		<title>GigaOM &#187; Rip Gerber</title>
		<link>http://gigaom.com</link>
	</image>
	<atom:link rel="search" type="application/opensearchdescription+xml" href="http://gigaom.com/osd.xml" title="GigaOM" />
	<atom:link rel='hub' href='http://gigaom.com/?pushpress=hub'/>
		<item>
		<title>With WAC’s demise carriers look for API alternatives</title>
		<link>http://gigaom.com/2012/08/01/with-wacs-demise-carriers-look-for-api-alternatives/</link>
		<comments>http://gigaom.com/2012/08/01/with-wacs-demise-carriers-look-for-api-alternatives/#comments</comments>
		<pubDate>Wed, 01 Aug 2012 19:37:46 +0000</pubDate>
		<dc:creator>Kevin Fitchard</dc:creator>
				<category><![CDATA[API platforms]]></category>
		<category><![CDATA[applications]]></category>
		<category><![CDATA[carrier consortium]]></category>
		<category><![CDATA[developers]]></category>
		<category><![CDATA[Rip Gerber]]></category>

		<guid isPermaLink="false">http://gigaom.com/?p=549154</guid>
		<description><![CDATA[Mobile operators big ambition to expose a common global API to developers has evaporated, but carriers are still searching for that holy grail -- relevance to the developer community. Carriers are signing their own API deals and launching new standards efforts, but ultimately they'll be disappointed.<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=gigaom.com&#038;blog=14960843&#038;post=549154&#038;subd=gigaom2&#038;ref=&#038;feed=1" width="1" height="1" />]]></description>
				<content:encoded><![CDATA[<p>The <a href="http://gigaom.com/mobile/bye-bye-wac-so-much-for-carriers-standardizing-apps/">Wholesale Application Community may be defunct</a>, but some hope of accomplishing WAC’s original mission – building a common set of mobile network APIs for developers – seems to remain. Other standards bodies are trying to pick up where WAC left off, and individual carriers are looking at private companies to do the work they couldn’t accomplish as a group.</p>
<p>Leap Wireless, which operates the Cricket Communications prepaid carrier, has tapped <a href="http://www.aepona.com/news-events/aeponas-network-as-a-service-solution-chosen-by-cricket-communications/">Aepona to provide it with a managed API platform</a>. Belfast, U.K.,-based <a href="http://paidcontent.org/2010/05/06/419-blackberry-leads-10-million-vc-in-mobile-web-apis-firm-aepona/">Aepona</a> plays two roles. First, it simplifies carriers’ complex and proprietary network APIs for billing, location and presence and exposes them to developers in a much easier-to-use format. Second, it handles the nitty-gritty of developer recruitment, relations and support – tasks that are not exactly the carriers’ forte.</p>
<p>On the standards front, the Alliance for Telecommunications Industry Solutions (ATIS) has grabbed the baton dropped by WAC and is <a href="http://www.atis.org/PRESS/pressreleases2012/073112.html">developing its own network API framework</a> that would allow HTML5 developers and device makers to dive into the hitherto murky depths of carriers’ core networks. ATIS, however, is a North American standards development group. <a href="http://www.atis.org/membership/members.asp">Most U.S. and Canadian carriers are members</a>, as are the big global handset and infrastructure ventures, so its recommendations don’t carry much weight over the oceans.</p>
<p><a href="http://gigaom.com/2010/10/18/do-we-need-a-global-app-store-for-feature-phones/fragmentation/" rel="attachment wp-att-167113"><img  title="fragmentation" src="http://gigaom2.files.wordpress.com/2010/10/fragmentation.jpg?w=708" alt=""   class="alignleft size-full wp-image-167113" /></a>Herein lies the problem: while <a href="http://gigaom.com/2010/05/05/global-carriers-unite-for-a-share-of-the-mobile-app-economy/">WAC’s mandate was truly global</a> – its membership was comprised of 4 dozen operators from every part of the world – the efforts emerging to replace it are fragmented. And one of the biggest reasons (among many) developers don’t want to work with operators is the problem of fragmentation: signing separate deals with individual carriers and developing to each operator’s own technical standards and APIs.</p>
<p>WAC was a noble idea, but as <a href="http://gigaom.com/2012/07/28/why-carriers-cant-create-common-apis-but-need-to-keep-trying/">Locaid CEO Rip Gerber wrote in a recent GigaOM contributed piece</a>, operators are probably the most ill-equipped creatures to turn such a grand plan into reality. Ultimately WAC failed, Gerber said, for three reasons:  carrier collectives move slowly &#8212; even when the stakes are high – building API’s simply isn’t in carriers’ DNA and because WAC ultimately had neither the mandate, nor the wherewithal, to bring those APIs to market.</p>
<p>Gerber’s answer is to hand the work over to API specialists like his <a href="http://paidcontent.org/tech/419-skyhook-and-loc-aid-reduce-the-barriers-to-providing-location-based-inf/">own location interface company Locaid</a>, <a href="http://gigaom.com/2012/07/24/api-manager-apigee-gets-20m-for-mobile-focus/">Apigee</a> or Aepona. These companies obviously are better equipped than any carrier consortium to do the technical work as well as deal with the <a href="http://gigaom.com/mobile/which-mobile-oss-apps-make-most-money-surprise-its-blackberry/">finicky developer community</a> But the problem of fragmentation remains. Half a dozen API companies means half a dozen platforms with which developers must deal.</p>
<p>Kudos to ATIS for taking another crack at seemingly insurmountable problem, but it’s just one standards development body of dozens worldwide. The GSMA is also taking up WAC’s slack working with Apigee as part of its One API initiative. Canadian carriers are working with Apigee’s competitor Aepona. If all of this standards work results in a dozen different API frameworks, we don’t really have a standard at all.</p>
<p>I agree with Gerber that half a dozen simplified API frameworks are better than 200 complex ones. And some developers would be able to work within those divisions. In the unlikely event U.S. carriers adopted a unified API framework, it could be attractive to any developer building apps primarily for the domestic market.</p>
<p>Even if a carrier like Leap finds itself on an API island, it can still put those interfaces to work. Cricket has enjoyed quite a bit of success with its <a href="http://paidcontent.org/2011/01/21/419-nokia-stumbled-but-mobile-music-services-are-still-gaining-ground/">white-label Muve music subscription service</a>. Using Aepona’s simplified APIs, it would be much easier for a Leap to recruit new content suppliers and launch their services.</p>
<p>But those kind of tight-knit carrier-developer relationships are a rarity and the tiniest fraction of the overall applications market. What carriers dream of doing is becoming part of the global app distribution chain, taking a cut of every app billed to their customers or charging fees to access their other APIs. Developers simply aren’t going to play that carrier game if they can get much wider exposure – and less headache – working with Apple, Google and Microsoft. Without some semblance of a common API, that carrier dream is never going to happen.</p>
<p><em>Featured photo courtesy of <a href="http://www.shutterstock.com/pic-79634698/stock-photo-standing-at-the-crossroad.html">Shutterstock</a> user Chantall; Puzzle i</em><em>mage courtesy Flickr user <a href="http://www.flickr.com/photos/horiavarlan/4273913228/">Horia Varlan</a>.</em></p>
<br />  <img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=gigaom.com&#038;blog=14960843&#038;post=549154&#038;subd=gigaom2&#038;ref=&#038;feed=1" width="1" height="1" /><p><a href="http://pubads.g.doubleclick.net/gampad/jump?iu=/1008864/GigaOM_RSS_300x250&#038;sz=300x250&#038;c=283619"><img src="http://pubads.g.doubleclick.net/gampad/ad?iu=/1008864/GigaOM_RSS_300x250&#038;sz=300x250&#038;c=283619" /></a></p><p><strong>Related research and analysis from GigaOM Pro:</strong><br />Subscriber content. <a href="http://pro.gigaom.com/?utm_source=mobile&utm_medium=editorial&utm_campaign=auto3&utm_term=549154+with-wacs-demise-carriers-look-for-api-alternatives&utm_content=kfitchard">Sign up for a free trial</a>.</p><ul><li><a href="http://pro.gigaom.com/2011/09/the-future-of-mobile-a-segment-analysis-by-gigaom-pro/?utm_source=mobile&utm_medium=editorial&utm_campaign=auto3&utm_term=549154+with-wacs-demise-carriers-look-for-api-alternatives&utm_content=kfitchard">The future of mobile: a segment analysis by GigaOM Pro</a></li><li><a href="http://pro.gigaom.com/2012/07/the-wearable-computing-market-a-global-analysis/?utm_source=mobile&utm_medium=editorial&utm_campaign=auto3&utm_term=549154+with-wacs-demise-carriers-look-for-api-alternatives&utm_content=kfitchard">Analyzing the wearable computing market</a></li><li><a href="http://pro.gigaom.com/2012/04/mobile-q1-the-fight-for-spectrum-goes-to-washington-the-tablet-wars-continue/?utm_source=mobile&utm_medium=editorial&utm_campaign=auto3&utm_term=549154+with-wacs-demise-carriers-look-for-api-alternatives&utm_content=kfitchard">A look back at mobile in Q1</a></li></ul>]]></content:encoded>
			<wfw:commentRss>http://gigaom.com/2012/08/01/with-wacs-demise-carriers-look-for-api-alternatives/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
	
		<media:thumbnail url="http://gigaom2.files.wordpress.com/2012/08/shutterstock_79634698.jpg?w=150" />
		<media:content url="http://gigaom2.files.wordpress.com/2012/08/shutterstock_79634698.jpg?w=150" medium="image">
			<media:title type="html">Choices decisions arrows</media:title>
		</media:content>

		<media:content url="http://0.gravatar.com/avatar/0544c4b228f8fa80e31bb952501cd7a4?s=96&#38;d=retro&#38;r=PG" medium="image">
			<media:title type="html">kfitchard</media:title>
		</media:content>

		<media:content url="http://gigaom2.files.wordpress.com/2010/10/fragmentation.jpg" medium="image">
			<media:title type="html">fragmentation</media:title>
		</media:content>
	</item>
		<item>
		<title>Why carriers can’t create common APIs (but need to keep trying)</title>
		<link>http://gigaom.com/2012/07/28/why-carriers-cant-create-common-apis-but-need-to-keep-trying/</link>
		<comments>http://gigaom.com/2012/07/28/why-carriers-cant-create-common-apis-but-need-to-keep-trying/#comments</comments>
		<pubDate>Sat, 28 Jul 2012 17:28:45 +0000</pubDate>
		<dc:creator>Rip Gerber, Locaid</dc:creator>
				<category><![CDATA[Rip Gerber]]></category>
		<category><![CDATA[wireless carriers]]></category>

		<guid isPermaLink="false">http://gigaom.com/?p=547714</guid>
		<description><![CDATA[The Wholesale Application Community (WAC) will go down in mobile history as one of the most ambitious, but failed, attempts at collaboration by our dear telco friends. Locaid's CEO Rip Gerber explains why these powerful carriers -- all facing common threats -- couldn't get their WAC together.<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=gigaom.com&#038;blog=14960843&#038;post=547714&#038;subd=gigaom2&#038;ref=&#038;feed=1" width="1" height="1" />]]></description>
				<content:encoded><![CDATA[<p>Over the past two decades, I’ve built and sold a few companies that have exploited the simple fact that the bigger an industry behemoth grows, the harder it gets for it to serve its customers. At my last company, Intellisync, my teams built products that wireless carriers needed but couldn’t deliver. Today, I run <a href="http://www.loc-aid.com/">Locaid</a>, a company that simply ﬁlls a void between giant carriers and giant enterprise developers. It’s hard enough for a single giant to innovate, so why do they always assume a coalition of giants will fare better? They never do.</p>
<p>Coalitions seldom succeed unless the members are motivated by a supreme crisis. Throughout history, a major threat or act of war was often needed to compel independent and competing parties to join forces for common gain: the United States, NATO, the international ban on whaling. Business can be war too, but the stakes aren’t usually high enough to keep a collective of companies aligned under a common agenda. Except for OPEC or Hollywood agencies, coalitions tend to generate more fodder for the press than progress.</p>
<p>Last week, another coalition tombstone was etched. As Kevin Fitchard <a href="http://gigaom.com/mobile/bye-bye-wac-so-much-for-carriers-standardizing-apps/">explained (and eerily predicted) in his recent article</a>: the Wholesale Application Community (WAC) will go down in mobile history as one of the most ambitious, but failed, collaboration attempts of our dear telco friends.</p>
<p>WAC, if you don’t know, was an industry alliance of 47 of the largest worldwide mobile operators. It was formed in 2010 to help wireless carriers compete in an open, unwalled mobile world. Rather than force developers to work with each individual operator to get APIs, the carriers would design a “single API” for location, billing, messaging and more. This would be the “iTunes for carrier stuff.”</p>
<p>Why couldn’t these powerful carriers &#8212; all facing common threats from open, data rich, ubiquitous platforms such as Apple, Google, Facebook and Amazon &#8212; get their WAC together?</p>
<h2><strong>The bullets shot in WAC’s back</strong></h2>
<p><strong>Membership impatience.</strong> Collectively, the carriers endeavored for more than two years to launch a “single API,” and failed to develop much of anything. Now the carriers are individually frustrated with the GSMA and WAC. Rightly so. You won’t find the AT&amp;T and Verizon chief technology officers publicly bashing the GSMA. But within their carrier walls, you can hear their screams at LTE and 4G speed. Don’t be surprised if splinter groups of carriers leave the WAC’s original 47 members behind to form their own common API solutions. And they should. Developers want tools and APIs that are easy and ubiquitous. A group of 47 single-minded designers won’t ever create a slick, friendly interface.</p>
<p><strong>APIs aren’t backhaul.</strong> Deploying servers and towers is easy after developing decades of monopolistic experience. But building APIs is hard. Those of us that do it well (such as Apigee, or my company, Locaid) have spent years and tens of millions of patient investor money connecting behemoth, byzantine carrier networks to create easy-to-use APIs for developers. You cannot create an API by committee. And while the carriers have done a yeoman’s job of offering up more APIs – either directly or through partners – for high-demand services such a billing, messaging, location, it’s not an effort conducive to a group. The task is made more difficult for carriers because top developer talent wants Apple, Google or the latest VC-backed wunderkind on their resume &#8212; not AT&amp;T or Vodafone. Carriers are trying to attract top developers, but that takes time. “Coding at carrier” isn’t hip in the college dorms just yet.</p>
<p>Policy versus products. Ultimately, WAC was a policy-setting machine, not an execution machine. And it certainly wasn’t a market-making initiative, which is what the carriers all desperately want. Some of us in the API enabler market have more sales people selling carrier API data than all 47 WAC carriers combined. It takes focus, design and execution to win share. And if you can’t launch product, you won’t survive. Hence, RIP WAC.</p>
<p><strong>WAC will be resurrected.</strong> The concept of carriers working together comes around every few years. WAC will rise again (under a new brand no doubt). But even if carriers can get their network technology people to agree on standards, code, enablers, SLAs, etc. (good luck with that), and even if the carriers’ legal teams can agree on liability, privacy, etc. (more good luck to them there), they still have a major issue: carriers will have a hard time selling APIs. These are telcos. The sales teams, commission incentives, even the product offers, need to be dramatically restructured to become “developer friendly” services. Carriers can get there, but the journey will take time.</p>
<p><strong>It’s a shame, really.</strong> The carriers want what WAC promised, and two-by-two they will eventually get there. WAC and carriers are populated with smart, innovative folks, and they should be admired for their ambition and fight. But carrier machinery &#8212; processing billions of bits per second at five nines of reliability &#8212; isn’t built to move at developer speed. Not out of the gate.</p>
<p>This is a great opportunity for developers. The message from the market is now loud and clear: “WAC is dead! Long live WAC!” The holy grail of “one API” remains. Venture capitalists and strategic investors have been funding the market-driven API agenda to date, and they will continue to do so because it’s the right thing to do. And it will be up to nimble, focused innovators to fill the need, one API at a time.</p>
<p><em>Rip Gerber is the founder and CEO of Locaid. The company offers Location-as-a-Service that connects developers to Tier 1 carriers via a single API.</em></p>
<p><em><a title="Attribution License" href="http://creativecommons.org/licenses/by/2.0/">Image courtesy of</a> Flickr user <a href="http://www.flickr.com/photos/buddawiggi/">buddawiggi</a>.</em></p>
<br />  <img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=gigaom.com&#038;blog=14960843&#038;post=547714&#038;subd=gigaom2&#038;ref=&#038;feed=1" width="1" height="1" /><p><a href="http://pubads.g.doubleclick.net/gampad/jump?iu=/1008864/GigaOM_RSS_300x250&#038;sz=300x250&#038;c=742644"><img src="http://pubads.g.doubleclick.net/gampad/ad?iu=/1008864/GigaOM_RSS_300x250&#038;sz=300x250&#038;c=742644" /></a></p><p><strong>Related research and analysis from GigaOM Pro:</strong><br />Subscriber content. <a href="http://pro.gigaom.com/?utm_source=tech&utm_medium=editorial&utm_campaign=auto3&utm_term=547714+why-carriers-cant-create-common-apis-but-need-to-keep-trying&utm_content=gigaguest">Sign up for a free trial</a>.</p><ul><li><a href="http://pro.gigaom.com/2011/12/carrier-iq-and-the-continued-erosion-of-operator-trust/?utm_source=tech&utm_medium=editorial&utm_campaign=auto3&utm_term=547714+why-carriers-cant-create-common-apis-but-need-to-keep-trying&utm_content=gigaguest">Carrier IQ and the continued erosion of operator trust</a></li><li><a href="http://pro.gigaom.com/2011/11/connected-world-the-consumer-technology-revolution/?utm_source=tech&utm_medium=editorial&utm_campaign=auto3&utm_term=547714+why-carriers-cant-create-common-apis-but-need-to-keep-trying&utm_content=gigaguest">Connected world: the consumer technology revolution</a></li><li><a href="http://pro.gigaom.com/2011/09/the-future-of-mobile-a-segment-analysis-by-gigaom-pro/?utm_source=tech&utm_medium=editorial&utm_campaign=auto3&utm_term=547714+why-carriers-cant-create-common-apis-but-need-to-keep-trying&utm_content=gigaguest">The future of mobile: a segment analysis by GigaOM Pro</a></li></ul>]]></content:encoded>
			<wfw:commentRss>http://gigaom.com/2012/07/28/why-carriers-cant-create-common-apis-but-need-to-keep-trying/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
	
		<media:thumbnail url="http://gigaom2.files.wordpress.com/2012/07/handshake_buddawiggi.jpg?w=150" />
		<media:content url="http://gigaom2.files.wordpress.com/2012/07/handshake_buddawiggi.jpg?w=150" medium="image">
			<media:title type="html">handshake_buddawiggi</media:title>
		</media:content>

		<media:content url="http://1.gravatar.com/avatar/4411542bbd7a2a9a2fc2a1b38809e45c?s=96&#38;d=retro&#38;r=PG" medium="image">
			<media:title type="html">gigaguest</media:title>
		</media:content>
	</item>
	</channel>
</rss>
