Anyway, Truecaller now has 600 million partly crowdsourced names and phone numbers in its database, which is quite a lot, and it’s decided to open up this information to third parties that can make good use of it. “Great,” you might think, “what a boon to telemarketers.” But no, Truecaller is rather sensibly hand-picking those developers who get to tap into its newly-launched, 3scale-managed API, and telemarketers are not welcome at all.

As for potential uses for this reverse lookup service, that’s up to the developer’s imagination. Here’s what Truecaller CEO Alan Mamedi suggests:

“Among many other scenarios, the Truecaller API could be used to save time in call centres. Each call centre minute is connected to a cost. By using our API, both local and global, call centres can identify who is calling even before starting the call. Win-win.”

Truecaller’s database is populated by two main sources: traditional phone directory services and users who are willing to upload their address books. This latter source means it can contain numbers that are unlisted, including pay-as-you-go phone numbers. Numbers in the database come with two types of scores: a “spam score” to rate how likely it is that they are associated with telesales or robocalls, and a “true score” to denote importance.

Importantly, name search will not be a function associated with the API – it will only be available on the mobile app, meaning the API can only be used for reverse lookup purposes.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

As part of reaching that objective, Cloudbase.io has launched a shared API to encourage data-sharing between apps. By way of example, someone coming up with a Foursquare-like idea could decide to use Cloudbase.io to build their application. Cloudbase.io would handle the backend for that app, and the developer could tell the BaaS provider to let other apps access their shared API, allowing those apps to draw on the app’s check-in data and creating opportunities for business deals down the line.

As Buliani told me:

“What I found everywhere [as I was promoting] Cloudbase.io was that everybody with a background as a backend developer instantly got it. Mobile developers were questioning the need for their application to be connected to the internet. Most mobile developers are only mobile developers; they’ve never done anything else before – never worked on websites, for example. They had this mentality of building the small game for mobile.

“The premise for the idea is that we want mobile applications to become platforms. We want them to be able to publish their own layer of APIs, even though it’s hosted on Cloudbase.io. Cloudbase.io becomes invisible in the background. We want to encourage them to be as ambitious as possible and think of themselves as a platform. It’s a chicken-and-egg game of course – what came first, the business or the API? – but we want them to be prepared for it.”

This perspective is unsurprising coming from Buliani, a developer (he was part of the early Covestor team) who became a management consultant in London’s financial heart before returning to tech. But then again, Cloudbase.io is not the only company trying to help smalltime developers think bigger.

So what about rivals such as Parse? According to Buliani, there’s a “philosophical difference” between the two outfits.

“The easiest example is, if you want to build an application on top of Parse you have to register the users of your application within that framework, so your application will have to have authentication. With Cloudbase.io you can have no authentication — it’s entirely up to you,” he said, adding that he was proud of the fact that all of Cloudbase.io’s libraries are open source and available on Github.

Of course, Cloudbase.io’s new service also crosses over somewhat with the territory of API management specialists such as Apigee and 3scale.

As with Parse, it’s free to register with Cloudbase.io and get going. Once the app’s in an app store, users need to start paying – the most basic account costs $11.99 a month, which comes with a gigabyte of data exchange. Above that are professional ($47.99 for 8GB) and enterprise ($119.99 for 20GB) tiers, with the possibility of negotiated pricing for higher volumes.

Users should take note of how data exchange volume pricing works with the shared API. If the app accessing data from the original, Cloudbase.io-using app is also using the same BaaS platform, it’s that second app that gets charged. If the second app is off-platform, it will obviously be the original app’s developers who get charged (it might be smart to publish the shared API but keep it password protected).

Incidentally, for those developers who need as much help as possible, Cloudbase.io also partnered up last month with MoSync, a provider of open-source tools for building mobile applications. The idea there is for MoSync to allow the building and compiling of the apps, with Cloudbase.io adding in the connectivity, geo-location and social pieces.

(And on another note, cloud infrastructure and data-sharing will definitely be on the agenda for discussion at our Structure:Europe conference, which will run in London on September 18-19.)

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Connected world: the consumer technology revolution
• Social media in Q1: commerce and discovery dominated
• 12 tech leaders’ resolutions for 2012

As my colleague Eliza Kern noted in her post on the new features, Twitter has given third-party apps the ability to add “deep links” to content inside a tweet, so that — for example — if a user includes a link to a photo from Path or Flickr and someone reading that tweet has the Path app or the Flickr app installed on their device, clicking the link launches that app and takes them directly to the content (a link to a download page for the app can also be included).

Twitter can help with app discovery

The benefits of these new features are clear, as Fred Wilson from Union Square Ventures (one of Twitter’s backers) and others have noted. For services like Path, one of the hardest problems is discovery — in other words, letting people know it exists, and also making it easy for users to find interesting content within the app. Twitter’s new Card features provide a potential solution for both of those problems, and since the social network has an active-user base of close to 250 million, it could give some services a substantial boost.

Really excited to integrate the new @twitter cards into @circa. This will be a game changer for app distribution.

—
Matt Galligan (@mg) April 03, 2013

The downside of this approach should also be obvious, however, especially if you notice that among Twitter’s partners for these new features there are names like Path and Flickr, but no Instagram. Why isn’t the largest photo-sharing service included? Because it is owned by Facebook, and Twitter cut off the app’s access to a key feature last year — namely, the ability for users to find Twitter friends who also use the service — and Instagram subsequently removed Card support. The company also cut off Tumblr’s access to the same feature, even though Tumblr was an early partner on the Cards rollout.

This is the fundamental difference between Twitter’s current approach to being a platform and its previous approach. In the early days of the service, up until mid-2011, Twitter seemed happy to be at the center of a more or less open ecosystem — one which allowed virtually anyone to make use of the company’s APIs to display or make use of tweets. Many services and apps (including Instagram) grew by piggy-backing on the network in this way.

Then came what one Twitter investor has called a “holy s*** moment”: Bill Gross — founder of what was then called Uber Media — started buying up Twitter clients (including an attempt to buy Tweetdeck, which Twitter ultimately acquired) and appeared to be preparing to launch his own network, one that would make use of tweets combined with a third-party advertising model.

Twitter’s control is a double-edged sword

These moves by Gross and others posed a clear threat to Twitter’s ability to monetize its growing user base — something that was becoming more and more crucial given the multibillion-dollar market value the company had developed after several rounds of financing. So the company started tightening the screws around its network: restricting access to the API, changing what were display “guidelines” into “requirements,” and generally exerting much more control over who got access to the company’s data.

Such decisions caused a firestorm of controversy in the third-party developer community, with some complaining that Twitter had “killed” their businesses. Now, the company is clearly trying to repair some of that damaged goodwill by offering third-party apps and services preferential access to the network, and features like Card deep links — replacing the open ecosystem approach with one that is more a velvet rope: only official partners allowed.

This approach makes sense for Twitter, since it needs to generate revenue from its network, and presumably intends (or theoretically could) collect fees from partners for the additional features they are getting with Twitter Cards, which can also include music links and other content. And as noted above, it makes sense for apps and services like Path to cut a deal in order to get more reach — but just like building integration into Facebook or Apple or any other controlled ecosystem, developers should be aware this is a double-edged sword.

In other words, such an arrangement will likely look like a win-win so long as Twitter thinks you are beneficial to its network. The minute it sees you as competition, it will suddenly become lose-lose — and whatever you have invested in that ecosystem will vanish.

Post and thumbnail images courtesy of Shutterstock / Ljupo Smokovski and Flickr user Rosauro Ochoa

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

When Wonder launched in the U.S., Russia’s Yandex was keen to maintain that it wasn’t a ‘search engine’ – it just helped people search for information from within specific networks. Facebook, which recently launched its own network search capabilities, didn’t see things that way, and shut off its Graph API
to Wonder almost immediately.

“It was confirmed that Facebook views the application Wonder as something that violates the Facebook Platform Policies and that the access to Facebook’s Graph API will not be restored,” Yandex said in a statement on Wednesday.

“Wonder’s functioning, in its current state, as well as the quality of user experience it provides, largely depends on the access to Facebook’s Graph API. Since this access was revoked, we decided to put our application on hold for the time being.”

Yandex went on to say it was considering partnership opportunities with other social networks. But really, without Facebook the app has a big hole in it for many if not most users.

Which is a shame, given that Wonder is all about letting users search across the data and human connections that they themselves have donated to Facebook and others. That’s not how Facebook sees it, though, so – at least for now – end of story.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Survey: How apps can solve photo management
• Sector RoadMap: Social customer service in 2013
• Sector RoadMap: Content personalization in 2013

So not surprisingly, one of the biggest champions of personal data ownership and paid services when it comes to social networks is forging an experiment in file storage and ownership. Dalton Caldwell plans to announced Monday that App.net will be launching a file storage API, giving each of its existing users 10 GB of file storage space connected with their accounts, so they can personally host their own photos and files and then authorize App.net apps to access those files.

App.net launched in the summer of 2012, and it’s still a little unclear exactly how Caldwell’s vision for the network is going to play out. He is currently committed to a paid network strategy where users have access to all the apps created on top of the App.net API, including everything from group texting apps to a network that looks pretty much like Twitter. Developers are paid from users subscription fees based on the popularity of the apps developers build.

Central to Caldwell’s thesis is that a paid network creates more value for the developers and gives users more ownership over their data and information. For instance, if you have an Instagram or Flickr account, you upload photos to the services which are then hosted on those companies servers even if you retain copies of the photos yourself. With App.net’s storage API, you would host your own photos in the cloud, and give authorization to different apps to access your photos (just as you give an app access to photos on your iPhone’s camera roll, for instance.)

“It’s like your personal Dropbox,” Caldwell said. “You want to maintain the originals and feel like they’re yours.” He noted that allowing for photo and file apps will be an important part of growing the App.net developer network, which is now fairly focused on text-based apps.

Caldwell said he thinks moving into photo and file storage will provide App.net developers a good deal of flexibility in what they design with the service’s API, and moves App.net into a potentially more useful and lucrative area for both users and developers.

“It’s an attempt to get away from some of the downsides of a siloed data storage,” he said.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Sector RoadMap: Content personalization in 2013
• Personal tools lead to practical business
• What We Can Learn From the Guardian’s New Open Platform

Twitter first began adding products to the Certified Products list this summer, and we explained the rationale behind the program:

This summer, the developer community has been consumed with the question of which apps using the Twitter API will keep the company’s approval and survive, and which will be shut down for conflicting with Twitter’s interests. Twitter first began to distinguish between apps with its August blog post, laying out its priorities in four quadrants and placing an emphasis on businesses over consumers and analytics over engagement.

The company has been steadily moving to monetize its product and become more brand-friendly this summer, so this support for business-oriented apps make sense.

The new products include companies that let brands manage their Twitter accounts (Shoutlet, Spredfast and Sprout Social), help marketers understand Twitter activity (Adobe Social), help brands create tweets that work with their audience (Percolate and Rallyverse), and help companies measure reactions and activity by users on Twitter (Sysomos, Simply Measured and Visible Technologies).

This summer, Twitter divvied up developers and their apps into four quadrants on a Twitter chart of approval, showing which ones Twitter likes and which ones it will discourage (aka the upper-right quadrant of doom). So the new additions are a good reminder — analytics and marketing apps built for businesses are in a good place.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Sector RoadMap: Social customer service in 2013
• NewNet Q4: Platform mania and social commerce shakeout
• NewNet Q4: Platform mania and social commerce shakeout

The post, published Tuesday, details the evolution of the fundraising platform from a hosted service provided by Blue State Digital to a redundant, dual-platform API that had the lowest latency possible. Rush, who was the deputy director of front end web development at Obama for America, lays out how the six engineers working on the fundraising side created a web-based API for accepting donations for the Obama campaign in early 2012. The goals of the team were to make sure the API was always available (when a platform can take in $3 million in donations in a single hour, downtime is pricey), that it scaled and that it was fast, since millisecond delays make people second-guess their decision to spend/give money.

Rush detailed how the team used Amazon EC2, Akamai and its own hosted platform with a REST-based API on top of that. Anyone who wanted to access the API had redundant options and Akamai chose the fastest route as well as lowered latency. From Rush’s post:

To ensure that the platform was as stable as possible we worked with backend engineers on the campaign’s Tech team to make the Blue State API redundant. The Tech engineers built out a duplicate payment processor/API and hosted it on Amazon EC2 (itself redundant across data centers). At this point we had two APIs that we could switch between if one went down, but our Devops team had a great solution to make this automatic. They sprinkled a little Akamai magic and we had an Akamai health check which would automatically divert traffic to one API or the other based on the health check. By the time this was fully functional there was not a single moment in time that our new platform was not able to accept donations.

For more on the campaigns use of tech read Rush’s post, or check out the post by my colleague Derrick Harris on how the Obama team used tech as a “force multiplier,” to help win the election. It’s a good reminder that politics has transitioned from TV soundbites to scaled out web infrastructure and the cloud.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Cloud computing infrastructure: 2012 and beyond
• Infrastructure Q1: Cloud and big data woo enterprises
• AWS Storage Gateway jolts cloud-storage ecosystem

Demand for this improved information flow had major players like SAP, Siebel and Oracle supplying a market with enterprise applications – which would need huge amounts of manpower and resources to be customized to suit the needs of a particular business. Applications grew to become suites of applications, with vendors aiming to provide a one-stop shop for every need. The original premise was that implementation of these application suites would typically occur over the course of years and run into the millions of dollars.

Then the cloud came along and changed everything. Now, the competitive advantage belongs to companies that find newer efficiencies through tightly integrated SaaS applications– and in the process uncover new opportunities. It’s this idea that inspired me to found MuleSoft, which is now the most widely used integration platform for connecting SaaS and enterprise applications in the cloud and on-premise.

SaaS disintegrated the application suite

Software as a Service (SaaS) has quickly blossomed and become the fastest-growing software market ever. Forrester estimates that by 2020 the SaaS market will hit $125 billion in global revenue, with 2012 projected to hit $20 billion. The appeal of SaaS is clear: With its attractive economics and frictionless deployment, its impact on the way enterprises now operate is immeasurable.

SaaS completely disrupts acquisition and maintenance models for enterprise applications. It offers fast implementation with little to no need for customization. SaaS applications are managed to a Service Level Agreement (SLA) by the vendor, which removes the costs of maintaining hardware and software in a data center, as well as the cyclical upgrade burden. Furthermore, SaaS applications tend to be more robust, since thousands of customers battle-test the platform every day.

SaaS offerings tend to be targeted at specific business problems. This disintegrates the traditional enterprise stack and means customers are no longer purchasing entire application suites. Instead, enterprise customers are able to pick and choose and then subscribe to best-of-breed point solutions for CRM, ERP, marketing automation, talent management, expense management and many more. Each of these point offerings look pretty much the same for every customer.

Traditionally, integration has been the pain point for getting siloed applications to work together. With SaaS, this pain can be amplified since there are potentially many more applications to integrate. Say a company needs its Salesforce CRM talking to its Workday ERP, and the SuccessFactors Talent Management system integrated with payroll and ERP, as well as Marketing automation and eCommerce applications talking to its CRM. Things get complex fast, and the number of integration points multiplies the more applications you need to connect.

APIs and the integration challenge

The advent of APIs for SaaS has revolutionized the way organizations can connect applications together and create new business models. With SaaS, you can pick and choose individual SaaS applications to run your business, connecting them together through their APIs. But even with APIs, each application is still different, which creates a challenge in finding a bridge to get the applications working together. (So, for instance, while SalesForce CRM and Workday ERP both have an API, they don’t know how to talk to each other.) Typically, integration needs to synchronize information between two or more applications, providing data transformation, security, reliability, visibility and error handling. Ideally this all happens in real-time so that your applications don’t get out of sync and users are always working with the most up-to-date information.

To further complicate matters, most organizations will have on-premise applications but want to adopt SaaS where it makes sense. To realize the benefits of SaaS without disrupting IT infrastructure calls for a new type of integration approach: one that enables connectivity on-premise, or cloud for SaaS and traditional on-premise applications.

Getting ahead of the competition

SaaS levels the playing field, theoretically giving all companies access to the same applications and tools. The atomization of enterprise applications means that companies can pick and choose the best applications for their needs rather than settling for ‘good enough’ application suites as before. Thus the enterprises that figure out how to make SaaS part of their application landscape will be best able to compete. The rest will be outpaced by the newcomers that understand how to integrate SaaS applications to build new business models, grabbing competitive advantage.

For this to be possible companies need an integration platform that provides connectivity for all their applications whether it be SaaS applications such as Salesforce.com, NetSuite, or Workday; or on-premise such as SAP, Microsoft and Oracle. But its not just about connectivity, its about reliability and agility.  The connections between your applications need to be working silently in the background. You need analytical visibility to the information running through your applications to help tune your business and discover new insights. And you need to be able to respond quickly to changes in your business model, processes and applications.

In short, your company’s competitive advantage is no longer in the applications you use, it’s in the platform you choose to connect them with.

Ross Mason is the founder and CTO of MuleSoft.

Photo courtesy of Shutterstock/Andrea Michele Piacquadio.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• How to Make Cloud Computing Greener
• How HR can make the case for workforce analytics
• Cloud computing 2012: a pessimist’s guide

When Twitter first released its new API rules in August — and changed what had been guidelines into hard-and-fast requirements about the way tweets are displayed, among other things — the company specifically said that Storify was an example of a service that added value to Twitter in a useful way, and therefore wasn’t at risk of being shut down or restricted like some other applications. Although the infamous “quadrant of death” graph that was published around this time made it seem as though Storify could be caught by the new restrictions, director of platform Ryan Sarver said that Storify was safe.

When I dropped in on co-founders Burt Herman and Xavier Damman recently in San Francisco and asked them about the potential for future conflict with Twitter, they said they were happy that the company had highlighted them as adding value, but both still seemed somewhat uneasy about the future — although Damman’s earlier response to a similar question (asked on Twitter, of course) shows that he sees any competition from the company as a challenge rather than a disaster:

@mathewi we can’t wait. Ask @foursquare what they think of @facebook entering the check-in space. It can only make us stronger. #ona12

—
Xavier Damman (@xdamman) September 22, 2012

Trying to become less reliant on Twitter’s API

I asked Herman about both of these potential issues in a follow-up phone interview — an audio recording of which is embedded below — and he said Storify believes that it is doing something very different from what Twitter might do if and when it offers curation tools, and that it is also about much more than just a way to curate tweets. Herman also said that the company is working on making it easier for users to pull in tweets without having to go through the Twitter API, and that it sees tweets as public information it should be able to gather however it wants to:

“It’s certainly Twitter’s right to do what they want to with their API, and so the more sustainable solution for a company is to figure out ways of doing what they need without using the Twitter API… We don’t want to be reliant on anybody — we want to be the place where you can collect public quotes from any service on the web [so] we’re hoping to make that easier and at the same time not be dependent on anyone’s API.”

That kind of reluctance to integrate too much with Twitter is probably the single biggest negative outcome from the company’s recent changes. For startups like Storify, deciding where to focus their energy is an important task, and the uncertainty around what Twitter might do in the future makes it difficult to know how to proceed. If it could change its mind so suddenly about which apps or services it should support, what would stop it from doing so again?

So one risk for Storify is the potential for unknown future changes to Twitter’s API rules that would leave the service — and its users — hanging, and force the company to either turn off some features or restructure the way it does things in order to get onside.

Storify wants to curate more than just Twitter

A related issue is that Twitter CEO Dick Costolo has talked about how the company wants to offer journalists and media organizations tools that will help them curate tweets more easily, the way that Twitter has been doing for its media partners during official events such as the Summer Olympics or the federal election. That sounds an awful lot like what Storify does. But Herman says he isn’t concerned:

“We’re not just tied to Twitter — we really want to be a curation tool for all of the social web, and that includes Instagram and Facebook and Tumblr and YouTube and Flickr and Vimeo and whatever else comes along… it is true that Twitter is a great source of real-time information, but there’s definitely more out there.”

Herman also noted that Twitter’s recent attempts at curation for specific events such as the Summer Olympics and NASCAR seemed to be more devoted to a real-time or social TV experience, and that Storify sees a big part of its value as being the ability to highlight content after an event. “We’re used for real time too, but we’re also about being a record of something that is lasting, not just a reaction in the moment,” he said. “So these are the best things people are saying or photos that are being posted about the topic — things that stand for more than just the second you happen to glance by.”

The Storify founder said that a large proportion of the content within the service still comes from Twitter — perhaps in part because tweets are so short that it’s easy to include a lot of them in a Storify module, whereas people likely wouldn’t include dozens of videos or photos. But it’s also true that the real-time nature of the Twitter stream and the speed with which it flows by is one of the main reasons why curation tools like Storify are so necessary, and that makes it feel as though the two services are joined at the hip. Whether Herman and Damman can successfully separate them remains to be seen.

Post and thumbnail images courtesy of Flickr user Umberto Salvagnin

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Sector RoadMap: Content personalization in 2013
• Frenemy mine: The pros and cons of social partnerships for online media companies
• Social media in Q1: commerce and discovery dominated