Tuesday, April 30, 2013

API Commandment: Thou Shalt Not Forego Talking to a Person

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.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/no8fgvuksw0/

An Author Walk-Through of a Story in Audio

I was finally catching up on all my podcasts this week, which includes Traffic and Weather, which is an always informative source of news and commentary podcast about APIs and the cloud hosted by @smarx and @johnsheehan 

While listening to Episode 8: I’m going to withdraw my objection, John Sheehan discusses his March story in NextWeb called APIs are Dead, Long Live APIs.  It was very interesting to hear him describe his intent behind the post and walk us through his points.  

I read the original article back in March, jotted down some notes, but really didn't trigger much beyond that.  After listening to him talk about the post, it renewed some very interesting points for me--which I'm working through an dyou will see in future blog posts.  

It is a lot of work to craft a good quality blog posts that conveys difficult and often abstract API concepts to a wide audience.  I struggle with getting my ideas across, as well as coherency in much of my writing. This got me thinking, maybe as part of my storytelling process I can try to work in an audio version, of me walking my readers (listeners) through it.

I'm not talking about something that reads the post to you. I'm talking about, me, actually walking you through the subject matter and post.  We'll see.  It is something I likely won't have time for with each post, but it would fun to try.  

I really have been trying to incorporate more audio and video into more of my content creation, but seem to be falling short.  I will keep trying until something sticks!



from Kin Lane http://feedproxy.google.com/~r/KinLane/~3/pWaWjJQK9Kg/

Monday, April 29, 2013

API Trends

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.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/0nGtE-yDiQk/

Sunday, April 28, 2013

API Priorities

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.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/f7bhkbIY1-E/

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

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 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...



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/ETMzUNx5iEA/

Saturday, April 27, 2013

Helping People Understand APIs Through Real World Examples

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.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/vbUN-19rN8k/

Helping People Understand APIs Through Real World Examples

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 as well.

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 busienss, 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.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/Mr7PcBi2cpU/

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

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:

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.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/asqL9fJbRlY/

Friday, April 26, 2013

Who Are The Customers For Your Startup?

Silicon Valley builds amazing apps!

We need customers to use our apps

Hopefully we get lots of customers who use our apps!

We can also launch an API, and become a platform

Now we have developers as customers

Now we have our developers customers as customers

We need $$ to operate and scale our platform, APIs and apps

Now we add investors as our customers

Our investors want us to give them ROI with a good exit

Now we have other larger companies as potential customers

Who is the customer of your startup?



from Kin Lane http://feedproxy.google.com/~r/KinLane/~3/E7BV2CWMv9I/

APIs & The Federal Government

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.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/mAC33Kn6DY8/

Thursday, April 25, 2013

After Last Couple of Weeks, It's Clear There Is Big Opportunity In The API Space

There was a lot of buzz in the API space over the last two weeks. I'm not a big on being first with news from the world of APIs, I leave this approach to the tech blogs like Techcrunch, RWW, GigaOm, The Next Web and others. I'd rather simmer on things for a bit, think beyond the press release, and craft a post that offers value beyond the initial announcement and the churnalism.

To get everyone up to speed, four major things happened in the API space over the last two weeks:

There is no arguing that these are some pretty significant signs the API industry is picking up the pace, especially when you have companies like Intel and Computer Associates taking notice and making investments. I've been tracking on the space for 3 years now, with round-ups of API service providers in 2011 and 2012. For 2010, 2011 it was all an uphill battle, but in 2012 I started seeing things heat up with the introduction of several new API service providers, then really stepping up in November 2012 with the acquisition of Vordel by Axway. But, the last couple of weeks are pretty outstanding, with not just acquisition of two separate API service providers, but also the fact that one of them is API pioneer Mashery, being purchased by chipmaker Intel. Love or hate Mashery, they help define the space and have been at it a while a while, and we all have an industry, partly due to their work.

VC Cycles More Than API Cycles

Personally I feel the recent acquisitions are indeed positive signals for the industry, but I think they are also just part of the natural cycle that is set in motion by the types of businesses, companies like Mashery and Layer 7 are looking to build. These are companies that are designed for an exit, an with Mashery raising almost $40M, after multiple rounds, as well as Layer7 at $20M, with just a handful of rounds. I don't do predictions, but I would say that Apigee is next with their $70M, in a Series E round. Any takers IBM? AT&T? Oracle?  The signals are more that these companies are ripe for picking, than it is a sign that the API space is booming.

The Enterprise Opportunity

The acquisitions of Vordel, Mashery and Layer7 tell me that the enterprise is interested in APIs, whether it is for mobile, big data or the internet of things--the enterprise wants in. Duh? That really isn't much of a signal. It is logical, and if you are building an API service provider company, that is looking for an exit, you are going to build your company so that it appeals to the enterprise. It isn't really API business, it is just business. I know that this is what many of you focus on as "being the opportunity", but in the end it is just short-sighted and doesn't reflect the real potential of APIs.

The API Opportunity

The real opportunity in the API space is about making sure that EVERYONE can design, develop, manage, discover and consume APIs, allowing them to significantly change their company or the industry they exit in. This is why ProgrammableWeb (PW) finding a new home at Mulesoft, and the $4.2M in funding by 3Scale excites me more than the acquisitions of Mashery or Layer 7.

First, ProgrammableWeb is the grandfather of API discovery, it's history and future are important to how we market our APIs as well as discover APIs for consumption, two sides of a very important coin.  So it is critical that PW remain live and being a vibrant piece of the API industry, something I believe that Mulesoft can deliver on, in a way that makes sure PW has a signficant a role in the future of API discovery. Alcatel-Lucent was completely abandoning their API efforts and it would have been a huge blow to the space if PW went down the toilet with Alcatel-Lucent's self-destructive vision of the future.

Why The 3Scale Investment is Important

I know all my haters will laugh, but I think the meager $4.2M investment made in 3Scale, is truly a positive sign for the API space. 3Scale isn't building an API service provider company for an exit. 3Scale has been the only freemium API service provider in the space since the beginning. Over the last 3 years, I've had multiple arguments with people across the space that the API opportunity for APIs is about unlocking enterprise resources with APIs, when in reality I feel the true API opportunity is about making sure every single business, organization and government entity understands APIs, stands one up, manages, iterates and evolves it until they get it right, without spending a fortune and being locked into contracts that are ultimately about boosting the numbers of a company intent on their exit. 3Scale has been doing this for years, and the $4.2M is just enough to grow and scale to the next logical and sustainable level.

I know the 3Scale approach it is not the sexy "startup way" or the "big numbers" that the TechCrunch and Silicon Valley audience loves, but to me it is a healthy way to approach what the API space truly needs.  3Scale's approach to running their business, and helping people stand up and manage their APIs is a realistic, healthy and sustainable way that API owners, developers and the overall space really needs. 3Scale is profitable and sought a sensible next round of funding to do more of what they are already doing. They aren't brining in customers to boost numbers or strictly pandering to the enterprise, ultimately seeking an exit over delivering a quality product. 3Scale focuses on delivering the resources, tools and services that people need to understand and successfully manage their APIs. The sign that 3Scale can get the funding they need to keep moving forward, shows the space has a healthy edge.

Meaningful Services, Tools and Educational Resources

Successful acquisitions of API service providers, by large enterprises, will not define the API space as "healthy". To deliver on the OG API vision, we will need a wealth of API resources, tools and services that make APIs accessible to ANYONE. There will be lots of money to be made when every individual company, organization or government organization can stand-up, run and iterate and find success with APIs for whatever their personal objectives or monetization goals are.

There is opportunity in the API space!  This is demonstrated by the buzz in the last couple weeks. But lets not get distracted by the opportunity to make money and selling to the enterprise. Let's focus on the opportunity that APIs afford individuals, companies, organizations and our government, and the impact APIs can make on the end-users or customers these companies sell to, or are in service of.

Ubiquitous API knowledge, tools and resources represent a much bigger opportunity for everyone, beyond the big money deals that seem to catch the headlines and dominate our attention.

Disclosure: 3Scale and Intel are both API Evangelist partners.  Although I have never actually taken money from 3Scale.  Maybe things are different now that they have the big bucks!! :-)



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/5OmmgwmZT4U/

Thursday, April 18, 2013

From CPU to API for Intel

Intel is reportedly buying API service provider Mashery for “a range of $120 million to $180 million”, according to ReadWrite(Web). As I reflect on this, two main questions come to mind:

  1. Was it a smart acquisition for Intel, and worth their money?
  2. Is this a logical move for Intel since they are a chip maker?

Was Intel’s acquisition smart for Intel? If they are serious about playing in the API game, which all signals I’ve seen say yes, I think it was smart. They didn’t buy Mashery for their tech, although their tech was a nice add-on to Intel's existing API Gateway. They bought Mashery to buy their market share.

Is the acquisition worth 120-180M? I’m not sure about that. I don’t think Masherys current market share is worth all that, so I think this is an investment in the past and the future more than current market share. Mashery is the pioneer of the API space, owning that history has value, if you can deliver on the future of the API space. Which I think Intel is more capable of than Mashery was all by itself.

Next is this a logical move for Intel? They are maker of physical things like motherboard chipsets, network interface controllers and integrated circuits, flash memory, graphic chips, embedded processors, not of things virtual like APIs.

Intel is known for making the thing essential ingredients “inside” our PCs, laptops, servers, smart phones and digital devices. They have been the driving force of “compute” for the last 40 years, basically my entire life. I’ve heard lots of chatter today that Intel moving from building the physical ingredients, to virtual APIs is too big of a switch for Intel, and they will fail.

Obviously I don’t know shit about chip manufacturing, but if Intel wants to be the leader in the next 40 years of computing, moving from central processing units (CPU) to distributed processing units (DPU) makes sense. In the past they have provided the computer, memory, graphics, networking and other essential elements we needed for personal, server or mobile computing. While these elements are still relevant at the physical level, compute has moved into the clouds and when it comes to the components or resources we will need to deliver the next generation of laptop, tablet, mobile, server, automobile or anything in the realm of Internet of Things, you will need hardened and secure API compute resources.

Intel will not be building and deploying APIs for fun and games on the Internet. Intel will be the gateway of the essential resources that are driving our mobile apps like SMS, voice, video encoding, etc, all the way to vital healthcare, climate monitoring and military grade API resources that will drive everything from the private sector to governments and NGOs worldwide.

I feel the Intel vision of APIs won’t and shouldn’t apply to all aspects of web APIs, open data, and various aspects of the open web. But I think Intel has what it takes to deliver the hardened and secure compute resources we are going to need to drive the next 40 years of web enabled technology.

Disclaimer: Intel is a partner of API Evangelist and Mashery has never been a partner of API Evangelist. :-)



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/NqFtRANYXmI/

Wednesday, April 17, 2013

Conflicting Emotions About API Providers

I’m a walking conflict most of the time. You should try being me, it can be tense about 40% of the time. I’ll give you a couple of example of what I mean to help bring you a little closer to what I experience each day.

I’ll start with what I consider to be the 2nd most important API of all time (#1 being AWS), Twitter. I love / hate Twitter. They really deliver on everything around their API except in regards to:

  • Rate Limits - Their rate limits suck!
  • Competition - They don’t approach potential competition sensibly
  • Communication - They aren’t good communicators

Other than those three "simple areas", Twitter delivers a damn good API. I find it very hard to criticize what they do, except for the fact that having suffocating rate limits, and shutting off access for integrations you view as competitive, can well, be a pretty quick downer.

An example of Twitter in action is with their recent post about Symbols entities for Tweets. I love this idea, I’m working through thoughts that are similar, when it comes to markup APIs or what I’m calling dictionary APIs. I think that a dictionary, symbol or other lookup functionality around an API is cool and has a lot of potential...right up until the point you realize they are have been sharecropping a lot of this innovation from the Twitter Ecosystem.

In the end, I just have to live at odds with the way I feel about Twitter. I can’t stop showcasing the cool stuff they are doing, just because I do not agree with their approach to API rate limits, communication, competition and sharecropping (or is it cropdusting?)

Another similar conflict in my life is around the Pearson API. As a company I’m not 100% in agreement with what Pearson is up to, but from an API perspective, I am a big fan of the companies approach. They follow what I consider to be a lot of the best practice for the space, and have a model API program I think other publishers should follow. This canyon is made even wider by the fact I live and work with notorious ed-tech trouble maker Audrey Watters who is not shy about sharing her hatred of Pearson.

In the end, I think my inner conflicts make for a better lense to see the API space through. I will keep sharing the good, the bad and the ugly as I see it. I really believe that Twitter is the second most important API around, and I can’t help but showcase what they are doing, while also holding them up as them up as the poster child of how to do it both right and wrong at the same time!



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/62GQIGBoDMg/