I don't feel confused about AR SDKs but I wonder if some of those who are releasing new so-called AR SDKs have neglected to study the AR ecosystem. In my depiction of the Augmented Reality ecosystem, the "Packaging" segment is at the center, between delivery and three other important segments.
Packaging companies are those that provide tools and services to produce AR-enriched experiences. Think of it this way: when content has been "processed" through the packaging segment, a user who has the right sensors detecting its context receives ("experiences") that content in context, or more specifically, in "camera view" (i.e., visually inserted over the physical world), as an "auditory" enrichment (i.e., a sound is produced for the user at a specific location or context) or "haptic" enrichment (i.e., the user feels something on their body when a sensor connects with some published augmentation that sends a signal to the user). That's all AR in a nutshell.
In the packaging segment we find many sub-segments. This includes at least the AR SDK and toolkit providers, the Web-hosted content publishing platforms and the developers that provide professional services to content owners, brands and merchants (often represented by their appointed agencies).
Everyone, regardless of the segment, is searching for a business model that will work for Augmented Reality in the long run. In order for value (defined for the moment as "something for which you either pay attention to or pay money for use") to flow through an ecosystem segment it's simple: you must have those that are buying-with their time or their money-and those who sell to the buyers. With the packaging segment in the middle, the likelihood is high that things that matter in the long run, that generate revenues, will involve this segment.
The providers of software development tools for producing AR-enriched experiences (aka AR SDKs) all have the same goal (whether they announce it or not). The "game" today, while exploring all possible revenue streams, is get the maximum number of developers on your platform. If you have more developers, you might get the maximum number of projects executed on/with your platform. It's the number of projects (or augmentations) that's the real metric that matters most. The SDK providers reach for this goal by attracting developers to their tools (directly or indirectly, using contests and other strategies) and/or by doing projects with content providers themselves (and thus competing with the developers). Cutting the developer segment out is not scalable and cannibalizing your buyers is not recommended either, but those are separate subjects.
For some purposes, and since it drives the use of their products, packaging companies rely on and frequently partner with the providers of enabling technologies, the segment represented in the lower left corner of the figure. More about that below.
Since we are in the early days and no one is confident about what will work, virtually all the packaging segment players have multiple products or a mix of products and services to offer. They use/trade technologies among themselves and are generally searching for new business models. And the enabling technology providers get in the mix as well.
The assumption is that if a company is using an SDK, they are somehow "locked in" and the provider will be able to charge for something in the future, or that, if you are a hardware provider, your chips will have an advantage accelerating experiences developed with your SDK. If manufacturers of devices learn that experiences produced using a very popular SDK are always accelerated with a certain chipset, they might sell more devices, hence order more of these chips, or pay a premium for them. This logic probably holds true as long as there aren't standards or open source alternatives to a proprietary SDK.
Let's step back to a few years ago when AR SDKs were licensed on an annual or project basis to developers. The revenue from licensing SDKs to third party developers on a project basis is the business model that was a primary revenue generator for computer vision-based SDK provider AR Toolworks, and annual licensing was relatively successful for the two largest companies (in terms of AR-driven revenues pre-2010), Total Immersion and metaio. These were also the largest revenue generating models for over a dozen other less well-known companies until mid-2011. That's approximately when a "simple" annual or per-project licensing model was washed away, primarily by Qualcomm.
Although it is first an enabling technology provider (blue segment), Qualcomm released its computer vision-based SDK, Vuforia, with a royalty- and cost-free license in last days of 2010 and more widely in early 2011. To compound the issue, Aurasma (an activity of Hewlett Packard since the Q32011 HP acquisition of Autonomy) came out in April 2011 with their no-cost SDK. Qualcomm and Aurasma aren't the first ones to do this. No one ever talks about it any more, but Nokia Point & Find (officially launched in April 2009 after a long closed beta) was the pre-smartphone era (Symbian) version. It contained and exposed via APIs all the various (visual) search capabilities within Nokia and was released as a service platform/SDK. This didn't catch on for a variety of reasons.
So, where are we? Still unclear on why there are so many AR SDKs, or companies that say they offer them.
AR SDKs are easily and frequently confused with Visual Search SDKs. Visual Search SDKs permit a developer to use algorithms that match what's in the camera's view with images on which the algorithm was "trained," a machine learning term for processing an image or a frame of video and extracting/storing natural features in a unique arrangement (a pattern) which, when detected again in the same or a similar arrangement will produce a match. A Visual Search SDK leaves what happens after the match up to the developer. A match could bring up a Web page, like a match in a QR code scanner does. Or it could produce an AR-enriched experience.
Therefore, Visual Search can be used by and is frequently part of an AR SDK. Many small companies are providing "just" the Visual Search SDKs: kooaba, Mobile Acuity, String Labs, Olaworks, milpix, eVision among others. And apparently there's still room for innovation here. Catchoom, a Telefonica I&D spin-off that's going to launch at ARE2012, is providing the Visual Search for junaio and Layar's Vision experiences.
Another newcomer that sounds like it is aiming for the same space that Catchoom has in its cross hairs (provides "visual search for brands") is Serge Media Corporation, a company founded (according to its press release) by three tech industry veterans and funded by a Luxembourg-based consortium. The company introduced the SergeSDK. Here's where the use of language is fuzzy and the confusion is clear. The SergeSDK Web page says that Aurasma is a partner. Well, maybe HP is where they are getting the deep pockets for the $1M prize for the best application developed using their SDK! If Aurasma is the provider of the visual search engine, then the SergeSDK is actually only a search "carousel" that appears at the top of the application. Sounds like a case where Aurasma is going to get more developers using its engine.
Hard to say how well this will work in the long run, or over just the next year. There are few pockets deeper than those of Google and Apple when it comes to Visual Search (and AR). These companies have repeatedly demonstrated that they have been incubating the technologies and big plans are in store for us.
All right. Let's summarize. By comparison with other segments, the packaging segment of the AR ecosystem is a high risk zone. It will either completely disappear or explode. That's why there are so many players and everyone wants to get in the action!
Stayed tuned as in the next 6 months this segment undergoes the most rapid and unpredictable changes when Google and Apple make their entries.