Tuesday, October 30, 2012

Postponing API Strategy and Practice in NYC Due to #sandy

Dear API Strategy Attendee,

As you know we've been tracking the weather events affecting New York. Up until now we've been hoping to run the event much as planned and working around the logistics issues that have come up.

We were hoping for better news this morning but the situation in New York is still very serious with extensive storm damage, mass-transit and airports with uncertain reopening times and in some areas there are still emergency rescue situations on-going. There has already been significant travel disruption and it looks set to get worse (none of the event team has yet been been able to get to New York and a number of speakers are already unable to fly).

As a result we've had to take the tough decision to postpone the event and not run it this week. It's very dissapointing for everybody we realize (not least the team) and we'd wanted to fight through and make everything work but as of this time:

- We don't think we'd be able to run much of the program and hence the event would
  not reach the great potential it had.

- There are safety concerns and for people traveling very possible serious travel chaos.

Lastly, people on the ground in the city likely have other things to focus on than the event - staying safe and securing everything.

So if you were planning to travel, please do not - the event won't take place unfortunately. However, this is a postponement and the event will definitely take place - we're committed to making it happen and making it happen in New York. We will get back to you with new dates and consultation in the next few days.

We will certainly work with speakers and sponsors to make sure the program is just as good and likely even better + we'll aim to do it as proximately as possible given people's logistics.

All tickets will remain valid for the new event when it runs, however if dates do not fit for you we will reimburse you. We'll keep you posted on that news.

Our apologies from the team that we've had to take this decision but we really see no other option. We'll be back with news as soon as we can on a new date / time / venue and in the meantime we hope everybody stays safe.

We thank everybody for the awesome support and advice -

Kin, Steve and Vanessa

from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/1U86Rem-5Hw/

Monday, October 29, 2012

API Developer Login Using Github

As with most social platforms, Github provides oAuth for their platform, allowing developers to provide secure credentials and authentication for their users via a Github account.

Service providers like Singly are providing two click authentication using Github's oAuth. This allows any website or app to offer their users the ability to login with their Github profile.

Allowing authentication via Github is no brainer for API providers. Why require users to create yet another login, or even use Twitter or Facebook oAuth? Allow them to login and retrieve API keys via the one social profile that reflects the programmer side of their online profile.

Github login can be implemented in any programming language, and because it is oAuth, it is something end users will understand. In addition to providing easy authentication, you will be able to immediately see other important data about a developer that is available via their Github profile.

Consider the potential of using Github authentication as part of your API strategy.

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

REST Web Services & API Security with Intel

When it comes to API service providers, there is one brand that I would say is widely known, but when we are talking about APIs, often gets overlooked. That company is Intel.

In addition to a whole suite of SOA and Cloud Middleware, all with an emphasis on security--Intel has a REST Web Services Gateway. This provides a simple solution to the number concern I get from potential API owners: How do I secure my API?

The Intel REST Web Services Gateway provides:

  • Invoke Security Token Service credential mapping or validation
  • Ensure throttling and SLAs by REST service
  • Extend Enterprise audit and compliance to WOA and REST
  • Detailed XML threat prevention and payload inspection
  • Service virtualization, proxy, and abstraction as a policy enforcement point
  • REST API security and management

You can find a summary of the product, a full data sheet, as well as some video tutorials over at Intel.

If you would like to know more, or have questions make sure and come to API Strategy & Practice this week in NYC. Intel will have a session on their approach to APIs, as well as be on a panel that I’ll be moderating on API service providers.  Intel is also a gold sponsor of API Strategy & Practice--the event wouldn't be happing if it wasn't for Intel.  Thanks!

If that isn’t enough! I will also be doing some workshops with Intel at the Gartner AADI conference in Las Vegas, the end of November.  So you will have another opportunity to speak with both of us.

If you can’t make to either New York or Las Vegas, drop me an email and I’ll get you in touch with Intel.

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

Sunday, October 28, 2012

Pearson Sets Example For Other Publishing APIs

One API I’ve been watching grow and evolve from day one is the Pearson Developer Community. I first wrote about them when Peasron announced a new initiative to build an API platform that give developers access to the publisher's content in May of 2011. Then in August 2011 they launched three APIs:

  • Longman Dictionary - The Longman Dictionary of Contemporary English is the flagship Longman dictionary
  • FT Press - FT Press provides essential insights from the best business books and original writings by leading business thinkers
  • Eyewitness Guides - The DK Eyewitness Travel Guides show you what others only tell you

After Pearson got acquainted with the ins and outs of API evangelism, and supporting the Pearson developer community, they released two more APIs this year:

  • Pearson Kitchen Manager - Pearson Kitchen Manager is a valuable resource for food enthusiasts and chefs alike, featuring a vast collection of recipes from bestselling Pearson textbooks of top culinary schools
  • Nursing & Health Survival Guides API - The best-selling Pearson Nursing & Health Survival Guide series is the UK's premier quick reference, aide memoire support for health and social care students and professionals while in practice and studying

It looks like Pearson is really finding a rhythm with identifying content to make available, as well as the right approach to deploying as APIs. They have 3 more high value publishing APIs available:

  • Penguin Classics API - The Penguin English Library is a collection of 100 of the best novels ever written in the English Language. Classics like Jane Eyre, Dracula and Great Expectations
  • dkimages API - The dkimages API is an encyclopaedic collection of 90,000 high-resolution images
  • Peachpit Visual QuickStart Guides API - With more than 12 million copies in print, Visual QuickStart Guides have been a vital part of the computer book category for years

That is a total of 8 APIs endpoints Pearson has made available via their developer center--providing some valuable text and image content that developers can use to build web and mobile apps.

What impresses me with Pearson is that they’ve found an efficient way to identify valuable assets within legacy inventory, part them out and expose these valuable parts and pieces as APIs. Essentially giving them a new life--driving web, mobile and tablet applications.

Pearson has deployed their developer center with all the essential API building blocks, while also executing an efficient API evangelism campaign around their APis, and delivering value to developers. It’s a commendable operation for such a big publisher.

If you are interested in hearing more about what Pearson is up to with their APIs, you can catch them at the API Strategy & Practice Conference this week in NYC. Pearson will be presenting as part of a media API session as well as helping sponsor the event, to make sure we can all get together an have these conversations.

from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/6XA1B-h5XrI/

API Code Samples via Gists

Code samples in a variety of languages are how API owners help developers understand an API in the language that makes the most sense to them.

Not all developers will understand REST, HTTP and other things you might take for granted. Very simple code samples will help demonstrate an APIs functionality, making the learning process a hands-on experience.

Github provides a very lightweight tool for publishing API code samples, that can be embedded on any website, called Gists. You can easily copy / paste a working code sample into a Gist and Github returns a lightweight, embeddable JavaScript that you can use in documentation, blog posts and any where you will need to share with users.

Github Gists can be a much sexier, and easier to implement alternative to html <code> tags. While also allowing easy management and versioning of API code samples alongside Github API SDK repositories.

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

Thursday, October 25, 2012

APIs Can Save Money and Make Government More Efficient

While I was out in Washington DC this week, one of the Presidential Innovation Fellows in my workshop was from the Department of Energy, and shared one of the best examples of APIs delivering value I’ve seen in awhile.

The US Department of Energy has developed the Bioenergy Knowledge Discovery Framework (KDF), which is a platform for researchers and engineers from national laboratories, academia, and private industries to upload files, customize information online, and exchange knowledge with each other.

The Bioenergy Knowledge Discovery Framework provides acess to a landmark “Billion-Ton” bioenergy study on fuel resources, providing a wealth of information from a variety of researchers. The study generated a large volume of interest, and resulted in numerous requests for raw data disclosure from the researchers.

In response the project deployed a web API, providing direct access to raw data, saving the resources necessary to reach out to researchers as well as the researchers valuable time in processing requests and providing data.

The US Department of Energy estimates they saved $882,000 in operational costs and researchers valuable time by bundling the API with the bioenergy study.

This is why I evangelize APIs. The US Department of Energy case study demonstrates not just the value of APIs, but how they can actually make government more efficient and save tax payers money.

In addition I strongly advocate that APIs and raw data access should be default for all studies and resulting reports, allowing anyone to dive deeper into the research and provide additional insights.

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

SDK Management for Your API with Github

The most common use of Github by API providers is to publish API SDK's to the popular social coding platform. If you look at most of the the top API providers in operation today, you will find they are actively using Github to not just manage and publicize their API SDK's, but actively interact with their developer ecosystem in the process.

Github provides the necessary workflow for initial design, development and publicizing of API SDKs, allowing owners to create separate repositories for web-based SDKs like PHP, Python and Ruby and mobile SDKs for iOS, Android and Windows mobile.

By making API SDK's public repositories on Github you get all the code management benefits of Github, but also make them available for social interaction by your developers. They will be able to download, fork and potentially commit additions and modifications back to an SDK's repository, allowing owners to harness the creative potential of the developer community.

Active Github repositories for an API are an essential part of any API ecosystem. If you don't use Github for anything else, make sure you publish your SDK's as a public repository. It will make the development of your client libraries a much more social experience, providing huge benefits for your API.

from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/pRHaZ-NCLgk/

Next Generation of API Service Provider: APIphany

I get so busy sometimes my stories pile up. Some only seeing the light of day when I get caught up on research, projects, travels and speaking. On story I’ve been meaning to write for almost 3 months now is about APIphany, one of the new generation of API providers. I met the APIphany team in person when I went out to Washington DC in August.

The APIphany team was cool enough to come out and support my API Craft meetup in DC, then the next morning I went out to their offices and met the rest of the team. APIphany sees the industry very similar to me, and believe in self-service, pay as you go API services that allow for anyone to innovate around APIs.

I’ve been watching their progress and they have 3 very cool projects made public so far:

  • Washington Post - Developer area for Washington Post, providing some endpoints including an Issue Engine API, White House Visitors Log API, and the Campaign Finance API
  • Houston Metro - Developer portal for the Houston area, providing public transit in the Houston metropolitan area for bus and rail
  • The Voting Information Project (VIP) - Offering APIs and developers tools to provide voters with access to customized election information, helping them navigate the voting process and cast an informed vote

When I met the team in August, they described how they were building out so many custom projects for customers that were API driven, they decided to standardize their approach and offer a product. The APIphany API management solution provides all the standard offerings we are getting used to in the space:

  • Administration Portal
  • Developer Portal
  • Key Management
  • Access Control and Security
  • Subscriptions and Billing
  • Monitoring
  • Analytics and Reporting

APIphany also gives you the ability to host the API in a variety of cloud providers, and my favorite is they provide you with an API to manage your API. The team has been building and managing web APIs for government, enterprise, and non-profit customers since 2006--so they get it.

APIphany is also supporting the API Strategy & Practice Conference in New York City, November 1st and 2nd. If you want to meet the team, you should make sure your there--if not just head over to apiphany.com to talk with them directly.

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

Wednesday, October 24, 2012

My Presentation to the Presidential Innovation Fellows

I spent two hours with a handful of the Presidential Innovation Fellows in Washington DC yesterday. They were some super savvy folks from a wide variety of agencies and backgrounds including education, energy and health.

During my two hours with them I walked through several areas of the API industry, from my perspective, including:

  • History of APIs
  • API Planning & Design
  • API Development
  • Business of APIs
  • API Service Providers
  • API Tools, Services, Platforms
  • Politics of APIs
  • API Evangelism
  • What’s Next for APIs

You can access my innovation fellows presentation off API Evangelist, I’ll leave it up permanently. It’s minus all my commentary and banter, but hopefully it will give you an idea of what I covered. If you’d like a custom presentation on it, let me know and I’ll see if I can find a slot to do a Google Hangout.

I had a blast talking to the Presidential Fellows, and I hope that I left them with some value that will help them be successful in their various initiatives. They are already halfway through their sprint, and have a lot of expectations put on them.

I will be following their progress closely and publish any stories I can on their progress.

from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/J-Y-LdTXQ5E/

A Hackathon Philosophy From Warren Wilbee of Microsoft

While doing the weekly hackathon roundup in September, I noticed an uptick in the number of Windows 8 hackathons that are going on. I decided to reach out to Microsoft and see if I can get more information on what they are trying to accomplish, and see what their perspective is on hackathons.

After talking to several people I was directed to a gentleman by the name of Warren Wilbee (@wwilbee), Director of ISV Evangelism at Microsoft. Wilbee is a passionate evangelist, one that isn't just externally evangelizing, he is actively working to evolve internal culture and options about the value of hackathons at Microsoft. When I got on the phone with him, he said the reason I was directed to him is because he had recently circulated an internal memo regarding the makeup and value of hackathons.

He feels strong that hackathons are very useful, you get the opportunity to get X number of people into a room, doing exactly what you want--delivering a very direct result. "Hackathons are purpose built", when you put on a hackathon for developers you get to define exactly what you, sending the desired message your company wants developers to receive, says Wilbee. By contrast, sponsoring a hackathon is a very different exercise and value proposition--proceed with caution. The hackathon organizer gets to define the purpose and drive the outcomes. The sponsor will not have access to this value, potentially excluding you from all the marketing or social "halo" produced at the event. Sometimes there are opportunities to offer a prize that will be in-line with the organizers purpose, but just flashing your logo will not deliver much value to your company.

When you do put on a hackathon, Wilbee is passionate about it being a "participatory event". Get your people to come and participate, don't just require them to show up, make it part of their responsibility to be involved. There is a social and community aspect to hackathons, "the shared experience of being in a room at 3am, committed to a common goal is a galvanizing, bonding experience." This is something you get by just showing up for a short period of time or just sponsoring an event.

In Wilbee’s opinion APIs and software platforms are here to stay, and hackathons do a great job educating people about the value they deliver. We will definitely see more organized efforts around these types of events, across many business sectors, in the future.

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

Version Control Your API Documentation with Github

Out of date API documentation is by far the most common mistake API providers make, and also the number one pain point for API developers. It makes sense that you will want to keep your API documentation in sync with each version of your API, and one way to handle this is to version them both, using Github.

To use Github for your API documentation, all you need to do is create an single public repository, which you can use to manage HTML versions of your API docs. By putting your API documentation in its own repository you can keep the version of the API code repository in sync with it's corresponding documentation.

With the API documentation in Github, you can then easily publish to your API area or just allow developers to go directly to the Github repository and browse documentation there.

To help you edit your API documentation, you can use tools like prose.io, which will allow even non-developers to assist in maintaining API documentation, with all changes stored neatly in a central Github repository.

Storing API docs in Github will also make them more portable. Some developers may wish to download a copy for offline work, or just prefer having locally for their own reference.

With the right approach to managing your API docs with Github, you can easily keep them up to date, in sync with your API, while also making them easily accessible by all API consumers--without much of the headache often associated with managing API documentation.

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

A Problem With Finding API Owners in Government

I had a great discussion with a friend who works in federal government yesterday. We were talking about various ways to “successfully” deploy APIs within the federal government. She gets APIs, understands the benefits, but she had some very realistic perspectives on where API deployment within the federal government can fail.

While discussing this with her, we kept coming back to two points:

  • API Garbage Littering the Internet - With some of the tools, making it easier to deploy APIs, the potential to just post meaningless and worthless data sets grows
  • Lack of API Ownership - There are big movements to get APIs deployed, but then very little ownership once its up.

Regarding worthless APIs being deployed, I think we can mitigate this by providing some sort of ranking or voting systems for APIs, allowing developers to upvote or downvote and add some critical feedback on what is right, or what is wrong. This will allow the “cream” to rise to the top, and everything else just disappear from view.

Next, her perspective on lack of API ownership after an API is launched, is a very big problem. It is something I see in the public sector all the time. Everyone gets excited about standing up an API, but once it’s in the wild, they lose enthusiasm--leaving the API to whither on the vine.

APIs will not succeed if they do not have an owner. For technology companies, it might make sense for them to have an API as a product, assemble a team and dedicate resources to the API.  Even hire an evangelist or advocate.

When it comes to government, maybe we need a different approach. A sort of personal API deployment platform like Socrata API Foundry, that will let anyone publish a dataset as API--allowing any individual to achieve "machine readable by default", as directed by President Obama back in May.

By empowering data owners within government to publish themselves, and give them the tools to handle the business of their APIs, and interact directly with consumers, maybe we can ensure APIs have an owner--one that cares about the data and truly understand the value it offers.

Just some quick thoughts, from a great conversation. I will flush out more ideas on this as soon as I can.

from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/9qAK3-XCo1o/

Monday, October 22, 2012

Alcatel-Lucent's Laura Merling at API Strategy & Practice

When 3Scale and I first decided to do the API Strategy & Practice Conference in New York, one of the first people I reached out to about speaking and sponsoring the event, was Laura Merling (@magicmerl), SVP Applications Enablement Platform and Strategy at Alcatel-Lucent.

As soon as I told her about the event, she said “We are in! What do we need to do, to support it!”

I’m stoked to have Laura kick off the event on Thursday, November 1st with a keynote as well as having Alcatel-Lucent as a gold sponsor.

If you’ve never heard Laura speak, I highly recommend making sure you are there. She always has great insight into the success Alcatel-Lucent is having within emerging markets and the telco space.  Also, her talks are always positive, energetic and demonstrate leadership in the space--something I want my daughter Kaia to experience.

During Laura’s keynote I’m sure we will here more about Alcatel-Lucent's new open source offering, API Grove, as well as their openly licensed API lifecycle and methodology.

Make sure you get registered today, before the event is sold out--there aren’t many tickets left.  I'll see you there.

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

Open Source Your API With Github

Github is a frequently used service in the toolbox of API owners. The most common use of Github is for publishing API SDKs in a variety of languages and platforms. But when it comes to truly being an "open API", some API owners are actually open sourcing their API design using Github.

Open sourcing the design of your API will not be sensible for every provider. Many companies are looking to ensure developers use their API, maintaining an advantage over competitors. However in some cases, open sourcing the design of your API is a way to ensure interoperability between partners or among mutliple companies within a certain business sector.

Simple examples of an API design might be for common systems like blogs, news, links, calendars or other API designs that don't deliver any sort of proprietary offerings. If you are looking to ensure synchronicity between say, the calendar of multiple organizations, developing a single API and open sourcing the design and possibly a version of it in multiple programming languages, might make sense.

With a consistent API design, and code to deploy the API, any organization can download or fork the Github code, deploy the API for themselves--ensuring consistency and interoperability between any deployment. If a single organizations has unique needs, they can extend and commit the code back to Github, allowing the central repository manager to decide if it is a change that should be added to the core offering.

Not all APIs are created equal.  Consider the possibility of actually open sourcing your API, the benefits it might bring to others, as well as your organization--they might exceed keeping it closed and proprietary.

This approach to using Github, is by far the truest meaning of the word, "Open API".

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

Saturday, October 20, 2012

The Right Partnership for the API Strategy & Practice Conference

The API Strategy & Practice Conference is kicking off in 12 days in New York City. The event will be keynotes, sessions and panels from over 60 leading individuals across all sectors of the API industry.

I’ve wanted to have an API industry event that was about ideas, practice and strategy, not just about companies, their products and clients for a while now. This is something that I could never achieve on my own. I just don’t have the money or all the connections to bring everyone together.

To make API Strategy & Practice happen it took the right partnership. That partnership is with API service provider 3Scale. The 3Scale team views the industry much like I do, that by openly educating people about the benefits of APIs and discussing the technical, business and political challenges we face in the industry--we can truly make change across all business sectors.  Allowing all of us to be succesful in whatever products and services we provide.

Through the regular discussion I have with the 3Scale team, we discovered our shared desire to have such an API industry event. We discussed what the event would look like, then quickly started figuring out what it would take to make it happen. We felt we both had resources necessary to pull it off, and even though there is a lot of risk, that it was something that had to happen, for the benefit of the industry.

Here we are, 8 weeks later, and the event is a reality. I just wanted to say thanks to 3Scale for not just sharing my vision of the API industry, but also partnering with me to make this event a reality. I hope all my readers can make it to the event and participate in the discussions about APIs, platforms, mobile, and how we can all work to solve the biggest challenges in the space.  This discussion will allow all of us to make significant change across all business sectors and at all levels of government using APIs.

Make sure you are there November 1st and 2nd in New York City for the API Strategy & Practice Conference, so your voice can be part of the solution.

Thanks 3Scale!

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

Monday, October 15, 2012

A 100% Open API Industry & Conference

When I set out to put on an API industry event in early 2012, I had grand visions of what it would be. Getting everyone together to discuss the best ideas, approaches the industry has to offer--while also discussing the critical topics such as open APIs, developer rights, monetization, etc.

Fast forward 10 months, and the event is a reality, and even though it doesn’t exactly look like I imagined, it is damn close--with lots of amazing API discussions.

After I announced the event has 60 speakers yesterday, I saw a tweet from Dave Winer (@davewiner):

Now for those of you who don’t read entire posts, I’m NOT going after Dave. We’ve already tweeted back and forth and discussed, and he is supportive. This post is about my feelings and thoughts on "open", and how we can all work together to make sure the industry is as open as possible.

First, I don’t see things as black and white. When it comes to politics, life or the API industry. To ability to snap our fingers and everything becomes open will not happen. It will be a lot of hard work and be very painful.

Next, I can honestly say there isn’t anyone else in the space who is dedicated to open APIs as much as I am. Sure Dave is much bigger name and has more history on this, but this is ALL I do. Period. I don’t work on anything else. It is my day and night job.

I have written constantly about the need for open API building blocks, open API billing and traffic control, all while constantly asking what open even means? My evangelism has helped guide two of the service providers in the space to deliver the first enterprise grade open source API products, from WSO2 and Alcatel-Lucent.  While these products aren't everything I want, they are a start.

I’m a firm believer in constantly discussing what “open” means. Is it free access, write capabilities, TOS, open source software under the hood, distributed technology, embracing open standards or is it just using the word, as many people feel comfortable with. Through these open and honest conversations, I firmly believe we’ll educate people and change their opinions one by one.

This is one of my goals at the API Strategy & Practice Conference. At first glance it is easy to think the event might appear to be a corporate API lovefest, but let’s scratch the surface a little bit:

  • Steve Klabnik - His keynote title is “Why Open?” 
  • Singly - I don’t know anyone who cares more about open access to personal data than Singly 
  • Swagger - Tony and the gang are building amazing open source tools that facilitate API development
  • Kirsten Jones - Kirsten’s talk on educating owners and devs about HTTP is critical to the standard being used consistently across industry 
  • Temboo & Webshell - These guys entire business rely upon open TOS allowing them to aggregate APIs and their existence provides real pressure for API owners to open up 
  • Hack Education - I’m biased here. But there is nobody in education working as tirelessly as my girlfriend Audrey Watters to open up data that is locked in education silos
  • Donors Choose - An online charity that provides open data and APIs to make classrooms better 
  • Seabourne - Seabourne has a suite of open source and open API products like Cumula that are transforming the government and making it more open and transparent
  • Digital Strategy - I will be showcasing all the open tools, data and API initiatives across federal agencies--spearheaded by the GSA

That is 10 out of 60 of the session and keynote speakers bringing open discussions to the table.  There are also three panels that are purposefully designed to discuss open:

  • Building Great APIs: Do’s and Don’ts 
  • API Business Models 
  • APIs Platforms and Business Model Tradeoffs

As you can see there will be plenty of "open" discussions at API Strategy & Practice--I’m sure I could extract more if I had time. I would love to be able to have a perfectly open API industry and perfectly open API event, where everyone agreed on what open was, widely used open standards and came together to truly make the industry the best it can be. But it doesn’t exist. We have to create it incrementally.

API Strategy & Practice took corporate sponsorship to make sure everyone has an event to come to. Then we got to work bringing together the best minds (yes some corporate running closed APIs), to work together and discuss all the issues across a multitude of industries. 

I’m 100% dedicated to the concept "open". I don’t work for any corporation, I’m 100% independent so that I can have the loudest, most unrestrained voice possible. And I am dedicated to making sure the event is about the community, ideas, strategy and real discussions about the toughest challenges we face in the space.

If you aren’t there, participating in these discussions, I’m afraid we are losing an important voice, and that is a lost opportunity. So please contact me if you wish to be there. I will make sure you get in.  Otherwise, you will miss your chance to convince some of the folks who might not see open, in the same way you do.

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

Sunday, October 14, 2012

A Rock'n Speaker Lineup for API Strategy & Practice

I finished updating the speaker lineup for the API Strategy & Practice Conference this weekend. While we still have a couple of panels to finalize and keynotes to announce, the speaker lineup is almost final.

We have spent almost 8 weeks reaching out to leaders across the API industry, soliciting submissions for keynotes, panels and sessions. It has been a lot of fun taking all the submissions and crafting the most compelling schedule as possible.

It was really important to me that we didn’t just discuss the common areas of the API industry, like service providers, REST, etc. Not that these aren’t relevant--they are! But I wanted to make sure we discuss some areas that are critical to the space, but do not get much airtime. Topics like API design and API life-cycle methodologies.

I feel it is also critical to discuss where we are going, by covering topics like API automation, aggregation and building of programming frameworks on top of numerous APIs--trends that will allow us leap forward in how we consume and build apps on top of APIs.

In the next two weeks I will be going through our lineup in detail and talking about the various API session tracks like music, social, payments, government and education to name a few prominent session areas.

While I started getting excited about this event back in August, it is really starting to get real. I’m really psyched about how this event has come together. There will only be 350-400 people at the event, so it’s going to be a very intimate opportunity for network with these API industry leaders.

Make sure and register for the API Strategy & Practice Conference ASAP, and I look forward to seeing you there.

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

Saturday, October 13, 2012

Does The Way I Look Make You Uncomfortable? Ok Now You're Ready for APIs!

I’ve been getting more comments lately about my appearance, as my API evangelism penetrates the enterprise and government. Specifically regarding my beard.

An executive at a leading API service provider reminded me the other day, that I will be the only one with a beard at the Gartner AADI event in November.

My appearance for me is natural. When I look in the mirror and I see my beard and long hair it feels more like me than the properly groomed version. It is also deliberate. I know it makes some people feel a little uncomfortable--but that is something you will need to accept.

As I see it, to play in this new world of web APIs you have to be able to accept being out of your comfort zone. APIs are about giving up a little control, in order to let in new ideas and innvoation.

As you can see in the before (2010) and after (2012) photo, back when I was VP of Technology at WebEvents Global and running SAP and Google events I played the game, but now as API Evangelist--not so much.

If my new look makes you a little uncomfortable, that is a good thing. It’s just a little taste of what it will take for you to leave your comfort zone and successful open up your companies assets and resources via APIs.

My goal isn’t to offend anyone, but make you think a little bit about what you are getting into. I hope you can quickly get past my appearance, hear what I have to say about APIs. I definitely have a lot more to say than I did in 2010 when I looked “normal”, and I think once you listen to my evangelism for a little--I’ll win you over.

If nothing else, I think you will at least remember me.  

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

Thoughts On Running a Successful Meetup From Jeremia Kimmelman of Mobile Mondays

As part of my research into how to create healthy developer communities, I've been spending time reaching out to organizers of developer meetups in different cities so I can get some insight into what it takes to successfully organize and run a developer meetup.

I recently spoke to Jeremia Kimelman (@jeremiak) of Tout, who runs Mobile Monday Developers. Jeremia took over the Mobile Monday Developers with the idea that he would create a meet up format where tech companies could reach out to developers in a non-spammy way. Companies could sponsor workshops and come in to deliver on topics like HTML5 or HTML5 vs Native Apps, and do it in a way that would add value to developers worlds.

This is a model that I'm sure many tech companies would drool over, and very often view meetups as a perfect medium for this type of sales pitch. As I reach out to meet up organizers I get the vibe that many of them already get solicited by companies in this fashion--either because they don't respond at all, or by being somewhat hostile to my questions about their meetup.

Jeremia was able to grow his meet ups from about 40 to 140 members with this model, but when I asked him if this was a model that could be replicated, he replied, "definitely not". It doesn't create value. It doesn't solve the problems developers face and ultimately will doom your meetup to failure.

As platform and API owners it's easy to drink our own kool-aid and think what we are offering is what developers want. Jeremia said it's easy to project your business understanding onto developers, and assume they are concerned with things like monetization and in-app payments, when in reality these things might be the furthest thing from their minds.

In an effort to truly deliver value to developers, Jeremia decided to pivot, working to better understand better how to make it a community owned event. By actually solving the problems developers face, making the event truly about learning and growth--not about what we perceive developers will need, and our products.

Not all developers are created equal. iPhone developers won't see things the same way as Android devs, and Windows mobile developers are going to have way different needs than others. "Don't try to be everything to everyone", said Jeremia.

To make it about developers and to introduce community into the meetup he is playing around with letting attendees share the problems they personally face as developers, letting the group openly discuss the problem, provide solutions and help each other learn and grow. This has the potential to bring value and community to the meetup in an organic way, not something that is imposed by him or a company.

As API or platform evangelists I think it's easy to be self-centered, making hackathons and meet ups all about us.  When in reality we should be actively working to just support developers as they are.  We need to work with them to understand the problems they face, and help them find solutions--even if the solutions are not our products and services.

In the end, if the developers are successful and we helped them get there. It will go a long way in building trust, something that can't be established when just evangelizing or selling our company to developers at meetups around the country.

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

Heading to Washington DC to Talk APIs with Innovation Fellows

I was honored this month to receive an invitation from Todd Park (@todd_park), the U.S. Chief Technology Officer, on behalf of the Presidential Innovation Fellows Program, to come out to Washington DC and spend an afternoon coaching and working with some of the Presidential Innovation Fellows on the Open Data Initiatives project.

The Presidential Innovation Fellows program brings together top innovators from the private sector, nonprofits, and academia with top innovators in government to collaborate on solutions that aim to deliver significant results in six months, while being supported by a broader community of interested citizens throughout the country.

The objective of the OpenData Initiatives are centered around:

Stimulating a rising tide of innovation and entrepreneurship that utilizes government data to create tools that help Americans in numerous ways

Working with the Innovation Fellows is just one areas I’m working to change the way our government works using APIs. I strongly feel that opening up our government, and evolving how it operates using web APIs is fundamental in bringing democracy into the 21st century.

While speaking with the Innovation Fellows I will cover the usual material I have published here on API Evangelist:

  • History of APIs - Brief overview of the modern web API movement
  • API Building Blocks - The essential building blocks to a successful API
  • API Service Providers - Roundup of the service providers who can help deploy APIs
  • API Tools - Pull together list of tools that can be used to design, deploy and manage APIs
  • Industries - Some of the top industries putting APIs to use
  • Hackathons - How hackathons are being used to drive innovation

My intentions are to help share everything I know with the fellows to make sure they are well equipped to execute as part of the OpenData Initiatives. APIs will be the underlying technology that stimulates innovation and the interface that allows Americans to develop tools that utilizes government data.

APIs won’t just be the underlying technology that drives this, the philosophies and methodologies that have fueled the current web API movement will be essential in changing culture in washington. APIs have the potential to allow federal agencies to take inventory of the rich data and content they posses, and open up government, making their day to day operations much more public, and a truly participatory process.

This process won’t be giving the folks who run our government another thing to learn or do, it will allow them share much of heavy lifting associated with day to day operations with the public, corporations and nonprofits--leaving them much more nimble to accomplish their core mission. APIs aren’t just about technology change, they are about cultural change, and have the potential to be the change we want to see in washington.

As I prepare my thoughts to go out to DC I wanted to put it out to my readers and see what you feel I should share with the Innovation Fellows about the API space. What do they need to know to make their six month iniatives as impactful as possible? How can I best distill down everything we’ve learned in the public space about openness, transparency and developer ecosystems, so they get the true essence of this movement?

Please share your thoughts below, tweet them @kinlane or email me directly at info@apievangelist.com

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

Friday, October 12, 2012

The API Evangelist Mission

Many folks who encounter API Evangelist think I'm working to evangelize a single API.  I field so many questions about this I thought I would address by publishing an API Evangelist mission statement. 

The mission of API Evangelist is to educate business, nonprofit and government leaders about the value of APIs to their organizations.

API Evangelist is made up of four properties:

With API Evangelist I strive to be the independent voice for the industry, providing the public with information about API:

The goal is to provide a wealth of resources for those looking to design, develop and deploy APIs without bias towards a specific platform--allowing them to make an educated choice about what path they should take.

To stay independent and operate API Evangelist, I need to bring in revenue, and keep things moving forward. I strive to do this in as healthy of a way as possible, without giving away control over my attention and focus, and contribute as much as possible to resources I provide to the public.

Areas I currently offer consulting services in are:


  • API Evangelism - Design and oversight of companies API evangelism efforts
  • Monetization Strategy - Design and oversight of a companies API monetization, business model and incubation approaches
  • Hackathons - Targeting, planning and execution of hackathons


  • Industry - Analysis of specific industries, API providers within and the opportunities available
  • Markets - Identifying and deeper understanding of evangelism opportunities within specific cities and countries
  • Developer Profiling - Targeting and profiling of developers within industries, markets and of specific, existing APIs
  • Providers - Providing a deeper understanding of how specific APIs operate their API operations


  • Webinars - Participating in webinars with companies and individuals
  • Conferences - Speaking and presenting at technology conferences
  • Meetups - Speaking and participating at local meetups
  • Workshops - Design and execution of workshops at existing events

All of these consulting areas are design to provide as much value to the client, while amplifying the signal and content via the four API Evangelist properties, and other syndication opportunities, under a creative commons license--enabling the public to consume and provide the greatest possible good for the API industry.

I feel strongly that a wealth of open resources will help ensure a fast growing and healthy industry by educating non-developers, non-technical business leaders about the benefits of APIs and healthy developer and partner ecosystem.

Please let me know how you can help support me in what I do, providing the industry with the information it needs to be successful, while also giving you what you need to successfully provide the services you offer.

This mission statement is a permanent fixture on my central kinlane.com site, it''s not just the API Evangelist mission, it is my mission.

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