I knew it then. Damn I didn’t say.

As I said in an earlier post, the folks as Programmableweb.com announced the that the number of open APIs they track reached an unbelievable number—4000—in record time.

The published this graph showing the hockey stick growth rate:

Figure 1—Total Number of APIs

source: Programmableweb

So lets take quick look at the dynamics of this growth rate.

Phil Windley helped me out and here is what we came up with.

The data could be interpreted as a power law.

Phil  used this: http://zunzun.com/Equation/2/Power/Power%20A%20Modified/

Here’s the data:

0, 0
8.5, 1000
10.5, 2000
11.25, 3000
11.75, 4000

Power law says:     Y = aX^b

The fit says

a = 13.665
b = 1.618

So, by the year 2013, (X = 13), we’d expect: 7117.

2016 shows 30,000 APIs.

This is a nice steep curve.

Figure 2—Extrapolating the Numbers

source: Craig Burton and Phil Windley

But I am going to go out on a limb and predict that something even more dynamic is in play. If you look at Figure 3, you can see that somewhere between Oct. and Nov. 2010, the growth Netflix was enjoying took a serious turn for the better. Hits on the API went from 4 billion a month to 12 billion in 30 days.

Figure 3—Growth of Netflix API

source: Programmableweb

If I am right, I expect that we hit the 5000 API mark sometime in mid 2012. Then instead of just going on the power curve to 7117 APIs by 2013, the industry will experience an exponential skip—like the one in figure 3 for Netflix—the jump will go from 5,000 to over 10,000 almost over night. So that we will be way ahead of this ambitious curve shown in Figure 2.

I have no real data to support that. I just think the movement is about to jump the chasm from early adopters to early majority sometime in 2012.

Whatchout.

Intro

Provocative quotes:

Baking your core competency into an open API is a economic imperative.

source: Craig Burton

If you are not engaged in generating or enabling open API’s for your business—you are not in the game.

source: Craig Burton

Social—, Mobile—, and Cloud-computing are hot. The API computing magic troika is white hot.

source: Craig Burton

Ubiquitineurs don’t litigate or file for patents. Litigation and patents are the tools of the purveyors of scarcity.

Source: Craig Burton

I talk to my buddy and visionary Doc Searls almost everyday. He is busy writing his new book about the Intention Economy: When Customers Take Charge. The book is the long expected follow up on his first co-authored work: The Cluetrain Manifesto.

While we talk, we often riff on ideas and things we have read or heard. We have been doing this now off and on for twenty years so we have a language and process that lets us get right to the meat of things quickly. It’s fun. When Doc gets on a rant I just shut up and listen. It’s like listening to Stevie Ray Vaughn riff with words.

One more thing: This post is the first instance of a new term. The term is Ubiquitineur. The definition of ubiquitineur is: Ubiquitineur—An entrepreneur whose business and innovation practices are ubiquity-based as opposed to scarcity-based.

The API Computing Magic Troika

Here is my point.

We are riffing on three core things that make the Intention Economy work. Surprisingly one of them isn’t social computing. They are:

1. Cloud-based code (Code platforms like Kynetx that are API and cloud-centric).
2. Cheap telephony-data (Affordable mobile—telephony data pricing like Ting.com provides)
3. Personal Data Technology(cloud-based stores that are controlled by the individual. Singly is promising such a thing, Cloudmine.me has one up in beta.)

Cloud-based Code

Here is why Kynetx (or possibly other cloud/API-centric code platform) rocks for the Intention Economy rapid prototyping and apps.

1. Runs in the cloud.
2. Has built in constructs for managing developer keys.
3. Late-binding is intrinsic
4. Loosely-coupled is explicit
5. Built in support for OAuth 1.o and 2.0.
6. Event-driven
7. JSON and JSON Path-centric
8. Much more but you get the point.

Traditional languages are playing catch-up to this. (I like the precepts of the new Dart language spec from Google. It needs to be evented though. Plus is doesn’t have key management as an intrinsic.)

Cheap Telephony Services

Current telcos are ripping us off for data access. Competition and common sense ( of which little is found in telcos today) will change this. For example look at what Ting.com is doing with providing no frills pay as you go telephony services over the Sprint Network.

Mobile device data access is fundamental to the Intention Economy.

Personal Data Technology

This a new category of technology that is just emerging. Call the personal data ecosystem, or personal data store or architecture, whatever, the point is a place in the cloud where you can store and control information about you.

There are a lot of players emerging in this space. The two I am going to mention are Jeremie Miller’s Singly.com project and the Cloudmine.me service.

To be honest I haven’t used either of them yet, but the precepts in Jeremie’s vision are spot on plus he has gathered an all star group that are likely to do something that will either rock or give us much to think about if it tanks.

I will be playing with the Cloudmine stuff shortly and let you know what I think. So far I like everything there. The one exception is their terms of service. It doesn’t really effect me, but I think they are missing out on the benefits of clear ubiquity-based thinking when the contractually prevent anyone from creating a compatible service.

Soap box rant

This is specifically to the Cloudmine folks but it applies to anybody. If you get enough inertia to attract someone interested enough to start copying your protocol, rejoice—things are good. Litigation is not your friend. Litigation is the tool of the purveyors of scarcity. Protectionism is contrary to what you are trying to accomplish. It is contrary to the laws of ubiquity. You have an alignment problem there. Ubiquitineurs don’t litigate or register for patents.

The API Economy

The API Economy is not something that is going to happen. We are already in full swing.

Look at the numbers published by  the folks at the Programmableweb earlier this month when they hit the 4000 API mark.

source:Programmableweb

Summary

Get with it. Figure out your API strategy. Understand the API Economy Troika and how it relates to what you are doing.

What more point. If you don’t know by know I will end with another quote that is not so provocative and should be obvious:

Digital Identity is core  to all this stuff.

source: Craig Burton.

Jeremy Miller is busy working on his new project that is a personal data store and so much more.

Take a look at this video of his talk last week at Web 2.0 Summit.

I like the vision. I don’t agree that API’s are not the way to do things. I do agree that most API’s come with a Terms of Service.

There are some that don’t this is going to be a continuing trend.

ListenLog from PRX, for example, is a log of  your listening using the iPhone Public Radio App. There is no terms of service. It is your log. You can do with it whatever you want with no restrictions.

Check out the EmanciPay app that Doc Searls and I cooked up with the ListenLog.

At the Internet Identity Workshop #12, Doc Searls and I concluded that a prototype VRM application was in order. We decided to collaborate and build a prototype For IIW #13 (October 18-20). You can still register. We decided that leveraging the ListenLog feature of the iPhone Public Radio app would be cool. We finished the prototype and we will be presenting it next week at IIW in Mountain View.

Here is how it works. Anybody who as the Public Radio iPhone app from PRX not only gets 500+ public radio stations and 1000+ programs, but they can generate something called a ListenLog. The ListenLog is your personal chronological log of your public radio app listening. Access to the log is not public unless you publish your ListenLog URL. It also cannot be controlled or managed by anyone but the owner of the log.

When ListenLog is enabled, every time you listen to a station or program, a log entry is created and stored in your ListenLog. This is a fabulous mechanism to have and a harbinger of great things that could happen. Indeed the ListenLog is the impetus and beginnings of the Personal Data Store trend that is currently underway. IIW #13 is slated to have significant movement in the Personal Data Store space.

The PRX  people even went a bit further to give individuals confidence that the ListenLog data was not going to be exploited. The ListenLog is hosted by the Berkman Center at Harvard and is not controlled by any individual or organization. Neither PRX or anyone else can use the ListenLog to track your behavior and target you to sell you something. I like that. Thanks to Keith Hopper for making the ListenLog happen and keeping the VRM vision in its implementation.

The ListenLog has a simple RESTful interface that can return the log data in either XML or JSON formats. I can deal with that. The design could be better with more attention paid to the access

Since Kynetx is such a great platform to integrate multiple data sources and create an interesting mashup very quickly, we decide KRL (Kynetx Rules Language) would be our development language the KNS (Kynetx Network Services) our platform. I am not a programmer, so the simplicity of KRL also made it possible for me to not only design the prototype but to implement and test things.

Just think, with the players involved with this prototype I have Doc Searls and Phil Windley (two of the founders of IIW) involved  prototyping an app that highlights both of their core passions—VRM and the Live Web. The only thing that could have made it cooler is if PRX had taken the time to change the API to ListenLog to be an Evented API. (But I digress.)

In this prototype, I use KRL to pull all of the services needed to make things work from the ListenLog for the log data, Twilio for the telephony and SMS parts, Pachube for the logging and graph generating, Twitter for tweeting, and WordPress for the website.

Here is the program flow diagram.

The prototype  uses Doc’s ListenLog data and the tweets are also posted by him (or at least by KRL using @dsearls).

As the diagram shows, when Doc sends a text message to the designated EmanciPay phone number (purchased from Twilio), KRL takes queries Doc’s ListenLog to see what he was listening to last. KRL assumes that the last thing being listened to is what should receive the contribution.

KRL then fetches the last program being listed to and then posts the amount, the program and radio station to Pachube.

I then use KRL to automatically tweet the event to Doc’s twitter feed.

Finally, I pasted a link to the graph created by Pachube for the daily contributions on a WordPress site at Emancify.com.

The ProjectVRM wiki also documents this little venture.

Here is the source  code in KRL for the app. Note the the source code is saved as a JavaScript file but it is not JavaScript, it is Kynetx KRL. I use the JavaScript extension (.js) so that github can provide some formatting to improve legibility.

Let me know if there are questions or suggestions for improvement.

I subscribe to the ProjectVRM mailing list. Every now and then, a raging debate comes up as to why the term VRM needs to be changed. The arguments are passionate, eloquent and irrelevant.

The term VRM is immutable.
No amount of logic or reasoning will change that.
You cannot change the term. The best you could hope for is to fork the term.
A forked term has been diffused.
The term VRM will never go away.
This makes any attempt to change the term VRM to something else a complete and total waste of time.
It is simply economically and technologically prohibitive.

Here is why.

When an idea like VRM comes into being and gets posted on the web, the second another person repeats the term or creates a link to the reference, it begins a life of its own and gains what is termed as “web equity.”

The more use, links, callbacks and references to VRM, the more equity it gains. The more equity it gains, the more immutable it becomes.

A simple but probably conservative measurement of web equity can be found by googling a term.

A VRM search yields more than 8.5 million hits.

Probably even more important, the first hit a VRM search is ProjectVRM.

It is economically and technically impossible to eradicate 8.5 million references to VRM.

The cost to ProjectVRM to change the term would be astronomical in terms of dollars and momentum.

As I said, the discussion of changing the term is a complete and total waste of time.

There are thousands of companies and projects that can only dream of obtaining the web equity VRM has. Instead of discussing how to destroy this hard fought equity, start thinking about how to leverage the web equity of VRM.

Gaining ubiquity with technology is hard.

The Yin and Yang of the whole thing makes it that way. If you force it, it will fail. If you back off and leave it, it fails. You can tease, cajole, blarney, wheedle,  sweet-talk, seduce, inveigle, palaver, coax, and seduce. Sometimes nothing you can do or wish to have happen can move you any closer to ubiquity.

Despite that, I have designed a guideline—six basic steps—that under the right timing and leadership seems to work. I have also found that if you don’t follow these steps, failure is likely.

When engaged in the in the process to produce ubiquitous movement, use the following guidelines.

1. Idea
2. Discourse
3. Understanding
4. Agreement
5. Movement
6. Ubiquity

If it is ubiquity you are after, take the time to consider these six steps. Make an honest assessment of where things are. It is almost impossible to skip any of these steps. Once you have an idea of where you really are, finish that step rigorously and thoroughly before you move on to the next step.

Try using your left hand.

I am the same age as Steve Jobs.

So when Phil Windley sent me the link to the 1985 Playboy Magazine interview of Steve Jobs (just before he was forced to leave Apple) I had to laugh at some of the questions made by the interviewer and remember all of the things that where going on in the industry then.

During the 80’s I worked for Ray Noorda at Novell. My job was to create and drive Novell’s strategy. The plan was simple, give real freedom of choice to the customer and be interoperable with as many networks and computers as possible.

By 1985 Noorda was finally coming around to the freedom of choice thing. But I had a hard time convincing Ray that the Macintosh was an imperative to support with NetWare. And he had good reasons to balk at my insistence.

Apple was notoriously difficult then—as now—to work with.  Especially when Jobs was at the helm. At times it seemed that Apple’s strategy was just the opposite of Novell’s. Don’t give any choice to the customer except to buy Apple. Interoperability? Never heard of it. Freedom of choice was something Jobs then—and still lives on at Apple now—resisted at every opportunity.

The operating system, the mother board, the bus, the network, the transport, you name it. Apple built their own and was slow to adopt anything that any other vendor supported or invented.

It seems that the only time Apple breaks down and supports any standard is when it is forced to do so. That’s how it was then at Apple, and that’s how it continues to be at Apple. All designed and driven by Jobs.

I doubt Novell would have had Apple attend the rollout of Macintosh support in NetWare if Jobs had been CEO when it happened. Of course having John Scully at the event made it less than stellar, but at least it happened. And the world business community loved it.

When I read the sections of the interview that talk about Apple’s struggle to get a foothold in corporate computing environments it reminds me just how big of a role Novell played in making that happen. Both Apple and Microsoft seemed to revel in the fact that their systems were not interoperable. Novell solved the namespace and interoperability issues between the Macintosh and DOS (and later Windows) in spades in spite of proactive resistance from both vendors.

It would have taken Apple another 10 years before gaining a foothold in the business community without Novell. With the bottom up approach and huge Novell channel and support network, Apple was able to slip in the back door of enterprise departments along with NetWare and the PC before corporate IT knew it or could try to stop it.

With the way things worked out—Apple being the most profitable company in the world and Novell being dead—you might conclude that the Steve Jobs approach to standards and interoperability are the way to go.

It isn’t that simple, things are much more complicated than that.

While no one can deny that Jobs was a great visionary and did incredible things for the world and computing, I can’t stop and wonder what really could have happened if Apple/Jobs had taken the approach of building sexy interoperability along with sexy computers and phones.

While attending the Cloud Identity Summit last week in Keystone Co. I noticed a usage trend that needs addressing.

Almost without exception, the discussions around identity and identity technology used two categories for defining market segments. The two categories are:

• The Consumer
• The Enterprise

These ambiguous categories are hindering moving forward with identity discussions and productivity. Every session I attended, I challenged the presenter to define these terms. Without exception, the confusion and ambiguity were rampant. For example, where are the people that don’t work for a large company defined here? They aren’t consumers, they aren’t an enterprise. Are you saying that a person at work is only recognized if they work for a large company? How large?

I don’t even want to go down the path of the Consumer word.

The Consumer

The Enterprise

As a result, I am proposing 6 alternate top level category definitions. These definitions are as follows:

• Person 
• Group  
• Organization
• Non-Profit Organization
• Government
• Program/Code

Of course there are sub categories to each of these definitions, but at least we have a set of of top level definitions that make sense.

Here are some icons I will use. Note that I use the accessory of a “hat” to distinguish the entity. This works for me, I often think of myself in a different hat depending on what role I am in.