Logs, Links, Life and Lexicon

Daily Thesis

We recently moved to Korea.

We are adapting quickly. What an adventure.

Excellent TED Talk on how the Blockchain technology will play a role in managing trust and identity.

The Thesis

Rachel Botsman is studying the defines trust as a “confident relationship to the unknown.” She is studying how technology is transforming the social glue of society.

Human beings are incredible in being able to take trust leaps.

She then introduces the concept of “climbing the trust stack.”

She then posits that we are going thru a massive change in the trust model, one from an instituionalized model to a distributed model.

She goes on to say that the blockchain technology will play a major role in how we effect digital trust. So much so, that the trust stack can be simplified, and the need for institutionalized trust intermediaries can sometimes be mitigated.

Watch the entire video. Very enlightening and provides a clear and consice explanation on how the blockchain works.

What Ms. Botsman omitted—clearly not intentionally—is the role sentiment analysis plays in the future of digital trust.

The Role of Sentiment Analysis and Trust

In the future, the ability to understand the sentiment or the “spectrum of intention” of another person or entity will be highly valuable in determining trust values.

In a recent series of blog posts by Phil Windley, the concept of a self-soveriegn identity system is introduced.

SIS purpose is just like it sounds. An independent identity system managed by users.

The series leads up to the announcement last week of Sovrin.org. (But I will get to that later.) Since these are in a series of blog posts, they are in reverse chronological order. So here they are in order.

  1. Service Integration Via a Distributed Ledger
  2. Governance for Distributed Ledgers
  3. An Internet for Identity
  4. Self-Sovereign Identity and the Legitamacy of Permissioned Ledgers

Some of these are lengthy. The topic is complicated, but fundamental to the future. Take your time. Dont let TL;DR syndrome sidetrack you.

In World of Ends, Doc Searls and
Dave Weinberger enumerate the Internet’s three virtues:

Kevin Marks

At the most recent Internet Identity Workshop (#iiw), I was watching the #iiw twitter feed. As the keybote speaker began (Kim Cameron), a barrage of insightful tweets from Kevin Marks ensued.

I looked over at Kevin Marks tapping away on his laptop. Something didn’t make sense. There was just no way the number of keystrokes he was making was matching the prodigious output of tweets.


So I aksed him how in the world he was doing that. He happily reavealed a tool for tweeting events that he and some others had developed.

Noter Live

Brilliant. Love it.

Since then, I have noticed others starting to use it with astounding results. Phil Windley.

I attended Internet Identity Workshop 22 in Mountain View last week. Fabulous conference. There is always lively discussion for experienced identity people and newbies.

Above is a shot of our beloved Doc Searls. Thanks Doc.

Everyone is interested in learning and sharing information.

This is my favorite conference to attend.

2015 has been a most difficult year for me. Lots of oppourtinity for growth. Ugh.
Robbed, evicted, and hospitalized.
To finish it, one of my dearest friends, mentor and advocate died from a staph infection last week.

On the good side, I have lost alot of weight. I feel better and am getting around much better.

Looking forward to a wild 2016.

2015-03-31 21.36.56

Sketched in Procreate on an iPad.

Writing. I find it ironic that the thing that is the hardest for me to do—write—is how I make my living.

Be careful what you ask for.

In the interest of improving my craft, I read books about writing. Writing Down the Bones: Freeing the Writer Within, How to Write a Sentence: and How to Read One, Writing White Papers: How to Capture Readers and Keep them Engaged and recently I discovered  Uncreative Writing: Managing Language in the Digital Age.

Note: I find it painfully bizarre that Kindle will not let you cut and paste text.

For the past several years, I’ve taught a class at the University of Pennsylvania called “Uncreative Writing.” In it, students are penalized for showing any shred of originality or creativity. Instead, they are rewarded for plagiarism, identity theft, reproducing papers, patch writing, sampling, plundering, and stealing. Not surprisingly, they thrive. Suddenly, what they’ve surreptitiously become expert at is brought out into the open and explored in a safe environment, reframed in terms of responsibility instead of recklessness.

Each semester for their final paper, I have them purchase a term paper from an online paper mill and sign their name to it, surely the most forbidden action in all of academia. Each student then must get up and present the paper to the class as if they wrote it themselves, defending it from attacks by the other students. What paper did they choose? Is it possible to defend something you didn’t write? Something, perhaps, you don’t agree with? Convince us. All of this, is technology-driven. When the students are writing class, they are told that they must have their laptops open and connected. And so we have a glimpse into the future.

Uncreative Writing: Managing Language in the Digital Age, Kenneth Goldsmith

I love this sort of thinking. Inspiring.


My good friend and mentor Phil Windley recently published “The Compuserve of Things“. As usual the information is well thought out and clearly articulated. It is so good I wanted to reiterate portions. Here is the summary:

On the Net today we face a choice between freedom and captivity, independence and dependence. How we build the Internet of Things has far-reaching consequences for the humans who will use—or be used by—it. Will we push forward, connecting things using forests of silos that are reminiscent the online services of the 1980’s, or will we learn the lessons of the Internet and build a true Internet of Things?

This also reminds me very much of the saying Doc Searls gave me:

Freedom of choice does not equate to choice of captor.

The way the internet is being used today, we have become numb to the process of being herded into silos of captivity. The first step to remedy this is awareness. Not always easy to resolve.

A Real Open Internet of Things

If we were really building the Internet of Things, with all that that term implies, there’d be open, decentralized, heterarchical systems at its core, just like the Internet itself. There aren’t. Sure, we’re using TCP/IP and HTTP, but we’re doing it in a way that is closed, centralized, and hierarchical with only a minimal nod to interoperability using APIs.
When we say the Internet is “open,” we’re using that as a key word for the three key concepts that underlie the Internet:

  1. Decentralization
  2. Heterarchy (what some call peer-to-peer connectivity)
  3. Interoperability

I really like these concepts. It all begins with awareness.


Pondering the real open IoT causes me to in all sorts of directions. In my next post I will explore the relationship between Bitcoin and IoT.

This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since.

It’s been a pleasure for us to work together on trying to derive a sound basis for thinking about the API Economy – but that basis isn’t very useful if it isn’t built upon. So today we’re introducing the second part of the API Economy Axioms series – a look into what the consequences of these axioms are.

We’re starting off in this post by summarizing the five axioms and from next week we’ll be covering what happens next:

  • Implications for individual organization
  • Implications for Internet and business ecosystems as a whole
  • The challenges to be faced – both technical and organizational

If you missed any of the Axiom posts, they are linked below in each section.

Summarizing the Five Axioms

In summary, the Axioms are defined as follows:

  • Axiom #1— Everything and everyone will be API-enabled: This Axiom highlights the fact that almost every network connected endpoint is becoming an API that can be invoked and read by other software systems. This transformation, when seen device-by-device or step-by-step, seems logical – perhaps even mundane. However, the point behind this Axiom is that as a macro phenomenon we are quickly accelerating into a world where almost every device and system is addressable via APIs. [Axiom 1]
  • Axiom #2— APIs are core to any cloud, social and mobile computing strategy: More concretely than Axiom 1, this Axiom describes how APIs form part of what are arguably the three most important transformational forces in the online economy today: cloud, social and mobile. It’s very clear that many of today’s innovations in these areas would be impossible without API-like architectural patterns (even if not always named APIs) and that APIs are enabling yet more of this same transformation. [Axiom 2]
  • Axiom #3 – APIs are an economic imperative.: This Axiom shows that APIs are at their core not simply a technical phenomenon, but are intrinsically linked to the creation and access to value – resulting in economic impact. This does not necessarily mean relevant APIs are “paid for services” (although some are), but in fact that almost all APIs enable, improve or scale value in ways which increase economic impact. [Axiom 3]
  • Axiom #4: Organizations must provide core competence through APIs: This Axiom zeros in on the fact that the transformation that matters most is when it’s core competence as an organization is made available as an API. In other words when APIs become drivers for core business, and enable partners and customers to engage, provision and consume that core competence in new ways. [Axiom 4]
  • Axiom #5 – Organizations must consume the core competencies of others through APIs: This Axiom is a counterpart to Axiom #4 and highlights the fact that consumption of the APIs of others is of equal importance to provision. When this consumption is of the core competences of others then this provides the strongest foundation for business partnerships. [Axiom 5]


By themselves, these Axioms can seem rather dry or disembodied – why these Axioms and not five others? While it is hard to know whether we chose the correct five building blocks they were chosen because they illustrate different dimensions of what is happening in the API Economy today:

  • Scale – Axiom #1: reaching almost every software and hardware system being deployed.
  • Momentum – Axiom #2: underpinning huge global transformative trends.
  • Economic impact – Axiom #3: moving from a technical phenomenon to a business essential.
  • Imperative to provide –Axiom #4: demonstrating the impulse to offer APIs.
  • Imperative to consume – Axiom #5: closing the loop on provider – consumer relationships for services.

But, the proof in the pudding is whether or not, these Axioms allow us to say something about how we think the API Economy will evolve, change and impact business.

This is the subject of the next set of posts we have queued up – we’re looking forward to people’s thoughts on both the Axioms and what we can derive from them!


This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since.

Having stated the Axioms in previous posts, a number of big picture questions arise: beyond how they are related to individual organizations, what effect do they have on the evolution of the web and the economy as a whole? What challenges are there in making the API Economy a reality?

The first post covered implications the Axioms have for individual organizations. In this second post, we cover implications for the market in general, the API providers, consumers and infrastructure organizations.

To look at this, it’s helpful to think in terms of what the axioms imply and what can be derived from them for the technology market in general:

  • Axioms #1, #2, #4 and also the arguments in the previous post on the imperatives for individual organizations to become API providers, show there is very clear pressure for more organizations to open APIs — both to smaller selected groups of partners and to the wider world. The value of each API is initially in the ecosystem built around the API and this is already sufficient to push many organizations over the edge. One of the important byproducts of this is also to increase the supply of APIs available in the economy — essentially each launch creates a new building block for others to use.
  • Via Axiom #5, there is huge benefit in consuming the APIs provided by others — often the organizations providing them offer specialist services of very high grade which would be impossible to replicate internally. Not using these often results in significant loss of competitive advantage. This fact creates clear demand pull for available APIs and further, leads some organizations to go as far as asking their existing partners and suppliers for access to API capabilities.
  • As the economic imperative plays out (Axiom #3), organizations are naturally drawn to want to exploit these opportunities for increasing gain: providers to reach a greater audience with their offering and API consumers seeking increased benefits from external services.

So, one can think of the API Economy emerging initially as a series of strong individual ecosystems around valuable individual APIs — each of which has its own growing customer or partner user base. However, over time more and more APIs emerge, and those API consumers getting benefit in one place begin to demand it elsewhere.

This dynamic implies a “positive feedback loop” between new APIs becoming available, new API consumers and increased API consumer pull — an autocatalytic chain. The growth of new APIs is the driver for new API consumption and vice versa. The question is – what are the signs that this interconnectivity is emerging and acting as a loop?

We first look at the API supply-side, then the demand-side and finally end with some thoughts about the feedback loop.

Supply-Side Dynamics

There are some excellent API programs we can examine that can be examples for how all providers should design their programs (Twilio, Sendgrid, Stripe, NPR, Twitter, Facebook for example) and they have gone on to build huge audiences. As a result, all of these organizations have large and successful developer programs with a significant number of apps and services that use their APIs.

The ultimate objective of any API program is to garner a relevant group of developers that use the provider’s APIs. Each API Program – whether tailored to the broader public, customers or close partners creates its own community of value, as illustrated in the Figure 1 (Source ProgrammableWeb):

web growth

Figure 1—API Growth                                                               Source:ProgrammableWeb

In Amazon’s case, APIs spurred both internal innovation, resulted in a large network of resellers, power their own mobile devices, and added a whole new line of business. The API layers built by the company are now an intrinsic part of their business.

Once a customer/partner community is within this particular orbit, they are able to plug into existing services. However, Amazon has also added new services over time to serve more demand. For example:

  • Amazon Redshift—distributed hosted data warehouse services
  • Amazon Route 53—highly available DNS services

Similarly, many other organizations extend the functionality of their APIs over time – Paypal, Twitter and more. In some cases functionality is also restricted over time as business models change.

As we have noted in previous posts, an interesting dynamic occurring in the industry is as more new and traditional vendors are jumping into the game with solid API programs, this stimulates interest in partners, competitors and other constituents to do the same:

  • Walgreens was one of the first retailers to open an API, many other retailers have since done the same.
  • USA Today and the New York Times were very early in the media field — many other news and content organizations have since followed.

The result is impressive annual growth in the number of APIs — both public and private. The number of APIs now listed on ProgrammableWeb is now approaching 14,000.

Demand-Side Dynamics

The other dynamic regulating the growth of the economy feedback loop are the dynamics occurring in the consumption of APIs and mashups of APIs from all sorts of organizations and independent groups and developers. Some of these dynamics are recognized in the following ways:

  • Each of the APIs has its own user base,
  • Each user of the API is deriving value from the APIs,
  • Many API consumers use more than one API.

As an indicator of developer engagement, the number of developers using APIs is continuously rising — 3Scale now has 150,000 developers using the APIs it powers as does Mashery. While there is likely overlap in these populations, there is strong regular growth in developer numbers.

It is a little harder to measure demand-side pull for new APIs. Anecdotally however:

  • Quora regularly surfaces questions of the form “Does X have an API?” — Recent examples for X include WhatsApp, Uber, Square, ZocDoc, Viber, Qwiki and Quora itself.
  • Many of the organizations working on new API programs also cite customer and partner demand as a major reason for opening a program.

In sharing the first API Economy axiom with a close friend and programmer we received his response that brought up some relevant questions:

“Maybe this will be covered in later axioms, or maybe it isn’t appropriately part of the axioms, but this is my gut reaction as an old programmer when I read about the API Economy: ‘Gaaaah!!! It’s hard enough keep track of the few hundred APIs in the Windows SDK and the handful of web libraries I use now. So now I’m supposed to be able to use potentially billions of APIs for every service, company, platform, and potentially every user on the internet? Who will document all those APIs? Who will test them? Will there be meaningful version control so I know when something changes? Will there be any consistency in syntax, performance and data usage? I think I should have listened to my Dad and gone to law school’.”

As this programmer asks, what about version control and search? Many organizations use Github to present their APIs to API consumers to address this.. Indeed Github has its own set of APIs to automate this process. Kin Lane—API Evangelist—gives a great example of a coder that instinctively figures out how to make this happen on his own (the post is here.)

There is much done, and much more to be done on the consumer side of the dynamics of the API Economy.

With some exceptions, todays APIs are individual silos that are focused on interacting with just the constituents of a specific organization. They are islands of functionality – the question is, will these islands join up into a coherent “economy”?

A Feedback Loop And A True “Economy”—Distributing, Managing, Monetizing And Aggregating The API Economy

Each API grows its own user-base over time but there are often overlaps in the mesh of APIs and certain API providers with together — for example Twilio, Sendgrid and a number of others often participate in hackathons together. There is also clear API consumer demand being expressed.

The question is, are these individual islands driving and feeding each other enough to create a big enough loop to generate autocatalytic growth?

The answer is — yes. There are clear signs that this supply-demand loop is acting, accelerating, and at the same time causing acceleration of growth in the creation of API programs. Further, there are also clear signs that while the API landscape is still a patchwork of ecosystems and technologies, there are structures emerging that are beginning to cut down the friction and create more connectivity. At the most fundamental level, there is clear cross-pollination between API programs:

  • API consumers of one type actively demand and subsequently use APIs in other areas
  • Organizations that see competitors provide and consume open APIs are driven to follow
  • Technology best practices are increasingly being re-used across APIs so developers are less often faced with unfamiliar design patterns.

These are now being reinforced by a wide range of fledgling activities which act to glue activities that when combined together reduce the “friction” in any economy:

  • Conferences: A number of API conferences have now sprung up from the API Strategy & Practice Conference to APIDays, Nordic APIs, API World, iLoveAPIs and APIcon as well as Gluecon which cover APIs often and early. These and smaller technical events like RESTFest and API-Craft do much to share best practice and encourage technical development.
  • Best practice blog posts and books: A large amount of blog materials, video, presentation and other content is now available to share how to achieve things with APIs – both from technical and business perspectives. Efforts such as APICodex (by 3scale) and APIAcademy (by Layer7) help categorize and track the best of this content.
  • Analyst reports: all major analyst groups and most subgroups are proactively monitoring and reporting on the API economy.
  • Directories, discovery and search: A fundamental element of a genuine economy is the ability to find APIs to use – ProgrammableWeb was an early pioneer in this respect, acting as a directory for open APIs, Mashape plays a similar role and APIs.io is attempting to add a search engine style approach.
  • Tools for API providers and consumers: The technology for deploying and managing APIs was complex and unwieldy early on – however companies such as 3scale, Intel-Mashery, Apigee now provide tools which make it easier for providers to get into the game. On the consumer side, the toolset is also increasing with tools such as APItools, Runscope, oAuth.io, APIMetrics, SoapUI making API testing and usage much easier.
  • Ratings and Trust: A problem that arises as an economy grows is knowing which APIs to trust and api500 is a first attempt in that direction.
  • Aggregators: The emergence of aggregator APIs which wrap other APIs are also another sign of structure being added that connects individual APIs – examples include Newscred, Segment.IO and Singly (now part of Appcelerator).
  • Mashup Tools: Lastly tools such as IFTTT and Zapier are making it easier for end-users to combine APIs – improving the value that can quickly be gained by using multiple APIs at once.

In some of these cases products and services are still in early stages, while others are already very mature. Together they are all signs of a connective tissue forming which helps the iterative interactions between API providers and API consumers. The two-way flow of demand is therefore becoming more agile and efficient and creating the autocatalytic positive feedback loop we are looking for.

Photo Nov 09, 1 21 58 PM


APIs as a tactical means to support the business of an individual organization deliver value – in general both to the provider and the consumer. This, in and-of-itself makes them valuable to build. However, what is also clear is that there are many transversal benefits to the development of many APIs – competing and complimentary. Shared technology, conferences, inspiration and re-use in unexpected ways all drive the feedback loop to make an Economy of APIs more valuable than the sum of the parts.

Many of the structures that glue this economy together are still extremely nascent or not widely used, but the fact that they exist at all suggests there is increasing value in the feedback loop. It seems likely that both the number of individual APIs and these structures will all accelerate.

In the next post we’ll explore how we might define the API Economy and in posts that follow we’ll look at challenges for individual organizations and the Economy as a whole.

July 2018
« Apr