API Evangelist

Ember, Angular, Backbone, Single Page Applications and APIs

Thu, 23 May 2013 23:56:46 PDT

I was looking through Steve Willmott's slide deck from his talk at GlueCon this week, called The API- & App-ification of the Web.

He talks about the evolution towards Single Page Web Applications (SPA). Which is the migration from static web pages and database driven web apps to dynamically driven HTML, CSS and JavaScript apps designed using popular JavaScript frameworks and libraries like:

Ember.js - Ember.js is an open-source client-side JavaScript web application framework based on the model-view-controller (MVC) software architectural pattern. It allows developers to create scalable single-page applications[1] by incorporating common idioms and best practices into a framework that provides a rich object model, declarative two-way data binding, computed properties, automatically-updating templates powered by Handlebars.js, and a router for managing application state
Angular.js - AngularJS is an open-source JavaScript framework, maintained by Google, that assists with running what are known as single-page applications. Its goal is to augment browser-based applications with model–view–controller (MVC) capability, in an effort to make both development and testing easier.
Backbone.js - Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface

Single page applications have benefits like speed, no page reloads, mobile optimization, real-time pushes, notifications and they just look freak'n cool. But there are also downsides like needing some healthy JavaScript talent to maintain, SEO issues and a general deviation from the linked, document driven web we are used to.

The popularity of frameworks and libraries like Ember, Angular and Backbone, and the Single Page Application approach isn't something just developers are noticing. Some top platforms are seeing the potential, and providing code and toolkits for integrating using Ember, Angular and Backbone:

At Crowdflower with Ember.js at CrowdFlower
At Firebase with Firebase Bindings for Angular and Firebase Bindings for Backbone.js
At Salesforce with Using JavaScript with Force.com & HTML5, Angular and Backbone Mobile Service Packs

With the popularity of JavaScript libraries and frameworks, and growing number of SPAs, there is a huge opportunity for API providers to offer API driven libraries and widgets that are plug and play with frameworks like Angular and Ember, and are compatible with libraries like Backbone.

As I monitor the API space I will continue looking for examples of APIs doing interesting things with Ember, Angular and Backbone. Let me know if you see anything I should take a look at.

Disclosure: 3Scale is an API Evangelist partner

APIs in DFW

Wed, 15 May 2013 21:34:24 PDT

I just got back from the Dallas-Fort Worth area. I visited Dallas last night to help kick off the first gathering of the DFW API Professionals Meetup.

We got together at Microsoft around 6PM and I talked from 6:30 until 8:00, evolving on my From Web, to ProgrammableWeb to ProgrammableWorld talk.

The meetup was about 45 people ranging from developers to investors. I showed up with a lot of content, but I wanted to make sure and cover the full API spectrum, while also introducing some new content about specifically about API consumption.

During the event I had some time to get to know the theRightAPI, Proxomo, Layer 7 Technologies and Pariveda Solutions folks--while connecting with the rest of the meet up group members.

Then, this morning theRightAPI crew brought me out to Plano, TX to the AT&T Foundry (@attfoundry), where I got to talk with Vincent Button (@vebutton) and Jennifer Conley (@jenniferconley). I was a little blown away by what I saw. It wasn't what I was used when visiting the campuses of big telco companies in the past. The facility was something you associate with Silicon Valley and Bay Area. Open layout with a variety of people working on things ranging from voice solutions to the internet of things.

Afterwards, Jennifer walked us up to the Gravity Center, which has been provided access to AT&T and Alcatel-Lucent resources to support multiple startups in the North Texas area. I got to meet to the BookShout team and hear about how they are navigating and working to change the book publishing space, while allowing people to discover books, and build social networks around books and authors.

I'm pretty impressed with what I saw in Texas in the last 48 hours. I met some pretty tech savvy people building interesting startups, putting APIs to use in meaningful ways, and a community around them that is investing in what they are doing. While I was there, I saw all the same elements for startup success I see in Silicon Valley, but without much of the hype.

I was stoked to be able to help kick off the DFW API Professionals Meetup Group. I appreciate theRightAPI for bringing me out, and Proxomo, Layer 7 and Pariveda Solutions for making it happen.

Adding API Broker Under Monitoring for API Aggregators

Mon, 13 May 2013 14:50:21 PDT

As I'm monitoring the API space I'm trying to create meaningful grouping for companies to belong when tracking API trends. My groupings are sometimes in alignment with what we hear in the tech blogosophere, but other times I try new definitions to help expand my monitoring definition and see if I can identify emerging patterns like I'm seeing with BaaS.

Each week I do a little more exploration in concept of API aggregation, and this week after studying payment API aggregator Spreedly, I'm considering adding a new, overlapping area with aggregation, called API brokers. Let's see if I can make this work.

API aggregators like Singly are providing personal data access to popular SaaS platforms by aggregating APIs. You can pull a list of photos from Singly, for a user, and it could pull photos from Flickr, Instagram and Facebook. This is pretty straightforward API Aggregation.

Other providers like Temboo, provide this functionality but focus more on the API interoperability or as i call it API reciprocity side of things. Temboo does aggregate multiple APIs like Singly, but focuses on providing interoperability as well as aggregation. While Singly does to, there are differences in their approach.

Spreedly has all the telltale signs of an API aggregator. They allow you to program against 48 payment gateways in 71 countries. It has aggregation, but rather than interoperability it seems to be about brokering transactions. Spreedly can help you choose the gateway based upon location, cost and availability. Which has all the elements of what I'd consider an API broker.

I envision other new API brokers emerging, in niche areas like images, video or messaging. Imagine if you could use Twilio, Tropo or other SMS API provider, but use through a broker who will give you the best availability and costs based upon various needs. This type of API aggregation is not meant for providing users with access to multiple cloud silos via APIs, it is more about brokering API resources and establishing a marketplace.

Not all APIs can be brokered, and maybe Spreedly is unique, but I bet I will find more of this behavior from other companies, once I start looking. Let me know if you know of any companies who broker API resources in a similar way to Spreedly.

The Dark Matter That Make APIs Work

Mon, 13 May 2013 13:01:01 PDT

I encounter many enterprise folks who dismiss APIs as nothing more that just one of the technical building blocks of SOA. Folks who, no matter how much I explain, will never see APIs beyond a technical specification and implementation.

API Evangelist solely exists to shed light on not just the technology of APIs, but the equally important business and politics of the APIs. It is the business and political building blocks that help the concept of API grow beyond just its technical roots.

An API won't find success just because you made a resource available via a URL. An API is successful because it is logically priced, possibly has revenue sharing, code samples to jumpstart integration and a support and resource network that a developer can tap into. An API is successful because it is open and self-service, but sensibly secured, providing a terms of service that benefit API owners, and developers, while also protecting the interests of end users.

APIs bring together a unique blend of technology, business and politics into a transparent, self-service mix that can foster innovation. As someone who is heavily invested at the enterprise scope, it can be difficult to see things through this lens sometimes. You will need to upgrade your prescription with the eye doctor.

Why "API" is working is not just a REST+JSON technical answer, there is a dark matter that binds the whole movement together, while also providing the right about of lubricant and oxygen necessary for innovation. In the enterprise you will often see this dark matter as governance, in the world of APIs it will have a lot of the same characteristics as your governance, but it is actually the exact opposite of governance.

I don't expect to convert all you enterprise folks to see APIs like I do. I don't think you are equipped to view the dark matter that keep the API movement expanding and moving forward. You are focused on seeing things through another lense of control and about the extraction of value--a lense that will always prevent you from seeing the dark matter that makes APIs an evolution beyond SOA.

Potential for API Aggregators to Provide Valuable Industry Data

Mon, 13 May 2013 12:18:57 PDT

I've been tracking on a trend in the API space that I call API aggregation. Companies like Singly and Adigami are aggregating APIs into more meaningful API stacks, than any single API provider can deliver on their own.

In my regular monitoring, I'm always on the hunt for examples of the benefits of API Aggregation, and last week I saw some pretty interesting payment gateway data being provided by payment API aggregator Spreedly--which definitely reflects the positive effects I'm looking to shine light on in the space.

Spreedly is a cloud based credit card vault that allows you to work with one or multiple payment gateways over time or simultaneously, and has published some pretty interesting analysis of failed transaction rates across multiple payment gateways.

I'll let you head over to Spreedly to read the analysis. What I find interesting is that they are open to sharing this data with the public. This type of information sharing by API aggregator providers is critical to the overall health of the space. I'm often frustrated by the lack of data that API providers share, because they so often are keeping their cards so close to their chest, trying to protect their valuable business data or often lack of business data.

There is huge opportunity for API aggregators to share information about their experience with the common APIs they integrate and aggregate with. The whole industry can learn from this, but also work its way back upstream to the payment API providers, providing them with insight into how their APIs are operating, but also provide benchmarks of where they stand with their competitors, good or bad.

Let me know if you see any other examples of API aggregators sharing data like Spreedly.

My Talk Tomorrow Night at the Dallas-Forth Worth API Professionals Meetup

Mon, 13 May 2013 11:00:06 PDT

After looking through the list of folks who have RSVP'd for the DFW API Professionals Meetup in Dallas tomorrow night, it looks like an interesting mix of tech and business folk. The tech group is definitely the larger, with a mix of mobile, web and enterprise. The business folks look like a mix of VC, project manager, marketing and startups.

I'm heading out to Dallas in the morning, and I am spending my afternoon preparing my talk. When it comes to meetups, I like to wait until the last moment, see who has RSVP'd and shift my talk to being more tech, more business or more API 101 depending on the audience. I like the mix of people I'm seeing RSVP'd for tomorrow night.

I'm pulling together a talk from some of my regular material, but updating for what is going on right now. Resulting in the following outline I'm calling, "From ProgrammableWeb to ProgrammableWorld":

API Evangelist
History of APIs
API Management
- What It Was
- Design
- Deployment
- Management
- Monetization
- Evangelism
- Community
API Consumption
- What It Was
- Discovery
- Education
- Integration
- Monetization
- Operations
- Community
API Trends
- Aggregation
- BaaS
- Reciprocity
- Real-time
- Voice
ProgrammableWeb
- Web
- Mobile
- Tablets
ProgrammableWorld
- Quantified-Self
- Automobile
- Buildings
- Sensors
In Closing

As with all of my talks, I look forward to making it a conversation with the audience and hopefully shifting the discussion, further towards what Dallas-Forth worth folks are looking to understand and share within the API space.

Thanks to theRightAPI for pulling the event together and Proxomo, Layer 7 Technologies and Pariveda Solutions for sponsoring to make it all possible. I look forward to seeing you all in Dallas, TX tomorrow evening.

The White House Releases An Open Data Strategy

Sat, 11 May 2013 15:19:30 PDT

Photo Credit - White House

President Obama issued an Executive Order this last week - Making Open and Machine Readable the New Default for Government Information. A move that will signficantly define the fast growing API economy. But before I dive into what this means for open data and APIs, I wanted to recap the last year of progress in Washington when it comes to open data and APIs.

If you recall, in May of 2012, the White House issued the Memorandum on Building a 21st Century Digital Government, which provided federal agencies with a 12-month roadmap to get familiar the concept of possessing a healthy digital strategy, which involves taking a strategic approach to using social, cloud computing and mobile, with open data and APIs as the core.

After reading the directive from the White House in 2012, I wrote Barack Obama Directs All Federal Agencies to Have an API, which is still one of the most viewed posts on API Evangelist, after The Secret to Amazons Success Internal APIs.

While I am a believer in both APIs and the potential of healthy government leadership, I'm also very skeptical of blind API faith and of our federal government to deliver on open data. After reading the directive out of the White House last year, I got to work understanding, tracking and quantifying the potential and progress coming out of Washington when it comes to open data and APIs.

The important thing to understand about the White House Digital Strategy, is that it doesn't just say open up APIs to support open data and mobile iniatives, it also says to make these efforts discoverable by providing a HTML, JSON and XML version of each agencies digital strategy--making their strategy and resulting data sets not just machine readable, but also machine discoverable. This is the critical aspect of the digital strategy, which will act as the gears in the government fueled API economy, but it also gave me an idea on how to measure the progress of each agency in the Digital Strategy and resulting open data efforts.

All federal agency were directed to develop a digital strategy around open data and mobile, then publish it at their website in HTML, XML and JSON. So I got to work quantifying this. I wanted to understand which agencies had done this successfully. To begin I needed a list of federal agencies, which I was able to pull from the Federal Agency Directory API. Now I had a database of each agency name, abbreviation code and URL. Next I wrote a script that "pinged" each agencies URL and looked for http://[agencyname].gov/digitalstrategy.html, http://[agencyname].gov/digitalstrategy.xml and http://[agencyname].gov/digitalstrategy.json. I ran this script each night to see who had published their strategy.

Coming up on a year after the release of Memorandum on Building a 21st Century Digital Government, we have 0 "agencies" that have published a digital strategy:

Federal Agency Digital Strategies

Across these 0 agencies, there are 0 published datasets to support 2.2, which was to make high-value data and content in at least two existing major customer-facing systems available through web APIs, apply metadata tagging and publish a plan to transition additional high-value systems:

Federal Agency Digital Strategies 2.2

Across these 0 agencies, there are 0 published services in support 7.2, which was intended to optimize at least two existing priority customer-facing services for mobile use and publish a plan for improving additional existing services:

Federal Agency Digital Strategies 7.2

All of this data was pulled programmatically, using one of the core elements of the White House Digital Strategy, stating that it should be programmatically discoverable. You can access the resulting JSON and scripts to display in the header of each listings above.

While 22 agencies did publish their strategies, there were a couple I couldn't process at all, and many others who had little problems that made harvesting difficult. Each programmatic request to an agency for their digital strategy could result in any number of HTTP codes retruned, redirects and responses. To demonstrate the potential differences, let compare two agencies:

Energy (http://energy.gov)

Digital Strategy (HTML) - http://energy.gov/digitalstrategy.html
Digital Strategy (XML) - http://energy.gov/digitalstrategy.xml
Digital Strategy (JSON) - http://energy.gov/digitalstrategy.json

Commerce (http://www.commerce.gov/)

Digital Strategy (HTML) - http://www.commerce.gov/digitalstrategy
Digital Strategy (XML) - http://energy.gov/digitalstrategy.xml
Digital Strategy (JSON) - http://energy.gov/digitalstrategy.json

While the XML and JSON version of each agencies strategy is at same location, the HTML version have differences of locations. These small differences only amplify when you scale to 246 agencies. The issues also get more technical, with any variety of HTTP response codes returned including 200, 300, 400 and 500. Which I won't go into for this post, but when you are trying to write code, these can cause a whole bunch of problems.

To put a cherry on top of this exercise, if you go to whitehouse.gov/digitalstrategy/ you get a pretty elaborate redirect to a PDF version of the original digital strategy mandate, which is a whole different cul-de-sac, especially since the White House has released datasets, APIs and mobile initiatives that should be listed here. The White House should lead by example.

I walk you through this process of programatically tracking on the White House digital strategy because I want to showcase the success that has occured over the last year, and support the next steps being taken by the release of the Open Data Policy. But I want to also showcase how difficult this all can be. On the surface it can sound easy, but once you get into the weeds of execution things can breakdown pretty quickly, and it can be very difficult to keep the big picture in focus.

As we roll into May 2013, and approach the 1 year mark of the White House Digital Strategy, I can't help but embrace the new Open Data Policy with the same chaotic, bi-polar embrace I give the rest of the Digital Strategy and the overall public API space--with healthy balance of optimism, pragmatism and concern--then roll up my sleeves and get to work. During the last year of doing this, I've learned a lot about APIs and the Federal Government I would like to share:

Web Literacy…is critical
101 Materials..are essential
Evangelists..are necessary
Hackers...are desperately needed

And most importantly, some sort of framework is necessary to give agencies a structure to work within, and a toolkit to direct them. This is the Open Data Policy, and brings us to the Open Data Executive Order and the accompanying Open Data Policy released by the Office of Management and Budget and Office of Science and Technology Policy which:

require(s) that, going forward, newly generated government data shall be made freely available in open, machine-readable formats, while appropriately safeguarding privacy, confidentiality, and security. This requirement will help the Federal government achieve the goal of making troves of previously inaccessible or unmanageable data easily available to entrepreneurs, innovators, researchers, and others who can use those data to generate new products and services, build businesses, and create jobs.

This kind of language is music to my ears. Understanding how our government works is one thing. Understand how to do it programmatically. Well, that is a whole other ball game. If we can move our government forward and develop a true path forward, to make everything our government produces machine readable by default. I'm on board. Let's get to work!

What does the Open Data Policy deliver?

Laying the Groundwork - Why is this important? The Open Data Policy makes the business case for why this is important. This is about making government more effecient and generating jobs and innovation amongst entrepreneurs
Open Data Definition - Balancing "open" with privacy, confidentiality and security. Acknowledging that open data is about it being accessible, described, reusable, complete, available in a timely and manner and should be managed post-release
Common Definitions - Some basic definitions of data and datasets, as well as covering common points like fair information practice principles and personally identifiable information. But i'm really impressed with the introduction to concepts of information lifecycle and the mosaic effect. Great way to start
Implementation Guidance - The Open Data Policy is truly a guide, with step by step implementation assistance for agency to help agencies actually making the rubber meet the road with putting open data to work
Tools - A suite of open source tools are provided to agencies including database to API, CSV to API, spatial search and other useful code that agencies download, fork and put to use
Resources - Additional resources that help agencies make the business case for open data, develop workflows, example licensing, content checklists and other resources to jumpstart an agencies open data efforts
Life Cycle - Critical guidance for agencies that helps them understand the importance of using machine-readable and open formats, follow open data standards, use open licenses and to take advantage of common core and extensible metadata whenever possible in open data initiatives
Accessibility - Provides an overview how agencies must build or modernize information systems in a way that maximizes interoperability and information accessibility. Making sure things are always available, scalable, flexible in multiple formats and empowers sharing and reuse
Release Practices - Introduces agencies to healthy data release practices to assist in developing data inventory, establishing roles & responsibility for stewardship, guides that assist agencies in developing a public listing and providing the essential outreach and engagement with the public and partners around data throughout its life cycle
Security Guidance - A clear process for securing publicly available data, consistent with the Open Government Directive's presumption in favor of openness, and to the extent permitted by law and subject to privacy, confidentiality pledge, security, trade secret, contractual, or other valid restrictions.
Institutionalize - Clear mandate that agencies must institutionalized and operationalized the interoperability and openness requirements in the Open Data Policy into their core processes across all applicable agency programs

Why the Open Data Policy Make Me Happy?
The Open Data Policy makes me proud to be an American. Really! But beyond my joy for APIs, open data and passion for making government more efficient, I see some pretty specific aspects of the Open Data policy that make me happy.

101 Materials - The open data lays the groundwork, provides the definitions, tools and resources that agencies will need to make it to the next level and find success with their agencies open data iniatives successful
History - To help make the case, the White House showcases how releases valuable data like GPS and weather has changed the world and how we do business. People need meaningful example like this to wrap their heads around the potential
Guidance - Guidance, in the form of step by step guides showing agencies how to execute on the Open Data Policy. This type of guidance is critical to help agencies follow the policy
Case Studies - The Open Data Policy provides case studies, which much like the history it provides, gives clear examples that agencies can relate with when considering, planning and executing on their iniatives. Agencies need to see clear examples that they can emulate in their own inaitives.
Tools - The White House provides agencies with a suite of open source tools that can be used to actually start deploying APIs from databases and CSV. Simple, open source tools are critical to the success of agencies when executing on the Open Data Policy.
Life Cycle - Understanding that just launching open data is not enough, and having processes to manage the lifecycle of open data and APIs is essential to not just a successful iniative, but also iterating and evolving data until it meets the needs of developers and consumers and generates maximum value
Two-Way Street - Finding sucess with an agencies open data wil require the process being a two way street. Agencies will need to engage with consumers and possess people, processes and tools for receiving and integrating feedback into agency operations. The Open Data Policy provides valuable information that helps agencies make their programs a two-way street
Institutionalize - The Open Data Policy isn't just yet another data or technology iniative where a new IT approach is being mandated. The Open Data Policy is about true change to the way agencies collect, process and publish information, pushing agencies to institutionalize the approaches set forth. This is about true change, not just another tech trend.

What Around The Open Data Policy Conerns Me?
Immediately after the joy ride through the items that make me happy, I start stumbling over some serious concerns. Things that will slow, trip up, or could make the Open Data Policy a non-starter. These are just a handful of my immediate concerns.

Government
- Lack of Resources - Agencies won't be given enough resources to give meaningful attention to executing on the Open Data Policy and the desired results won't be achieved
- Lack of Evangelists - Agencies won't be able to hire or cultivate the passionate evangelists that will be needed to iniatiate change within agencies and get the word out to consumers
- Lack of Storytellers - The Federal Government won't actually give agencies the freedom to be storytellers around all information, data and resources coming out of each agency. Storys around the data will be essential to getting consumer interested and engaging
- Administration Changes - The next administration will come in and not see the value of Open Data Policy and will roll any progress that has been made back
Corporations
- Exploitation - The private sector will step up and expoit government data and resources without recipricating value and sharing their data and augmented resources for the greater good
- Talent - When talent is identified as part of federal government open data, the private sector will snatch them up and put them to use for their own goals, taking the talent away from where its most needed
Citizens
- Won't Step Up - Even with the effort of federal agencies, citizen hackers won't step up and do the work it will take to make agencies open data iniatives work and help clean up, refine and provide the feedback agencies will need
- Won't Be Aloud In - Citizen hackers will build amazing things and provide some valuable work and feedback, but because of the closed nature of Washington, their efforts will be ignored and now given the attention they need to be successful

Why I am Optimistic About the Open Data Policy?
I think we can navigate many of the concerns I have around the Open Data Policy. I know many of the people behind the government efforts, and I believe in these folks. But I also believe in the power of what the private sector, leaving me very optimistic about what the Open Data Policy can achieve.

Government
- Starting Simple - The White House is starting simple. They have started with the necessary education and evangelism needed to get agencies on board. The Open Data Policy isn't technically overwhelming, it focuses on the basics and keeps things simple so agencies can absorb and put what they've learned to work
- Engage - The Open Data Policy enforces engagement with consumers as part of a healthy data lifecycle. Without engaging consumers and making the process a two way street, no amount of opening data will be successful. Helping agencies understand the importance of engagement is critical to healthy open data iniatives
- Using Github - The Open Data Policy isn't just educating agencies on the importance of using Github as part of their open data iniatives, the White House is using Github ot deploy and support the Open Data project. This type of leading by example is critical to the adoption of proper tools by agencies
Corporations
- Value of Open Data - The private sector understands the value of open data and will actively participate in open data iniatives from federal agencies. The more data that is opened, the more the private sector will step up and use, contributing significantly to the data life cycle
- Emulate Government - With the federal government stepping up and leading, the private sector will follow. In the API space, corporations often emulate what they see in the space. Strong leadership from Washington will make for healthier busineses across the private sector and API economy
Citizens
- Roll Up Sleeves and Get to Work - There are some seriously talented and passionate invidivuals involved with current government open data movements. As more agencies open up their data these hacker citizens will step up and provide some great code, data and feedback for government agencies. The key is to make sure we continue to train the next generation of these talented, passsionate citizen hackers
- Problem Owners- There are individuals in the private sector who are extermely passionate about some of the biggest problems our country faces. These individuals will step up and put open government data and resources to use solving these problems

After reading through the Open Data Policy multiple times, I feel that we can do this. I've read much of the criticism in other folks analysis of the release of the Open Data Policy, along with their praise of the administration's move. I think there is enough optimism and healthy pessimism out there, to really make this work. We can't be blinded by the often meaningless declrations of "open" or our blind faith in technology solutionism, we have to get to work with the difficult tasks of taking inventory, collecting, deployment and management of our countries valuable information and assets. It will be a long road to get to where each agency and government worker understands what open and transparent truly means, it will be occur dataset by dataset, app by app and via numerous conversations between government and the private sector around each opened dataset and API. It won't happen overnight, but the White House Digital Strategy and resulting Open Data Policy are an decent start.

What I'd LIke to See!
The pragmatist in me appreciates the simple and cautious approach of the federal government. It will take years of baby steps before we can run with open data. But to help me understand where we need to be, I tend to try and understand what the potential future of government and open data could look like. So let me share a few items I'd like to see in the future of government open data.

JSON by Default - I want every individual in government to speak JSON, just like they speak PDF or Excel. Government workers need to natively generating and consuming JSON without hestiation or confusion
Dictionaries of Data Inventory - The listing of agencies who published their digital strategy, lists of 2.1 and 7.2 compliance and the counts listed above were all provided with JavaScript and JSON. ALL government should work like this. I shouldn't reference an agency, individual, budget report or otherwise without using an open data driven dictionary of some sorts. There should always be the data behind each fact or claim made in government. With a healthy inventory across agencies, this is possible
Visualizations - Pictures are indeed worth a thousand words. We need an arsenal of simple, JavaScript and HTML5 visualizations that government works can reverse engineer or put to use when trying to tell the store around their information. Visualizations will be essential in storytelling around federal government open data.
Toolkits - The Open Data Policy does a great start to provide tools and resources agencie will need. But we need a whole aresenal of open toolkits providing tools and resources to help agencies with everything from GIS to working with financial data. These meaningful toolkits will be generated by the projects, in the trenches and published as part of the the living Open Data Policy in coming months
Widgets - Much like visualizations, there will need to be a arsenal of simple, JavaScript and HTML5 widgets that allow for interaction between agencies, data stewards and the public. Widgets will allow for feedback, updates, syndication and other essential aspects of data lifecycles
Acreditation - There will be a lot of data coming from federal government. We need to know which individuals have the most skills in specific domains. There will need to be some sort of micro acredition process that individuals can go through to demonstrate the data and tools they have experience with, so that agencies and individuals can quickly identify who they should reach out to as part of the open data life cycle
Tax Incentives - I've spent probably 150 hours in the last year working on government open data work. None of it was paid. As someone who does not seek a career in government, but will continue supporting from the private sector, I would really enjoy some sort of tax incentive to do so for my business or self employment

While I'm always looking toward the future, I am extremeley satisfied with leadership coming out of Washington when it comes to APIs. I'm also happy with the progress that has come out of the Digital Strategy over the last year, and I think the Open Data Policy provides a healthy and logical next step for federal agencies to take.

The Open Data Policy does an excellent job of addressing the technical, business and politics of APIs. While APIs, open data formats and other technical building blocks create a nice base, the policy also considers healthy data life cycles, engagement, outreach and support that will be critical to each agencies success. The Open Data Policy also provides the necessary licensing, security and educational elements that will be necessary to properly deliver on what can be some of the very political aspects of open data and APIs in the wild.

The administration's pragmatic and balanced approach to open data in government will significantly increase the chance for individual agency success with open data and increase the chance they will truly be able to assimiliate the principles and practices set forth by the Open Data Policy into the agency operational fabric. When each individual within an agency embraces this, information management in the federal government will no longer be a technical or IT solution--every government worker, private sector partner, NGO and citizen will be a gear in an efficient, well lubricated, interoperable government engine that truly serves its people.

P.S. If you really read all of this post, I thank you. This whole process starts with my need to truly understand all of this and actually write code against as much of what the federal government is doing with APIs. I learn a lot along the way, and hope I am able to move the conversation forward.

When API Success Signals Begin Working Against You

Fri, 10 May 2013 10:10:36 PDT

Curently I'm immersed in discovering, vetting and tracking on signals that show me which companies are trending in the API space. I'm looking for signals that will tell me which companies are making movements on a week to week basis, and when the blogosphere and developer communities are buzzing about these companies and technologies.

Three very important signals I use are blogs, twitter and Github. These tools provide me with great signals I can use to tune into what a company is doing, when they push code, write a story or tweet about it. They also provide me with signals of when developers are engaging with API owners, because they follow on Twitter and download, fork, favorite and follow Github repositories.

However, in some scenarios a companies blogs, twitter and Github accounts can also tell me when a company has given up and has run out of money or just stopped putting energy and resources into a project. An example of this is with a company I came across during my monitoring last week, called RESTful Labs. RESTful Labs has all the eye candy to draw me in. I mean they have REST in their name, and they build tools for developers!

RESTful Labs provides API analytics tools for developers. I'm pretty stoked anytime I find something like this, then I immediately look at the common signals:

Blog - Check! - Last blog posted 11 months ago
Twitter - Check! - Last Tweet 8 months ago
Github - Check! - Last commit was 8 months ago

On the surface, RESTful Labs has all the right signal generators in having a blog, Twitter and Github accounts. But immediately these signals start working against them, rather than the positive signals I would normally gather from someone having a blog, Twitter and Github accounts.

It is clear that RESTful Labs WAS something last year, but now it is all but a ghost town. It is not a tool I will recommend anyone use because there is nobody home to support. Since they have a Github account, there might be resources that can be picked from the bones of the startup, but not much else beyond that.

I keep companies like this in my database, as I want live examples like this to show people, and help them understand how to send the right signals that they are doing good things in the space.

Get To Know Which Languages Your API Developers Are Using

Wed, 08 May 2013 19:29:46 PDT

Accounting API platform Xero has been taking a deeper look into the languages that their developers are using when integrating with the Xero API. Currently there are 1,600 active applications communicating with the Xero API, from a mix of Xero add-on partners to custom integrations engineered by 3rd party developers. But which programming languages were they using?

To create a snapshot of what tools developers are using, Xero needed to find the best source to obtain this data. Xero doesn't ask developers which platform they use upon registration, and since Xero doesn't require any sort of user agent or other identifying signature, it was difficult to know where to best acquire the data they needed.

The next best place to look for this data, is with the code samples themselves. It would be nice, if Xero code samples were hosted using Github where they could track downloads, forks, followers, etc. But the best they had, was the page views from the pages for each code library, within the Xero developer area.

Using this approach, Xero was able to extract some pretty interesting data about which programming languages developers were clicking on. Identifying the growing dominance of languages like PHP and the emergence of newer approaches using Node.js.

While Xero was able to learn a lot, I think we all should learn from Xero's story. There is a lot to be learned by other API providers: 1) API integration needs to be language agnostic 2) Working to understand which languages are beings used or in demand from developers, on a regular basis is important.

This seems like a pretty basic topic to some of us, but when an API is born out of a company that has a single language focus, it can be difficult to understand the needs of developers who are using other platforms and languages.

Make sure you prepare an approach to gathering and regularly evaluating data around which languages your API developers are needing to integrate ad work to support that as much as you possibly can.

Twitters Developer Area is More Embeddable Than API

Wed, 08 May 2013 18:35:38 PDT

Does anyone else notice the evolution of the Twitter developer area? The site has taken a page from the LinkedIn playbook and become more about embeddable buttons, badges and widgets than about APIs.

Granted, you can click on documentation and get at the REST API v 1.1. I'm not saying this is a good or bad thing. I'm a big supporter of embeddable strategies for API providers. I think that evolution is very telling of Twitter's API strategy and what type of "developer" they want to support with the API.

Whether or not you agree with Twitter's overall API strategy, there is a lot to learn from their approach to API driven embeddable tools. I will produce more pieces aobut their approach to cards, timelines, buttons and other embeddable tools.

Overview Of Backend as a Service (BaaS) White Paper

Wed, 08 May 2013 15:26:30 PDT

I've been working on expanding the amount of research and writing I can do via API Evangelist lately. In the last couple weeks I rolled out new projects in three areas: API Toolkits, API Trends, API Priorities. This new approach is helping me focus on the areas I think are most important or exciting to the API space and generate as much, high quality news, analysis and white papers for the API space as I can.

The first of my white papers, using my new approach is finished. The new paper is called Overview Of The Backend as a Service (BaaS) Space, and is the aggregation of all my research into the BaaS space. Here is a breakdown of the white paper:

What is BaaS?
How Does BaaS Differ From IaaS and PaaS?
What Are The Benefits of BaaS?
What Can You Build With BaaS?
Who Are The Top BaaS Providers?
What Are The Common Building Blocks of BaaS?
What Are the Common Approaches to BaaS Pricing?
What Are The Other Approaches to BaaS Pricing?
Who Are The Other BaaS Providers?
Watch Out As 1000lb Gorillas Set Their Sights on BaaS Space!
What Makes BaaS Relevant to APIs?
The Future Is About Virtualized Mobile Operating Systems
Investment in BaaS
What Are The Opportunities in BaaS?
Summing Up BaaS
Appendix A: Full List of BaaS Features
Appendix B: Curated News Sources

Much of the research, news, analysis and data that went into this white paper is available at baas.apievangelist.com. As I do with most of my work, I will be publishing all my BaaS research to this Github project, allowing anyone to view, fork or download. The BaaS project will also have a full version, available as a PDF for $99.00. My goal is to subsidize my research via sales of white papers and the support of my partners. If you can't afford, tune into the BaaS project, but if you'd like to support what I do you can purchase a copy.

I'm working on other papers that are part of all of my API Toolkits, API Trends and API Priorities research areas. If you'd like to get more access to my research, news, analysis and data, or would like to support what I do, please let me know.

Make Sure And Have Multiple KPIs For Your APIs

Tue, 07 May 2013 18:49:05 PDT

In the API space, we have to be constantly measuring and looking for signals that will help us understand where we should be focusing our resources, as part of an overall strategy. One of the ways we measure value within the world of APIs (and business) is using KPIs, or Key Performance Indicators. Using KPIs we strive to measure the Return on our Investment (ROI), as we gamble with the technology, business and politics of APIs.

One approach to quantifying the value, that has emerged from API providers, API service providers and the tech blogosphere is using the "API call". It is simple. You launch an API, so you quantify it by the number of times someone calls it. Kind of like a page view, right?

Out of this eyeball derived reality(which is silly since APIs aren't for humans), the API space has become obsessed with the number of API calls, resulting in what is known as the API billionaires club. The Billionaires Club is an elite group of tech providers who have billions of calls per month on their API. It is a pretty simple algorithm. Have API + Have Billions of Requests = Your In The Billionaires Club. And if you are in the billionaires club, you are successful. End of calculation.

To quickly get to the point of my story, let's take one of my favorite members of the API billionaires club, Netflix. Billionaire Club Membership + Shutting Down Public API = Success. It is a different variation on the whole concept of measuring API success. The news, commonly held KPIs and definition of success doesn't immediately pan out in the whole Netflix story.

Netflix, along with Twitter are both API case studies for the history books. Both of these API stories reflect the ups and downs of the API world, and the often bipolar nature of the public API ecosystem and schizophrenic nature of the tech blogosophere. In contrast, along with Amazon Web Services, Twitter and Twilio, Netflix is a constant player in the stories I tell about success in the API sector. But at the same time, Netflix is considered to be a failure by common public APIs measurements. Are you feeling the crazy? I do!!

As I've covered before, the blogosphere tends to associate closure of the Netflix, with the ecosystem failures of Twitter. While this is an easy comparison to make, when you look further, you see a lot more going on. Which tells me we need better ways to measure API success and failure and tell the stories around the ups and downs.

After monitoring the API space for some time now, I'm looking for signals beyond what normal bloggers, analysts and pundits are following. In this hunt, Github is becoming an ever increasing gold mine of signals. To help demonstrate, let's take a look at the signals the Netflix Github account puts out.

Priam - Co-Process for backup/recovery, Token Management, and Centralized Configuration management for Cassandra. (Last updated a day ago)
aminator - A tool for creating EBS AMIs. This tool currently works for CentOS/RedHat Linux images and is intended to run on an EC2 instance. (Last updated 2 days ago)
astyanax - A Cassandra Java Client (Last updated 2 days ago)
asgard - Web interface for application deployments and cloud management in Amazon Web Services (AWS). Binary download: http://netflix.box.com/asgard Twitter: http://twitter.com/AsgardOSS (Last updated 3 days ago)
RxJava - A library for composing asynchronous and event-based programs using observable sequences for the Java VM. (Last updated 4 days ago)
denominator - (Last updated 5 days ago)
blitz4j - Logging framework for fast asynchronous logging (Last updated 6 days ago)
SimianArmy - Tools for keeping your cloud operating in top form. Chaos Monkey is a resiliency tool that helps applications tolerate random instance failures. (Last updated 8 days ago)
ribbon - Ribbon is a Inter Process Communication (remote procedure calls) library with built in software load balancers. The primary usage model involves REST calls with various serialization scheme support. (Last updated 9 days ago)
frigga - Utilities for working with Asgard named objects (Last updated 10 days ago)
curator - ZooKeeper client wrapper and rich ZooKeeper framework (Last updated 11 days ago)
karyon - The nucleus or the base container for Applications and Services built using the NetflixOSS ecosystem (Last updated 12 days ago)
edda - Service to track changes in your cloud (Last updated 13 days ago)
brutal - A multi-network asynchronous chat bot framework using twisted (Last updated 17 days ago)
archaius - Library for configuration management API (Last updated 17 days ago)

When I pulled this data, several days ago, there are 15 separate repositories, in four separate programming languages, including Python, Java, Groovy, Scala, that have all been updated in the last 30 days. The fact that Netflix has a Github account, has open sourced so much of their code, while also actively maintaining it all, point at some very meaningful signals that we can tune into and work to emulate.

While the number of calls against an API is a valid KPI to measure the potential success of an API, we have to have multiple KPIs when truly trying to understand the value of a company, the platform or any single API resource. Let's not get hung up on any single KPI, let's consider as many as we can--to see what makes sense and truly defines succcess.

There is so much to learn from reading between the lines in the world of APIs.

API Enabled Toys For Our Children

Tue, 07 May 2013 18:09:46 PDT

When it comes to the Internet of Things, APIs have a bright future. I tend to focus on the greater good when showcasing APIs, but occasionally I get tripped up by the market potential of APIs. I came across the Baby Toys Get an App Extension post in the New York Times this week, and I can't think of a more lucrative market for API interaction via a smart phone, than a baby or toddler's toys.

First, can you image every mom or dad in America with access to their kids toys via their iPhone. Talk about an emotional connection. You have a real-time chord that is attached to a parents heart string. So if you are at work, missing your child that is at home, in day care, or even when you are at home with them, you have the opportunity to interact with your child via their crib, playstation or other toy? I'm not even going to start profiling the toys and the opportunity here.

Second, can you imagine the data available for toy, clothing and other manufacturers? You have a daily, permanent connection between a parent and their child via the toys that are most important to a child each day, and by default, what is important to the parent. With API connectivity between this toy and a parents smart phone via the home wifi connection, there is an unlimited flow of data about what impacts a child's life, and their parents world each day.

As the connection between APIs and the Internet of Things comes into focus for me, I get excited about opportunities like connecting our children's worlds to our smart phone enabled worlds. Then as soon as I get excited, I immediately get freaked out. Think about the opportunity, for…well, exploitation. We need to make sure there are best practices for terms of use, privacy and security in these fascinating, and new possibilities within the API space.

Lots to think about with APIs and the Internet of Things.

I Am Speaking At The Dallas-Forth Worth API Professionals Meetup May 14th

Thu, 02 May 2013 20:29:57 PDT

Hey everyone. I'm heading out to the Dallas-Fort Worth area the week after next, Tuesday, May 14, to kick off the DFW API Professionals Meetup.

TheRightAPI team were so kind to invite me out to speak, hang out and talk APIs, to help kick-off the area API group. Both TheRightAPI and backend as a service (BaaS) provider Proxomo are sponsoring the shindig.

The group will be meeting at the Microsoft Campus, 7000 Texas 161, Irving, TX. We are thinking we'll kick it off with food and drinks from 6:00 - 6:45 PM, and I'll start talking around 7:00 PM.

After that we can just hang out and talk about APIs and see what all y'all are doing with APIs in Texas. Ping me if your in the DFW area, so that I know you will be there.

Look forward to seeing you there and connecting.

How Much Do You Spend Attracting and Supporting Freemium API Developers?

Thu, 02 May 2013 14:27:47 PDT

I had a question from an API owner land in my inbox. It is regarding the amount of attention and resources that should be spent on on-boarding new customers. Directly from the email:

How would you suggest companies place a quantifiable value on free API users? I know that it is very important to have a lot of people use your API so that they can make great things with your API and also give people a chance to really understand the value of what the API offers, but do you have any thoughts on how companies should decide how much to spend on an API conversion (AdWords, Hackathons, etc.)

Let's first address the freemium part of the question. It is my opinion that every API should have a freemium layer. But only as one part of a well planned developer incentive ladder. This freemium tier is the top layer of your funnel. It will provide a way for people to test drive your API, understand what it does and the value it can deliver in their world.

Your freemium layer should be easy to access, no billing required and provide a sensible access to your API resources--also your freemium tier should never appear as if it is in danger of going away. But freemium should be that first step, with clear, meaningful next steps towards on-boarding users as paid customers. Provide clear paths to becoming a solid, revenue generating and contributing participant in the platform.

Make it clear to developers that at a freemium level they don't get support, that they have to pay to get that. Don't let this tier of users dominate you. With this said you better have good docs, code samples, active forum, FAQ and other essential building blocks for your self-service, freemium customers to use. But the amount of resources dedicated to your freemium customers should be minimal.

In my opinion, your resources should go into supporting your paid tiers of customers, the one who fee your revenue model, communicate and provide feedback to your platform and deliver value to your platform and business--reciprocating the value you have provided them. API ecosystems are a two-way street.

The second part of the question I think is regarding how much resources you should spend to attract developers into the top part of your funnel, potentially bringing them into your freemium tier, with hopes of quickly converting them into paid. I have a different perspective on this than probably many other companies. I'm a fan of organic campaigns vs. paid campaigns.

My approach to API Evangelism is about generating organic content that will help explain what an API does and the value it delivers. I hack PHP, Python, Ruby or mobile projects against the API. I find problems to solve, that may reflect what my target audience is trying to solve. I just don't think very many people are ever going to look for an API. They are going to be looking for a solution to their problem, and it may just be the solution your API provides. So advertising and traditional marketing is harder to dial in. I prefer identifying, coding, solving the problem and telling the story that speak to the customers I'm looking for.

The downside of an organic API evangelism campaign is it takes time to work. It takes months before you see anything. It is a very SEO driven approach, but it is how I've built API Evangelist over 3 years. Its lower cost than Google Adwords spend and hackathons, but takes someone with passion and domain expertise, mad programming skills and the ability to write stories, publish to Github and work social media like kung foo master--to execute!

The moral of the story is, that you should spend as little as you possibly can on bringing in developers into your funnel, and supporting them in operating at your freemium tier. Don't let the freeloaders rule your world. But this is easier said than done. Its a lot of work to generate resources that will bring the right customer in the door, in an organic way, and it takes a lot of outreach to engage with the customers you have in the door to develop a sensible developer and partner framework.

I think I have several more stories to derive from this great question, so stay tuned.

What Does The API Evangelist Do?

Thu, 02 May 2013 11:52:40 PDT

I sent three emails this morning to people, explaining what it is that I do and how they can get involved. This process reminded me that I need to do the same here via the blog on a regular basis, to help people understand what API Evangelist is, and my vision for it.

Despite popular belief I do not evangelize any single API to developers, my role (self-appointed) is to evangelize all APIs to the masses, most importantly beyond the developer community--penetrating business, marketing and other key groups.

At API Evangelist I monitor the entire API space. To do this I track on 2000 of the best of the APIs out there. I've gone through the entire ProgrammableWeb Directory and hand pick the ones that are worth paying attention to, and I continue doing this in real-time as they are added. Its not that the rest aren't worthy of use, just not an approach I feel is worth showcasing to other API owners.

700+ of these APIs have blogs, 1000+ have Twitter accounts and many have Github accounts. I monitor all in real time. I also track on 250+ blog feeds from mainstream tech blogs (TC, Gigaom, etc) as well as lesser known feeds.

I watch all this in real-time and tag everything using a centralized system I've developed. This is where I derive my blog posts and generate what I call my API Stack. The API Stack isn't meant to be a definitive list of who are the best, in a single order, but a living stack of which APIs are worth paying attention to, and are doing innovative things on a week to week basis.

I generate The API Stack using my home grown ranking system which is based upon 3 types of signals:

Internal - Number of blog posts, tweets, github repos and other internal activity from the APIs themselves
External - @mentions of twitter, stack exchange, hacker news, tech blogosopher, github repo follwers and activity
Analsyst - My curation, flagging w/ notes, voting up and writing stories about an API or company

From all of this weekly process I have carved several areas I focus deeper on:

API Service Providers

API Trends

API Priorities

These areas will evolve and grow as my research continues and the space changes. From all of this research I produce short form analysis (blog posts, project sites) and long form content (whitepapers, books). To keep things simple I provide a single standard monthly subscription to partners wishing to access of all this for $1500.00 / month.

Writing - Access to all of my long form content. White papers, research, etc.
Data - I generate a lot of data exhaust tracking, ranking and curating the API space. I have JSON data available across all aspects of my work.
Logo - Placement of maximum 250px width logo on right hand menu of API Evangelist properties.
4 Consulting Hours - Four hours of conversation via phone, skype or hangout each month.
Keywords - Your company name plus one other keyword or key phrase of choice which will link to URL of your choice.
Weekly / Monthly Summary - I produce a weekly and monthly summary of the top APIs and industries, with curated news and my analysis from the API industry.

This monthly subscription provides access to all research, data and writing I produce. I'm willing to negotiate other relationships, but this helps me keep a nice pool of clients, and me knowing I'll be in operation next month. Keeps me focused on research and not chasing new customers all the time.

Sometimes I also do specific industry research looking for patterns and opportunities as well going deeper by targeting specific APIs, like Twitter or Twillio, but I try to keep targeted research feeding into my overall pool of industry data, providing value to the bigger picture and overall space.

Hope this helps you understand what it is I do, and if you'd like to get involved, feel free to reach out.

Startups Need To Work Together on API Definitions

Thu, 02 May 2013 11:11:08 PDT

I am tracking on 2000 APIs that I have deemed worthy enough to pay attention, out of the 9000 on ProgrammableWeb, 13,000 in APIHub and numerous APIs in Mashape's marketplace. In addition to these APIs, I'm also closely watching 30+ backend as a service providers, 20+ reciprocity providers and emerging big data, analysis, visualization and other emerging platforms who are using APIs in new ways.

I was reading some of the great research coming out of OPENi, which is a "Open-Source, Web-Based, Framework for Integrating Applications with Cloud-based Services and Personal Cloudlets"--specifically the post on OpenI API Framework: Studying the Landscape of Cloud-Based Services.

What is great about OPENi, is they are doing all this research and planning, and sharing the process with everyone publicly. Which is great for everyone, but will take some time to play out, as they study, plan and execute in the space.

As I watch aggregate API providers like Singly plow forward and reciprocity providers like Zapier deliver some amazing integrations, using APIs, and bridging some of the most meaningful cloud platforms in our world--I can't help but think about how much redundant work is going on amongst startups.

When it comes to the definitions of specific APIs, the nuances of their interface and authentication, each of these service providers is doing their own work, in a silo. In a perfect world, API providers would provide Swagger definitions, standard oAuth implementations, etc. API owners would do a lot of the legwork for these providers. As we know, this isn't the reality, and each of these aggegrators, reciprocity providers, analytics tools are all mapping these API connections on their own.

I can't help but think about, how if providers stepped up, communicated with each other, they could establish some sort of commons for all of these API definitions to reside. They could colloaborately develop a way they could identify the meaningful APIs, hang Swagger definitions and code for connecting and authenticating in a multitude of programming languages.

Each provider could still maintain their secret sauce, what happens before and after each API connection, allowing them to have their own unique approach to API aggregation, reciprocity, analysis, visualization or real-time tools. But by sharing the API definitions and working together on the connections, they could spend more time on what makes their companies unique, rather than hand-rolling each API connection in isolation.

Just some random thoughts, as I navigate the world of APIs, from within my own silo!

Parse Is Successful By Truly Solving Problems for Mobile Developers

Wed, 01 May 2013 21:12:07 PDT

I don't personally use Parse or any other backend as a service (BaaS) provider to build mobile applications. I'm just playing role as analyst when it comes to the backend as a service space, but I am a developer so I can tell when any technology provider is speaking to developers or just marketing and hock'n their wares.

Each week I monitor the tech blogosphere, the API space and where it has expanded into the backend as a service space and driving mobile development. I pull 300 + feeds from random blogs and 700+ feeds from APIs providers. I see the contrast between what Techrunch, GigaOm and NextWeb produce alongside what API and BaaS providers publish to their blogs.

Day after day you can really start smelling the bullshit. The positive side is that this high profile bullshit really makes good quality posts, that are actually about solving problems, stand out.

I see a lot of posts come out of BaaS providers, and day after day, Parse is producing high quality posts, such as Versioning and Verification for your AWS Security Group Configuration and Six Creative Ways to Use Push Notification Marketing in Your Mobile App. When you read their blog, it is mostly posts that are about solving problems that developers are facing, and goes beyond just using Parse.

There are a number of reasons Parse was an attractive investment for Facebook, but I think the Parse blog is a very positive signal that Parse is more than just about building a company for acquisition--Parse is building a platform that solves developers problems. Another important aspect of this, is they tell the story of how they do this in real-time. Without telling the story, you can be doing some amazing things and nobody will know about it--Parse gets this.

Another sign of Parse's conviction, is the blog post rhythm hasn't changed since the acquisition of Facebook. I get the feeling that I will continue showcasing Parse's approach, much like I have done with Twilio, because they just get it.

API Commandment: Thou Shalt Not Forego Talking to a Person

Tue, 30 Apr 2013 14:17:44 PDT

Listening to an episode of Traffic and Weather yesterday, renewed a concept that John Sheehan(@johnsheehan), founder of Runscope made in an article he wrote for NextWeb back in March. In the post, John walks us through his “Three Commandments for Using Someone Else’s API”, which, after listening to him talk about his story on Episode 8 of Traffic and Weather, I couldn't stop thinking about commandment #2:

Thou Shalt Not Forego Talking to a Person

An open API is a great way to test drive an integration, but it does not absolve you from the responsibility of building a relationship with the provider. If you can’t reach someone, that should be all the reason you need not to use that API.

This commandment comes out of Johns unique experience which spans:

Twilio - Experience managing large, successful developer ecosystem
IFTTT - Experience being consumer of not just one, but many APIs
Runscope - Providing tools that make API developers lives easier

This experiences is what make John’s perspective unique. He doesn’t just understand delivering APIs and managing developers, he knows what it is like to be a developer and consumer of APIs. Which I think makes him either just the right balance or he’s his own worst enemy, not sure--could be both.

Anyways, regarding John’s commandment: Thou Shalt Not Forego Talking to a Person. In the past I have put a lot of pressure on API providers to consider different potential layers of their API ecosystem, and work hard to have a consistent approach to communicating, supporting and engaging with your developer ecosystem. While this all holds true, and API owners should focus on healthy developer outreach, it is a two sided coin, in which developers are accountable too.

The target audience for API Evangelist is API owners, so I guess my point is that as an API owner you have to craft a healthy communication and support framework, but also explain to developers when they sign up or are getting started, that while you’ll work to support them, it is up to them to step up and meet you halfway.

In the hype fueled tech blogosphere it's easy to take sides, rather than actually discuss the nuances of API ecosystems, and give sustainable advice--something that only comes from domain experts like John Sheehan.

API Trends

Sun, 28 Apr 2013 23:24:07 PDT

I study the API space. I want to understand how we got where we are at, and try to understand where we are going with our usage of APIs. To do this I monitor the best of the existing and new APis, using the blogosphere, Twitter, LinkedIn, Github and the open web looking for examples of how people are using APIs in different ways.

Currently I monitor the blogs of 804 API related companies and 205 blog feeds from other news and blog sources, as well as around 1000 API twitter accounts. As I read and curate this every day, I tag items according to a process I've evolved over 3 years of operation. Then at the end of each week I look at which tags are trending for the week, based upon what I've written and other news items I've curated along the way.

This is how I monitor trends. When Is see a tag trending, and I feel the area is interesting or has potential, I tend to spin off the topic into its own trend area. Now I can monitor it separately and potentially give it more attention, with the hope of finding new sources of information, companies and domain experts in this area.

I have done this with four main areas I've seen trending in 2013:

These are just a few of the areas I've had time to isolate and spin off into their own research projects. I have a short list of other areas I will tackle very soon, including voice, data analysis and visualization.

None of these project areas are concrete. They can change at any time, becoming entirely new areas or stay as it is, and since each project is its own Github repository, it can go idle, without any impact on the overall network--leaving it open for anyone else to use the data and content available within the project.

I will add new trending projects as I find them and have time, as well as add news, companies, APIs, tools, services and any analysis to existing project areas.

API Priorities

Sun, 28 Apr 2013 22:34:39 PDT

I spend a lot of time on API Evangelist getting excited about APIs. Going on three years doing this, I'm getting a little more hardened in my view on what is "good" in the API space. Along with that evolution, I'm getting my priorities in order.

While I may get excited about cloud computing APIs or quantified self APIs, there are other areas I think are straight up priorities--ones that we can't ignore. To support this I'm launching several research projects into areas I have labeled as API priorities:

These represent areas I'm actively doing research in, looking for the best APIs, tools, services, building blocks and news while also generating as much analysis and white papers as I can to help define what is going on.

As with all of the API Evangelist network of research projects, everything is a work in progress and represents what I have time to dive into. If you see anything missing, or feel some priority areas are not represented, let me know.

Have You Taken A Look At AT&T APis Lately?

Sun, 28 Apr 2013 17:57:22 PDT

Have you taken a moment and looked at the APIs AT&T is offering through their developer program lately? I think it is an interesting spread of API resources for a leading telco to offer, and is very telling about their strategy.

This is one thing I like about my API monitoring platform, is that I'm forced to dive deeper into companies that are ubiquitous in the space, and make sure I'm kep in tune with where they are actually going.

I thought AT&T's API catalog was interesting in its current state:

	Advertising - Create a new revenue stream through the use of customized advertising. The Advertising API allows you to incorporate a simple, easy-to-use solution that supports revednue share-based monetization of your apps through the placement of paid advertising.
	Call Management - Pick a virtual telephone number and add real time, cross-carrier voice, and SMS communications to your app.
	Device Capabilities - Returns important information about a device—allowing you to customize your apps accordingly.
	In-app Messaging - Drive further engagement with your customers by allowing them to share information with friends and family directly from within your app.
	Location - Quickly and accurately pinpoint the location of an AT&T mobile device.
	mHealth Platform - AT&T mHealth Solutions for healthcare combines mobility technologies, devices, connectivity, and apps to help minimize medical costs and deliver better patient outcomes.
	MMS - Multimedia Messaging Service (MMS) greatly enhances the power of your communications by moving beyond the text only capabilities of text based messaging.
	Notary Management - Add the capability to digitally sign content or data payloads to your app.
	Payment - Give your customers the convenience and security of having their in-app purchases charged directly to their AT&T bill.
	SMS - Short Message Service (SMS) enables your application or service to reliably send and receive secure, targeted text messages and alerts to your AT&T mobility subscribers.
	Speech - Allow your customers to interact with your app using their voice. You send us audio. We send you text. It's that easy. Now with the option to customize our speech recognizer for your app. Plus, Text to Speech.
	AT&T U-verse - Enable your app with the U-verse TV experience and allow U-verse TV customers to "connect" their world to yours via this cutting edge IPTV service.
	WAP Push - Provide support to legacy device customers that have limited message content and formatting capabilities.

Some of the APIs they offer are pretty straightforward like MMS, SMS, Location and Speech. But the TV, Healthcare, Notary and even advertising seem like they are from a different planet. Which is a signal in itself I think.

AT&T pops up on my radar a lot because of their presence at hackathons, and coverage in the blogosphere. I'd like to make more time to dissect AT&T's approach to APIs from an outside perspective. I think there is a lot to learn from their strategy, both good and bad.

Stay tuned...

Helping People Understand APIs Through Real World Examples

Sat, 27 Apr 2013 17:41:36 PDT

I'm always looking for easy, dead simple approaches to explaining APIs to people. Having real world examples, that folks can relate with, go along way in helping people wrap their heads around the very abstract concepts that are APIs.

While going for a walk today I was thinking back when I use to build technology for my parents trucking company, when one of the fuel expenses was for Commercial Fueling Network (CFN), which is a self-service commercial fueling station.

Whether your a long haul trucker or local contractor, you can use CFN to get at an essential resource for your business, whatever the application. Any business can apply and join CFN, get a "key" to access fuel resources in a self-service way.

APIs are the same approach to selling any "virtual" online resource, as CFN is to selling a "physical" fuel resource. CFN doesn't just put free gas alongside the road for anyone to take. They have a portal where you know to go to get your resources, providing you with a key to access the fuel resources you need. CFN then bills you for the usage of their resource. You can be sure CFN has extensive data on how much fuel they sell and who it was sold to.

With virtual resources, whether you are a iPhone developer or website developer you can use APIs to get at essential resources you will need for your business, whatever the type of applications you are developing. Any developer can apply to use an API, and get a "key" to access the resources in a self-service way.

The best part about the online approach is you can turn ANYTHING into a resource. Your resource can be data in a database, specialized code you've developed or interact with anything in the physical world.

This example works well for helping people to understand how APIs work, by using a real world example they may have experience with. The best thing is, you can continue evolving this example by talking about the payment APIs used to process credit cards while fueling or the usage of APIs to interface with accounting or other administrative systems for businesses who use CFN.

I'm adding this to my list of white papers and see if I can create a more polished version of it.

Evolving Beyond API Service Providers and Tools to Goal Based API Toolkits

Sat, 27 Apr 2013 14:28:29 PDT

As the universe of APIs expands, I’m working to find new ways that I can discover, educate myself, then organize information around the most meaningful areas in the API space. As part of this effort I’m reorganizing API Evangelist site into a network of small story groups, so that I can focus on a specific piece of this expanding API universe.

Each portion of API Evangelist will run using what I call my Hacker Storytelling format, where I use Github Page, Jekyll along with a variety of JSON driven widgets that tell a story around a specific topic.

The first story group I’m tackling is redefining two of my main sections which I had called “service provider” and “tools”. My original intent was to find resources people could use to deploy APIs, and if it was an online service I put it in service providers and if you could download and install, it went under tools.

I’m abandoning this approach and dismantling these sections and breaking them into goal oriented stories:

Design
Deployment
Management
Evangelism
Monetization
Discovery
Consumption

I don't have evangelism, monetization or consumption ready to go yet, but design, deployment, management and discovery are coming together nicely. You will be able to get at news, analysis, services and tools within these areas, as well as some overall thoughts about each area of the API universe.

I'm doing this to help me focus on each aspect of the API space, allowing me to see just the news and the best of the companies who are active in that area. This approach really helps me curate and write very focused stories and white papers that serve each topic. I hope it offers similar value for you.

My objective is to allow people to find information from two main areas, either using APIs or providing APIs. You can then navigate to individual areas within those two goal areas, with some overlap between them. In addition to toolkits for using or providing APIs, I'm also rolling out other story groups in the areas of API trends, priorities and opportunities.

So stay tuned…API Evangelist is always a living research project.

APIs & The Federal Government

Fri, 26 Apr 2013 10:40:55 PDT

It is has been a while since I updated any of my research around APIs & the Federal Government. In May 2012, I started monitoring the progress of the White House Digital Strategy, where I setup a monitoring system that pings all 246 agencies to see if they have published their digital strategy yet.

As we approach the one year anniversary, I expect we'll see a lot more news emerge around what various agencies are doing as part of the original mandate by the White House. As of today there are now 23 federal agencies who have published their Digital Strategy at their domain.

I have published all of my research around my APIs & the Federal Government research at a permanent Github repository. I will continue pushing all my research, curated stories and analysis there in real-time. I have also published a handful of JSON data sets I have generated as part of the research:

You can find the JSON data for these areas, along with the PHP script I used to harvest, store and publish this data using the JSON version of each agencies Digital Strategy.

While you can pull a list of federal agencies via from the Federal Agency Directory API, and each agencies social data using the Federal Social Media Registry API, the logos included with each agency is something I hand-rolled, so you won't find it anywhere other than here. I gave the data to the GSA, and I hope they incorporate the agency logos into the Federal Agency Directory API.

My Federal Government Github project will be a permanent, living place for me to publish stories, news, data and the scripts I create around my research in the area. I'm using my Hacker Storytelling format to keep everything up to date, openly licensed, while also keeping everything machine readable by default.

I'm categorizing this project under "API Priorities". It is a critical area that we need as many people involved as possible. If you need an idea for a project, let me know. I have endless ideas to suggest on how we can evolve our government using open data and APIs.