RSS

API Evangelism News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.

How API Evangelist Works

I’ve covered this topic several times before, but I figured I’d share again for folks who might have just become readers int he last year. Providing an overview of how API Evangelist works, to help eliminate confusion as you are navigating around my site, as well as to help you find what you are looking for. First, API Evangelist was started in the summer of 2010 as a research site to help me better understand what is going on in the world of APIs. In 2017, it is still a research site, but it has grown and expanded pretty dramatically into a network of websites, driven by a data and a content core.

The most import thing to remember is that all my sites run on Github, which is my workbench in the the API Evangelist workshop. apievangelist.com is the front door of the workshop, with each area of my research existing as its own Github repository, at its own subdomain with the apievangelist domain. An example of this can be found in my API design research, where you will find at design.apievangelist.com. As I do my work each day, I publish my research to each of my domains, in the form of YAML data for one of these areas:

  • Organizatons - Companies, organizations, institutions, programs, and government agencies doing anything interesting with APIs.
  • Individuals - The individual people at organizations, or independently doing anything interesting with APIs.
  • News - The interesting API related, or other news I curate and tag daily in my feed reader or as I browse the web.
  • Tools - The open source tooling I come across that I think is relevant to the API space in some way.
  • Building Blocks - The common building blocks I find across the organizations, and tooling I’m studying, showing the good and the bad of doing APIs.
  • Patents - The API related patents I harvest from the US Patent Office, showing how IP is impacting the world of APIs.

You can find the data for each of my research areas in the _ data folder for each repository. Which is then rendered as HTML for each subdomain using Liquid via each Jekyll CMS driven website. All of this is research. It isn’t meant to be perfect, or a comprehensive directory for others to use. If you find value in it–great!! However, it is just my research laying on my workbench. It will change, evolve, and be remixed and reworked as I see fit, to support my view of the API sector. You are always welcome to learn from this research, or even fork and reuse it in your own work. You are also welcome to submit pull requests to add or update content that you come across about your organization or open source tool.

The thing to remember about API Evangelist is it exist primarily for me. It is about me learning. I take what I learn and publish as blog posts to API Evangelist. This is how I work through what I’m discovering as part of my research each day, and use as a vehicle to move my understanding of APIs forward. This is where it starts getting real. After seven years of doing this I am reaching 4K to 7K page views per day, and clearly other folks find value in reading, and sifting through my research. Because of this I have four partners, 3Scale, Restlet, Runscope, and Tyk who pay me money to have their logo on the home page, in the navigation, and via a footer toolbar. Runscope also pays me to place a re-marketing tag on my site so they can show advertising to my users on other websites, and Facebook. This is how I pay my rent, an how I eat each month.

Beyond this base, I take my research and create API Evangelist industry guides. API Definitions, and API Design are the two most recent editions. I’m currently working on one for data, database, as well as deployment, and management. These guides are sometimes underwritten by my partners, but mostly they are just the end result of my API research. I also spend time and energy taking what I know and craft API strategy and white papers for clients, and occasionally I actually create APIs for people–mostly in the realm of human services, or other social good efforts. I’m not really interested in building APIs for startups, or in service of the Silicon Valley machine. Even tough I enjoy watching, studying, and learning from this world, because there are endless lessons regarding how we can use technology in this community, as well as how we should not be using technology.

That is a pretty basic walk through of API Evangelist works. It is important to remember I am doing this research for myself. To learn, and to make a living. API Evangelist is a production, a persona I created to help me wade through the technology, business, and politics of APIs. It reflects who I am, but honestly is increasingly more bullshit than it is reality, kind of like the API space. I hope you enjoy this work. I enjoy hearing from my readers, and hearing how my research impacts your world. It keeps me learning each day, and from ever having to go get a real job. It is always a work in progress and never done. Which I know frustrates some, but I find endlessly interesting, and is something that reflects the API journey, something you have to get used to if you are going to be successful doing APIs in this crazy world.


Sharing Top Sections From Your API Documentation As Part Of Your Communications Strategy

I’m always learning from the API communication practices from out of the different AWS teams. From the regular storytelling coming out of the Alexa team, to the mythical tales of leadership at AWS that have contributed to the platform’s success, the platform provides a wealth of examples that other API providers can emulate.

As I talked about last week, finding creative ways to keep publishing interesting content to your blog as part of your API evangelism and communications strategy is hard. It is something you have to work at. One way I find inspiration is by watching the API leaders, and learning from what they do. An interesting example I recently found out of the AWS security team, was their approach to showcasing the top 20 AWS IAM documentation pages so far in 2017. It is a pretty simple, yet valuable way to deliver some content for your readers, that can also help you expose the dark corners of your API documentation, and other resources on your blog.

The approach from the AWS security team is a great way to generate content without having to come up with good ideas, but also will help with your SEO, especially if you can cross publish, or promote through other channels. It’s pretty basic content stuff, that helps with your overall SEO, and if you play it right, you could also get some SMM juice by tweeting out the store, as well as maybe a handful of the top links from your list. It is pretty listicle type stuff, but honestly if you do right, it will also deliver value. These are the top answers, in a specific category, that your API consumers are looking for answers in. Helping these answers rise to the top of your blog, search engine, and social media does your consumers good, as well as your platform.

One more tool for the API communications and evangelism toolbox. Something you can pull out when you don’t have any storytelling mojo. Which is something you will need on a regular basis as an API provider, or service provider. It is one of the tricks of trade that will keep your blog flowing, you readers reading, and hopefully your valuable API, products, services, and stories floating to the top of the heap. And that is what all of this is about–staying on top of the pile, keeping things relevant, valuable, and useful. If we can’t do that, it is time to go find something else to do.


Sharing Top Sections From Your Api Documentation As Part Of Your Communications Strategy

404: Not Found


Developing The Ability To Repeat The Same API Stories Over And Over

After seven years of telling stories on API Evangelist I’ve had to repeat myself from time to time. Honestly, I repeat myself A LOT. Hopefully I do it in a way that some of you don’t notice, or at least you are good at filtering the stories you’ve already heard from your feed timeline. My primary target audience is the waves of new folks to the world of APIs I catch with the SEO net I’m casting and working on a daily basis. Secondarily, it is the API echo chamber, and folks who have been following me for a while. I try to write stories across the spectrum, speaking to the leading edge API conversations, as well as the 101 level, and everything in between.

Ask anyone doing API evangelism, advocacy, training, outreach, and leadership–and they’ll that you have to repeat yourself a lot. It is something you get pretty sick of, and if you don’t find ways to make things interesting, and change things up, you will burn out. To help tell the same story over and over I’m always looking for a slightly different angle. Let’s take API Meetups as an example. Writing a story about conducting an API Meetup has been done. Overdone. To write a new story about it I’ll evaluate what is happening at the Meetup that is different, or maybe the company, or the speaker. Diving into the background of what they are doing looking for interesting things they’ve done. You have to find an angle to wrap the boring in something of value.

API documentation is another topic I cover over, and over, and over. You can only talk about static or interactive API documentation so much. Then you move into the process behind. Maybe a list of other supporting elements like code samples, visualizations, or authentication. How was the onboarding process improved? How the open source solution behind it simplifies the process. You really have to work at this stuff. You have to explore, scratch, dig through your intended topic until you find an angle that you truly care about. Sure, it has to matter to your readers, but if you don’t care about it, the chances of writing an interesting story diminishes.

This process requires you to get to know a topic. Read other people’s writing on the topic. Study it. Spin it around. Dive into other angles like the company or people behind. Spend time learning the history of how we got here with the topic. If you do all this work, there is a greater chance you will be able to find some new angle that will be interesting. Also, when something new happens in any topical area, you have this wealth of knowledge about it, and you might find a new spark here as well. Even after all that, you still might not find what you are looking for. You still end up with many half finished stories in your notebook. It is just the way things go. It’s ok. Not everything you write has to see the light of day. Sometimes it will just be exercise for the next round of inspiration. That hard work you are experiencing to find a good story is what it takes to reach the point where you are able to discover the gems, those stories that people read, retweet, and talk about.


Tyk Is Conducting API Surgery Meetups

I was having one of my regular calls with the Tyk team as part of our partnership, discussing what they are up to these days. I’m always looking to understand their road map, and see where I can discover any stories to tell about what they are up to. A part of their strategy to build awarness around their API management solution that I found was interesting, was the API Surgery event they held in Singapore last month, where they brought together API providers, developers, and architects to learn more about how Tyk can help them out in their operations.

API surgery seems like an interesting evolution in the Meetup formula. They have a lot of the same elements as a regular Meetup like making sure there was pizza and drinks, but instead of presentations, they ask folks to bring their APIs along, and they walk them through setting up Tyk, and deliver an API management layer for their API operations. If they don’t have their own API, no problem. Tyk makes sure there are test APIs for them to use while learning about how things work. Helping them understand how to deliver API developer onboarding, documentation, authentication, rate limiting, monitoring, analytics, and the other features that Tyk delivers.

They had about 12 people show up to the event, with a handful of business users, as well as some student developers. They even got a couple of new clients from the event. It seems like a good way to not beat around the bush about what an API service provider is wanting from event attendees, and getting down to the business at hand, learning how to secure and manage your API. I think the Meetup format still works for API providers, and service providers looking to reach an audience, but I like hearing about evolutions in the concept, and doing things that might bring out a different type of audience, and cut out some of the same tactics we’ve seen play out over the last decade.

I could see Meetups like this working well at this scale. You don’t need to attract large audiences with this approach. You just need a handful of interested people, looking to learn about your solution, and understand how it solves a problem they have. Tyk doesn’t have to play games about why they are putting on the event, and people get the focus time with a single API service provider. Programming language meetups still make sense, but I think as the API sector continues to expand that API service provider, or even API provider focused gatherings can also make sense. I’m going to keep an eye on what Tyk is doing, and look for other examples of Meetups like this. It might reflect some positive changes out there on the landscape.

Disclosure: Tyk is an API Evangelist partner.


How Do We Help Folks Understand That APIs Are A Journey?

I was hanging out with my friend Mike Amundsen (@mamund) in Colorado last month and we ended up discussing folks uncertainty with APIs. You see, many folks that he has been talking to were extremely nervous about all the unknowns in the world of APIs, and were looking for more direction regarding what they should be doing (or not doing). Not all people thrive in a world of unknown unknowns, and not even in a world of known unknowns. Many just want a world of known knowns. This is something that makes the API landscape a very scary thing to some folk, and world where they will not thrive and be successful unless we can all begin to find a way to help them understand that this is all a journey.

I love figuring all of this API stuff out, and I know Mike does too. We like thinking about the lofty concepts, as well as figuring out how to piece all the technical elements together in ways that work in a variety of business sectors. Many folks we are pushing APIs on aren’t like us, and just want to be told what to do. They just want the technology solution to their problem. A template. A working blueprint. It freaks them out to have so many options, possibilities, patterns, and directions they take things. I feel like we are setting folks up for failure when we talk them into embarking on an API journey without the proper training, equipment, support, and guidance.

I think about the last seven years doing this, and how much I’ve learned. Realizing this makes me want to keep doing APIs, just so I can keep learning new things. I thought I understood REST when I started. I didn’t. I thought I understand the web when I started, I didn’t (still don’t). I was missing a lot of the basics, and no matter what folks told me, or how precise their language was, I still needed to bang my head on something over and over before I got it. I was missing a significant amount of why hypermedia can be a good approach without truly understanding content negotiation, and link relations. Realizing how much I still need to explore and learn has only emboldened me on my journey, but I’m not convinced this will be the case with everyone. We are wrong to assume everyone is like us.

As technologists and autodidacts we often overestimate our own ability, as well as what others are capable of. We realize APIs are not a destination, but a journey. However, we suck at explaining this to others. We are horrible at understanding all of the stepping stones that got us here, and recreating them for others. I put myself into this group. I think about this stuff full time, and I still regularly stumble when it comes to on-boarding folks with what API are, and properly helping them in their journey. I still do not have a proper set of on-boarding lessons for folks, beyond my API 101 stuff. I talk a lot of talk about the API life cycle, the API economy, and all the business and politics of APIs, but I still can’t point folks to where the yellow brick road is. We have to get better at this if we expect folks to ever catch up.

This is one reason I feel Zapier, and other iPaaS providers are so important. We should be helping people understand APIs and integration in context of the problems they are trying to solve, not in terms of REST, SDKs, or any of the other technical jargon we spew. With Zapier, folks can play with Zaps (recipes) that deliver meaningful API integration that actually solve a problem in their world. They can play with what is possible, without learning all the technical pieces first. They can evolve in their business world, while also progressing on their API journey. IDK. I’m just trying to find ways to help folks better understand what APIs are. I’ll never make everything known to them, but I’m hoping that I can help make folks a little less nervous about the known unknowns, and who knows maybe some day they’ll feel brave enough, and confident in their API awareness that they’ll be able to operate in a world of the unknown unknowns, and settle in on the perpetual journey that are APIs.


Concerns Around Working With The API Evangelist At Large Organizations

I know that I make some tech companies nervous. They see me as being unpredictable, with no guarantees regarding what I will say, in a world where the message should be tightly controlled. I feel it in the silence from many of the folks that are paying attention to me at large companies, and I’ve heard it specifically from some of my friends who aren’t concerned with telling me personally. These concerns keep them from working with me on storytelling projects, and prevent them from telling me stories about what is happening internally behind their firewall. It often doesn’t stop employees from telling me things off the record, but it does hinder official relationships, and on the record stories from being shared.

I just want folks to know that I’m not in the scoop, or gotcha business. I only check-in on my page views monthly to help articulate where things are with my sponsors. I’m more than happy to keep conversations off the record, anonymize sources and topics. Even the folks in the space who have pissed me off do not get directly called out by me. Well, most of them. I’ve gone after Oracle a couple of times, but they are the worst of the worst. There are other startups and bigcos who I do not like, and you don’t ever hear me talking trash about them on my blog. Most of my rants are anonymized, generalized, and I take extra care to ensure no enterprise egos, careers, or brands are hurt in the making of API Evangelist.

If you study my work, you’ll see that I talk regularly with federal government agencies, and large enterprise organizations weekly, and I never disclose things I shouldn’t be. If you find me unpredictable, I’m guessing you really haven’t been tuning into what I’ve been doing for very long, or your insecurities run deeper than anything to do with me. I’m not in the business of making folks look bad. Most of the companies who are looking bad in the API space do not need my help, they excel at doing it on their own. I’m usually just chiming in to help amplify, and use as a case study for what API providers should consider NOT DOING in their own API operations. Sure, I may call you out for your dumb patents, and the harmful acquisitions you make, but anything I rant about is going to already be public material–I NEVER do this with private conversations.

So, if you are experiencing reservations about sharing stories with me, or possibly sponsoring some storytelling on API Evangelist because you are worried about what will happen, stop fretting. If you are upfront with me, clear about what is on the record, and what is off, and honest about what you are looking to get out of the relationship, things will be fine. Even if they end up being rocky, I’m not the kind of person to call you out on the blog. I may complain, rant, and vent, but you can look through seven years of the blog and you won’t find me doing that about anyone I’ve specifically worked with on storytelling projects. I don’t always agree with why corporations, institutions, and government agencies are so controlling of the message around their API operations, but I will be respectful of any line you draw for me.


I Am Not A Card Carrying Restafarian I Just Believe In The Web

I am always surprised at the folks who I meet for the first time who automatically assume I’m all about the REST. It is always something that is more telling about the way they see the world (or don’t), than it ever is about me as THE API Evangelist. It is easy to think I’m going to get all RESTY, and start quoting Roy, but I’m no card carrying RESTafarian, like my buddy Darrel Miller (@darrel_miller) (not that is what Darrel does ;-). Really the only thing I get passionate about is making sure we are reusing the web, and I am pretty much be a sellout on almost everything else.

I am just looking to understand how folks are exposing interfaces for their digital resources using the web, making them available for use in other applications. I feel like RESTful approaches are always a good start for folks to begin considering, and learning from when beginning their journey, but I’m rarely going to get all dogmatic about REST. There are trade-offs with any approach you take to providing programmatic interfaces using the web, and you should understand what these are whether your are using REST, Hypermedia, (g)RPC, GraphQL, or any other number of protocols and technologies available out there. A RESTful approach using the web just tends to be the lowest common denominator, the cheapest, and widest reaching solution we have on the table. Rarely is it ever the perfect solution–there are no such things. #sorry

If you are entering into discussions with me thinking I’m 100% team REST, you are mistaken, and you have profiled yourself considerably for me. It shows me that you haven’t done a lot of (wide) reading on the subject of APIs, and while you may be an expert, you probably are a very siloed expert who doesn’t entertain a lot of outside opinions, and keep an eye on how the space is shifting and changing. When I encounter folks like you in the space you’ll often find me pretty quiet, submissive, and just nodding my head a lot. As you aren’t my target audience, and there isn’t much I can say that will shift your world view. Your opinions are pretty set, and I’m not going to be the one who moves them forward. My role is to reach folks are looking for answers, not those who already have them.


What APIs Excite Me And Fuels My Research And Writing

I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.

The number API that gets me out of bed each day, with an opportunity to apply what I’ve learned in the API sector is with the Human Services Data API (HSDA). Which is an open API standard I am the technical lead for which helps municipalities, and human service organizations better share information that helps people find services in their communities. This begins with the basics like food, housing, and healthcare, but in recent months I’m seeing the standard get applied in disaster scenarios like Hurricane Irma to help organize shelter information. This is why I do APIs. The project is always struggling for funding, and is something I do mostly for free, with small paychecks whenever we receive grants, or find projects where we can deliver an actual API on the ground.

Next, I’d say it is government APIs at the municipal, state, but mostly at the federal levels. I was a Presidential Innovation Fellow in the Obama administration, helping federal agencies publish their open data assets, take inventory of their web services. I don’t work for the government anymore, but it doesn’t mean the work hasn’t stopped. I’m regularly working on projects to ensure RFPs, and RFIs have appropriate API language in them, and talking with agencies about their API strategy, helping educate them what is going on in the private sector, and often times even across other government agencies. APIs like the new FOIA API, Recreational Information Database API, Regulations.gov, IRS APis, and others will have the biggest impact on our economy and our lives in my opinion, so I make sure to invest a considerable amount of time here whenever I can.

After that, working with API education and awareness at higher educational institutions is one my passions and interest. My partner in crime Audrey Watters has a site called Hack Education, where she covers how technology is applied in education, so I find my work often overlapping with her efforts. A portion of these conversations involve APIs at the institutional level, and working with campus IT, but mostly it about how the Facebook, Twitter, WordPress, Dropbox, Google, and other public APIs can be used in the classroom. My partner and I are dedicated to understanding the privacy implications of technology, and how APIs can be leveraged to give students and faculty more control over their data and content. We work regularly to tell stories, give talks, and conduct workshops that help folks understand what is possible at the intersection of APIs and education.

After that, I’d say the main stream API sector keeps me interested. I’m not that interested in the whole startup game, but I do find a significant amount of inspiration from studying the API pioneers like SalesForce and Amazon, and social platforms like Twitter and Facebook. As well as the cool kids like Twilio, Stripe, and Slack. I enjoy learning from these API leaders, studying their approaches, but where I find the most value is sharing these stories with folks in SMB, SME, and the enterprise. These are the real-world stories I thrive on, and enjoy retelling as part of my work on API Evangelist. I’m a technologist, so the technology of doing APIs can be compelling, and the business of doing this has some interesting aspects, but it’s mostly the politics of doing APIs that intrigues me. This primarily involves the politics of the humans involved within a company, or industry, providing what I always find to be the biggest challenges of doing APIs.

In all of these areas, what actually gets me up each day, is being able to tell stories. I’ve written about 3,000 blog posts on API Evangelist in seven years. I work to publish 3-5 posts each weekday, with some gaps in there due to life getting in the way. I enjoy writing about what I’m learning each day, showcasing the healthy practices I find in my research, and calling out the unhealthy practices I regularly come across. This is one of the reasons I find it so hard to take a regular job in the space, as most companies are looking to impose restrictions, or editorial control over my storytelling. This is something that would lead to me not really wanting to get up each day, and is the number one reason I don’t work in government, resulting in me pushing to make change from the outside-in. Storytelling is the most important tool in my toolbox, and it should be in every API providers as well.


Who Are The Most Influential People And Companies To Keep An Eye On In API Space

I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.

When it comes to the most influential people and companies in the API space that I am keeping an eye on, it always starts with the API pioneers. This begins with SalesForce, eBay, and Amazon. Then it moves into the social realm with Twitter and Facebook. All of these providers are still moving and shaking the space when it comes to APIs, and operating viable API platforms that dominate in their sector. While I do not always agree with the direction these platforms are taking, they continue to provide a wealth of healthy, and bad practices we should all be considering as part of our own API operations, even if we aren’t doing it at a similar scale.

Secondarily, I always recommend studying the cloud giants. Amazon is definitely the leader in this space, with their pioneering, first mover status, but Google is in a close second, and enjoys some API pioneering credentials with Google Maps, and other services in their stack. Even though Microsoft waiting so long to jump into the game I wouldn’t discount them from being an API mover and shaker with their Azure platform making all the right moves in the last couple of years as they played catch up. These three API providers are dictating much of what we know as being APIs in 2017, and will continue to do so in coming years. They will be leading the conversation, as well as sucking the oxygen out of other conversations they do not think are worthy. If you aren’t paying attention to the cloud APIs, you won’t remain competitive, no matter how well you do APIs.

Next, I always recommend you study the cool kids of APIs. Learning about how Twilio, Stripe, SendGrid, Keen, Stripe, and the other API-first movers and shakers are doing what they do. These platforms are the gold standard when it comes to how you handle the technical, business, and politics of API operations. You can spend weeks in their platforms learning from how they craft their APIs, and operate their communities. These companies are all offering viable resources using web APIs, that developers need. They are offering these resources up in a way that is useful, inviting, and supportive of their consumers. They are actively investing in their API community, keeping in sync with what they are needing to be successful. It doesn’t matter which industry you are operating in, you should be paying attention to these companies, and learning from them on a regular basis.


What Is The Role Of An Influencer In The API Industry?

I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.

The idea of an influencer in the API space will mean many things to many different people. I have pretty strong opinions about what an influencer should do, and it is always something that should be as free of product pitches as it possibly can. Influencing someone in the API space should mean that you are just influencing their decision to buy your product or service. That is sales, which has it’s place, but we are talking about influencing. I would also add that influencing SHOULD NOT be steeped in convincing folks regarding what they should invest in, at the technology purchasing level, all the way up to the venture capital level. The role of an influencer in the API industry should always be about education, awareness, and helping influence how average flks get everyday problems solved.

Being an influencer always begins with listening and learning. We are not broadcasting or pitching, we want to influence, so we need to have an idea about who we are influencing, and what will resonate and help them solve the problems they face. I do a significant portion of this by reading blogs, tuning into Twitter, and spending time on Github understanding what folks are building. Next, I engage in conversations with folks who are doing APIs, looking to understand APIs, and listening to what their challenges are, and what matters to them. At this stage I am not influencing anyone. I am being influenced. I’m absorbing what is going on, educating myself about what the problem set looks like, and better understanding my potential audience, when and if I get around to doing some of that influencing.

With a better understanding of an industry, a specific audience, and potentially the problems and challenges faced with doing APIs, I will usually step back from APIs entirely. I want to better understand the industry outside of just doing APIs. I want to understand the companies, organizations, instutions, and potentially government influence on what is happening. Everything that is already going on often weighs on doing APIs way more than the technology will ever by itself. I’m looking to understand the business and politics of operating in any sector before I will ever begin doing any sort of influencing within an industry, and to any specific audience. In technology circles, I find that many of us operate within silos, with our blinders on, and don’t always understand the scope of the problem we are looking to provide API solutions for. Stepping back is always healthy.

Once I’ve done my research, engaged in conversations with folks in an area I’m looking to influence, I’ll begin to write stories on the blog. This is all just exercising and training for the white papers, guides, workshops and talks I will be giving in any area I’m trying to influence. I will do this for months, repeating, reworking my ideas, and developing my understanding. The process usually brings more people out of the woodworks, opening up even more conversations, and influencing my industry, but also potentially adding to the number of folks I will be influencing. Slowly I will build the knowledge and awarness needed to truly be able to influence people in any industry, ensuring I have the platform of knowledge I will need, and grasp the scope of the challenges and problems we will be looking to deliver API solutions for.

The role of an API influencer is always a two-way street. You should be influenced just as much, or more than you are influencing. You should be working with influencers to understand your challenges. Tell us your stories, even if they are confidental. Help us understand your industries, and the unique problems and challenges that exist in there. Invest in us listening to your stories, and us telling your story on our blogs, and other longer form content. This is how we’ll help work through what is going on, and find the right path for your API journey. We can bring a lot of value to your API operations, and help you work through the challenges you face. This isn’t about content creation, or simply workshops, training, white papers, and public speaking. This is about influencing, and making an impact. You can’t do this without truly knowing what is going on, and being able to intelligently speak what is going on. This takes time, practice, investment, and actually giving a shit. It is something not everyone can pull off.


What It Was About Web APIs That First Captured My Attention

<img src="http://s3.amazonaws.com/kinlane-productions/api-evangelist/t-shirts/KL_InApiWeTrust-1000.png" align="right" width="40%" style"padding: 15px;" />

I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.

In the spring of 2010 I was ready for a career shift. I was running North American event for SAP, and had also taken up running events for Google, which included Google I/O and Developer Days. I was the VP of Technology, and made all the decisions around usage of tech, from email blasts, to registration, session scanning, and follow-up reporting. When I took over the role I was dealing with a literal hostage colocation facility for server infrastructure, and massive hardware expenditure on servers that I didn’t need most of the year. Then in 2007 I began using the Amazon Cloud, and got to work re-engineering systems to be more API-centric, leverage AWS APIs to orchestrate my operations.

By 2007 I had been playing around with web APIs for some time. I had incorporated payment and shipping APIs into commerce systems, and integrated Flickr, Delicious, Twitter, Facebook and other APIs into applications. I had plenty of SOAP web service experience when it came to enterprise infrastructure, but this was the first time I was deploying global infrastructure at scale using web APIs. I realized that web APIs weren’t just hobby toys, as my SAP IT director in Germany called them, they were an actual a tool I could use to operate a business at scale. My success resulted in more work, taking on more events, and scaling operations, which didn’t always pencil out to me actually being happier, even though the events scaled more efficiently, and out-performed what had come before.

The two Google I/O events where I managed the technology were the first ones where Google gave away their new Android mobile phones. I saw first hand what was happening in the mobile market, with the growth of the iPhone, and everyone scrambling to deploy APIs to support the new applications their were developing. Now, I was also beginning to develop new APIs to support what was possible via Android devices. It was clear that web APIs were going to be the preferred way to deliver the resources needed on mobile phones, and by 2010 there was no doubt that this mobile thing was going to be around for a while. Both SAP and Google were pushing on us to deliver resources that could be used on mobile platforms across all the events we were managing, and I saw that web APIs were how we would do this at scale.

I was using web APIs to deliver compute, storage, and other essential infrastructure to support global events. I was also using web APis to deliver resources to iPhone applications, and now Android applications. I wanted to better understand how this was being done, so in 2010 I began studying the world of APIs, looking at the common approaches to delivering APIs. I quickly saw there were plenty of pundits discussing the technical details of doing APIs, and I decided that I would focus on the business of doing APIs, and specifically how I can help convince business leaders to understand the potential. By summer of 2010 I had settled in on the name of my research blog, and by October I was beginning to publish my research on the blog. Seven years later, 3,000 blog posts later, I’m still doing it, and enjoy the focus on this important layer of not just the web, cloud, and mobile, but how APIs are being used in devices, on the network, and for bots, voices, and other conversational applications.


Azure Matching AWS When It Comes To Serverless Storytelling

I consume a huge amount of blog and Twitter feeds each week. I evaluate the stories published by major tech blogs, cloud providers, and individual API providers. In my work there is a significant amount of duplicity in stories, mostly because of press release regurgitation, but one area I watch closely is the volume of stories coming out of major cloud computing providers around specific topics that are relevant to APIs. One of these topics I’m watching closely is the new area of serverless, and what type of stories each providers are putting out there.

Amazon has long held the front runner position because AWS Lambda was the first major cloud provider to do serverless, coining the term, and dominating the conversation with their brand of API evangelism. However, in the last couple months I have to say that Microsoft is matching AWS when it comes to the storytelling coming out of Azure in the area of serverless and function as a service (FaaS). Amazon definitely has an organic lead in the conversation, but when it comes to the shear volume, and regular drumbeat of serverless stories Microsoft is keeping pace. After watching several months of sustained storytelling, it looks like they could even pass up Amazon in the near future.

When you are down in the weeds you tend to not see how narratives spread across the space, and the power of this type of storytelling, but from my vantage point, it is how all the stories we tell at the ground level get seeded, and become reality. It isn’t something you can do overnight, and very few organizations have the resources, and staying power to make this type of storytelling a sustainable thing. I know that many startups and enterprise groups simply see this as content creation and syndication, but that is the quickest way to make your operations unsustainable. Nobody enjoys operating a content farm, and if nobody cares about the content when it is being made, then nobody will care about the content when it is syndicated and consumed–this is why I tell stories, and you should to.

Stories are how all of this works. It is stories that developers tell within their circles that influence what tools they will adopt. It is stories at the VC level that determine which industries, trends, and startups they’ll invest in. Think about the now infamous Jeff Bezos mandate, which has been elevated to mythical status, and contributed to much of the cloud adoption we have seen to date. It is this kind of storytelling that will determine each winner of the current and future battles between cloud giants. Whether it is serverless, devops, microservices, machine learning, artificial intelligence, internet of things, and any other scifi, API-driven topic we can come up with in the coming years. I have to admit, it is interesting to see Microsoft do so well in the area of storytelling after many years of sucking at it.


API Evangelist Is A Performance

I think I freaked a couple of folks out last week, so I wanted to take a moment and remind folks that API Evangelist is a performance. Sure, it is rooted in my personality, and I keep it as true to my view of the world of APIs as I can, but it is just a performance I do daily. When I sit down at the keyboard and research the world of APIs I am truly (mostly) interested in the technology, but when I craft the words you read here on the blog I am performing a dance that is meant to be interesting to the technology community in a way that draws them in, but then also gives them a swift kick in the pants when it comes to ethics of the technology, business, and politics of doing all of this.

Sure, my personality shines through all of this, and I’m being genuine when I talk about my own battles with mental illness, and other things, but please remember API Evangelist is a performance. It is a performance that is meant to counteract the regular stream of fake news that comes out of the Silicon Valley funded technology machine. API Evangelist is a Contrabulist production, pushing back on the often exploitative nature of APIs. Not that APIs are exploitative, it is the people who are doing APIs are exploitative. Back in 2010, I saw that APIs were providing a peek behind the increasingly black box nature of web technology that was invading our lives through our mobile devices, and jumped at the opportunity to jam my foot in the door, even as the VC power brokers continue to look to look for ways to close this door.

In 2011, I found my voice as the API Evangelist explaining APIs to the normals, making these often abstract things more accessible. Along the way, I also developed the tone of this voice pushing back on the politics of doing APIs, calling out the illnesses I see in the space. These are the two areas I hear the most praise from my readers, something that has significantly shaped my performance over the last seven years. I have a pantheon of API characters in my head when I tell stories on API Evangelist, speaking to specific groups, while showcasing as many of the best practices from the space as I possibly can. I’m looking to shine a light on the good, first and foremost, but I’m also never going to shy away from showcasing the illnesses in the space as I have nothing to lose. I’m never looking to get VC funding, or do any technology startup, so throwing myself against the machine doesn’t ever worry me–I will keep doing it until I grow weary of this production.

I just wanted to take the time to help folks understand that all of this is a show. Sure, my rant last week was rooted in my own dark personal thoughts, but it was meant to be a reflection of the space (your darkness). I’m touched at the folks who reached out to me with concern, but I’m fine. If I am ranting on the Internet you can always be sure I’m fine. It is when I go silent for any sustained amount of time is when you should have concern. When I’m in my dark place I have NO interest in performing as API Evangelist, and increasingly I have little interest in Internet technology when I feel this way. If you are reading this, thank you for tuning into my little production. I enjoy doing it because it keeps me learning each day. It keeps me writing and telling stories each day. Hopefully along the way some of you also get some value from the stories I tell, whether their are positive, or a little dark like they were last week.


The Fact That You Do Not Know Who I Am Shows You Live In A Silo

Don’t who know who I am? I am the API Evangelist. Ok, I know this post is dripping with ego. However, it is the last post in my week of API rants, and I’m just pumped from writing all of these. These types of posts are so easy to write because I don’t have to do any research, and real work, I just write, putting my mad skills at whitesplaining and mansplaining to work–tapping into my privilege. So I’m going to end the week with a bang, and fully channel the ego that has developed along with the persona that is API Evangelist.

However, there is a touch of truth to this. If you are operating an API today, and you do not know who I am, I’m just going to put it out there–you live in a silo. I have published around 3,000 blog posts since 2010 on APIs. I’m publishing 3-5 posts a day, and have consistently done so for seven years. There are definitely some major gaps in that, but my SEO placement is pretty damn good. You type API or APIs, and I’m in the top 30 usually, with the occasional popping up on home page. The number thing I get from folks who message me is that they can’t search for anything API without coming across one of my posts, so they want to talk to me. So why is it that you do not know who I am? I have some ideas on that.

It is because you do not read much outside your silo. When you do, you don’t give any credit to authorship. So when you have read any of my posts you didn’t associate them with a person named Kin Lane. You operate within your silo 98% of the time, and the 2% you get out, you really don’t read much, or learn from others. I on the other hand spend 98% of my time studying what others are doing, and 2% hiding away. My goal is to share this with you. I’d say 75% of my work is just referencing and building on the work of others, only 25% is of my own creation. I’m putting all of this out there for you, and you don’t even know it exists. What does that tell you about your information diet? It tells me that you probably aren’t getting enough exercise and nutrients as part of your regular daily intake, that will make your API operations be less healthy and strong–reading is good for healthy bones girls and boys!

Kin Lane doesn’t have this much ego, but API Evangelist does. The fact that you don’t know who I am shows you aren’t spending enough time studying the API space before launching an API. I’m hoping that you in your API journey you learn more about the importance of coming out of your bubble, and learning from your community, and the wider API community. It is why we do APIs, and why APIs work (when they do). I wrote this title to be provocative and part of my week of rants, but honestly it is true. If you haven’t come across one of my API posts, and stumbled on my blog at some point you should probably think about why this is. The most successful API providers and evangelists I know are tuned into their communities, industries, and wider API space, and are familiar with my work–even if they don’t all like me. ;-)

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.


You Have No API Imagination, Creativity, Or Sensibility

I know you are used to people telling you that you are creative, and your ideas are great, but I’m here to tell you they aren’t. You lack any imagination, creativity, or sensibility when it comes to your APIs. Some of it is because you are personally lacking in these areas, part of it is because you have no diversity on your team, but it is mostly because you all are just doing this to make money. As creative as you think doing a startups is, they are really just about making money for your bosses, and investors–not a lot of imagination, creativity, or sensibility is required.

You could invest the time to come up with good ideas for applications and stories on your blog, but you really don’t want to do the work, or even stand out in the group. It is much easier to just phone it in, follow the group, and let your bosses and the existing industry trends dictate what you do each day. If the business sector you operate within is doing it, you are doing it. If you see something funny online or at a conference you will do it. You have a handful of blogs you read each weekend, that you will rewrite the best posts from and publish on your own blog. Your Twitter account is just retweeting what you find, and you don’t even push out your own stories, because you have already tweeted out the story you copied in the first place.

Don’t beat yourself up about this, you come by it honestly. Your privilege affords you never really getting out of your comfort zone, and the people around you make you feel good enough. Everyone on your team is the same, and your bosses really don’t care, as long as you are just creating content, and sending out all the required signals. Just make it look like you are always busy, and keep all the channels active. You don’t actually have to support your API consumers, just make sure you are having conversations with them on forums, and the channels your boss can keep an eye on. Doing too much will make you a target. Keep an eye on your coworkers and never do anymore than they are, establishing a kind of solidarity of mediocrity. This isn’t rocket surgery, its API theater.

You know deep down that you have some creativity in there, but it is something that has never been encouraged. This is the damaging effects of your privileged world. Your parents, teachers, bosses, and friends never push you, and neither do you. You don’t have to. If this story pisses you off, you really have nobody to blame. You’ve never had to work hard. You have never pushed yourself to do any of the hard work required to fail, on the path to becoming creative, developing your sensibility, and honing your imagination. How are you ever going to know what you are capable of if you do not put yourself out there. Creativity isn’t created in a silo. People aren’t just born with sensibility. And API aren’t lacking in imagination by default. There are many APIs operating out there that possess all these characteristics, and are leading the conversation–why aren’t you one of them?

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.


Holding Little Guys More Accountable Than We Do VCs And Bigcos

I spend a lot of time defending my space as the API Evangelist. I’ve had lengthy battles with folks in the comments of my blog for defending women, charging for my services, being pay for play, having secret agendas, and much more. I’ve had my site taken down a handful of times (before I made static on Github Pages), because I stood up for my girlfriend, or just joined in on the wrong (right) cause. When you have been doing this as long as you have, you see the size of the armies of tech bros that are out there, waiting to pounce. It is why I don’t share links to Reddit or Hacker News anymore. I stopped sharing to DZone for same reason, but they’ve since cleaned up their community, brought in some great talent (including women), and I’ve started syndicating there again.

Most recently I had someone accuse me of pay for play, even though there was no disclosure statement present, and I have had two other folks accuse me of having an agenda set forth by my partners. If you know me, you understand how ridiculous this is, but this never stops the waves of young men finding their way to my site, and pointing the finger. What I find fascinating about this is these men never point the finger at Techcrunch, or call out API startups (and bigcos) for colluding, sponsoring, pay for play, and the other bullshittery that goes on. They go after folks who are outspoken against the machine, and never after the machine itself. If people don’t like something I said, or what someone I’m writing about is up to, they tend to go after me, without spending any time getting to know me, looking at my background, or looking at the seven years of storytelling on my site–there is a single page to do it!

The majority of these folks rarely ever have their own blog, name and pictures on their Twitter or Github accounts, and have a minimum digital footprint. They don’t understand what it is like to be out in the public sphere sharing their ideas on a daily basis, and prefer hiding behind anonymity while they go after the little guy. Again, rarely do you see them going after the Silicon Valley, or larger corporate machine–too big of target. I have special Twitter lists I add these folks too, and usually when one of them pisses in my Cheerios I’ll spend some time seeing what the others are up to, and most times it is more of the same. Trolls. It is easy to dismiss these folks as part of the wider illness we see infecting the Internet, but much like sexism and racism, the real damage is done by the waves of complicit individuals and platforms who support them, chime in, pile on, and maintain an environment where this type of behavior is normalized.

For the most part I’m a diplomat. I tend to perform API Evangelist in a supportive, friendly tone. I started API Evangelist on this tone with intent. I saw the meanness in the space, fully grasped my assholeness as a VP of technology within an enterprise group, and wanted to do something different, and help people feel like APIs were approachable and friendly. I still support this tone, but this week, I’m performing a more offensive version of API Evangelist. One that is calling y’all out for the bullshit that you do each day online in this business, or condone and support daily in your complacency. I’m not really as unhinged as these posts make me out to be (close), I’m just exploring the illness that is rampant in the space, and pushing back a little. There is a significant amount of cover afforded to VCs, bigcos, and the startups who support their message, and for the handful of us out in the open, we often become a much easier target, when in reality there should be much more accountability for those that are responsible for the illnesses in the tech sector, ad are often out of site, but actually have their hands on the puppet strings that make things go around.

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.


Extract As Much Value As You Can From Your API Community And Give Nothing Back

You are in a sweet spot. You got a fat six figure job in the coolest department of your company, building out your API platform. You have a decent budget (never as much as you want) to throw hackathons, run Google and Twitter ads, and you can buy schwag to give away at your events. Sure there is a lot of pressure to deliver, but you are doing pretty well. All you gotta do is convince 3rd party developers to do thing with your companies APIs, develop web, mobile, voice, and other applications that generate buzz and deliver the return on investment your bosses are looking for.

It is all about you and your team. Let’s get to work growth hacking! Attract as may new users as we can, and convince them to build as much as we possibly can. Let’s get them to develop SDKs, write articles for us on their blog, speak at our events, favorite things on hacker news, and whatever activities that we can. Your objective is to extract as much value from your API operations as you possibly can, and give nothing back. Expect developers to work for free. Expect your hackathons attendees to come up with the next great idea, build it, and hand it over to you for very little in return. This isn’t a partnership, this is an API ecosystem, and your team is determined to win at all costs.

Your API isn’t a two-way street. All roads lead to your success, and your bosses getting what they want. You don’t care that 3rd party developers should be compensated, or that they have any rights to their intellectual property. The 5% of them that successfully build applications, we will offer them a job in exchange for it, or we’ll just replicate it internally, decrease their rate limits, and increase their error rates so that they can’t compete. Sure you want people to still feel inspired, but not enough so that they’ll ever be able to sustain their applications–the only sustainable application around here will be owned by the platform. After all, this is all just business–it is nothing personal.

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.


The Yes I Would Like To Talk Button When Signing Up For An API Platform

There are never enough hours in the day. I have an ever growing queue of APIs and API related services that I need to play with for the first time, or just make sure and take another look at. I was FINALLY making time to take another look at the RepreZen API Studio again when I saw that they were now supporting OpenAPI 3.0.

I am still driving it around the block, but I thought the second email I got from them when I was signing up was worth writing about. I had received a pretty standard getting started email from them, but then I got a second email from Miles Daffin, their product manager, reminding me that I can reach out, and providing me with a “Yes I Would Like To Talk Button”. I know, another pretty obvious thing, but you’d be surprised how a little thing like this can actually break us from our regular isolated workspace, and make the people behind an API, or API related service more accessible. The email was pretty concise and simple, but what caught my eye when I scanned was the button.

Anyways, just a small potential building block for your API communication strategy. I’ll be adding the list I am cultivating. I’m not a big hard sell kind of guy, and I appreciate soft outreach like this–leaving it up to me when I want to connect. I’ll keep playing with RepreZen API Studio and report back when I have anything worth sharing. I just wanted to make sure this type of signup email was included in my API communication research.


The Successes And (Mostly) Failures Of A Developer Evangelist

I am a big fan of companies who share their API journey publicly. The comment I hear from readers, as well as attendees of @APIStrat often, is that they want to hear more honest stories from API practitioners regarding every stop along the API lifecycle from defining to deprecation. I encourage API providers to actively share their stories publicly on their blog, and even semi-privately via email newsletters.

Ash Hathaway (@ash_hathaway) over at Stich Data asked me what I thought about her doing an evangelism email newsletter based on her experiences–to which I responded with, “hell yeah, it is a great idea!”. So she has launched The Evangelism Compendium, the successes and (mostly) failures of a developer evangelist email newsletter. She will be sharing her regular thoughts from the trenches, as she is evangelizing for the data integration platform.

Sharing stories from the API trenches like this is a great way to generate content for your operations, while also working through your thoughts on what is working (or not), when it comes to evangelism and outreach for your platform. I think the email newsletter has two audiences 1) data stewards looking to learn more about managing your data in today’s online cloud environment, and 2) other data and API service providers who are looking to learn, and hopefully share thoughts on evangelizing your platform. Many folks think I’m crazy for encouraging this type of real-time transparency into your operations, something that can make some feel vulnerability and exposed, but I find it to the best way to generate honest and compelling content.

API Evangelist is the result of me doing this for the last seven years. Sharing my thoughts as I do my work. I find it is a helpful part of my regular workflow to tell stories in this way, as it helps me refine and articulate my approach. It also generates valuable SEO and SMM exhaust for my platform, while also hopefully helping educate others along the way–even stimulating conversation. I encourage all API providers, and service providers to tune into what Ash is doing over at Stitch Data, and make sure you are telling your story via your blog and/or email newsletter–no matter which stops along the API lifecycle you are looking share with the community.


More Evangelism Will Be Needed To Move Banking API Conversation Forward

I was reading what’s behind the hold up of API adoption at credit unions and I’m reminded (again) of the critical need for API evangelists in the space. I am not talking about advocates for a single API, but more evangelists that reflect my mission as the API Evangelist, but dialed in for specific industries.

To set the stage for you, let me share why I started API Evangelist seven years ago. I began writing about the business, and eventually the politics of APIs because I saw the potential with APIs, but I also saw that things were not evolving as fast as they could because technologists were dominating the API conversation. We needed more discussion around the business of doing APIs, and many of the finer political details like security, terms of service, branding, and other concerns of the business leaders who actually controlled the purse strings that would move the space forward at the speed and scale everyone desired.

To help break the log jam within the federal government, healthcare, and other industries someone needed to help assure business and technical stakeholders of the benefits of doing APIs, with sensible discussion regarding how they could mitigate the risk involved. The problem in the banking space is that you only have the vendors and hype pundits dominating the conversation, and much-needed trust is never established. Banks are extremely risk adverse because of money, but also because of regulations, and when you have just technologist, vendors, and hype analysts stirring the pot, nobody ever really helps alleviate bank’s actual concerns around security, privacy, and other areas that keep them up at night.

I remember sitting down at a table in Vegas with Anthem, Kaiser Permanente, and other health insurance providers who were all about business when I sat down, but after an hour or so I convinced them they weren’t in my sales pipeline, and the tone changed completely. They are so used to be sold to and pushed vendor solutions to their problems, they were just seeing APIs as the next vendor product. I help show them I didn’t have a product to sell, and genuinely wanted to help them understand the API potential, and break down the security, business, and other concerns they faced as major players in the space. I have seen this play out over and over, across many different industries over the last seven years, and is something that the waves of enterprise sales teams, vendors, and analysts never fully grasp is actually gumming up the gears of their progress–a bi-product being so narrowly focused.

For the last five years, I have been trying to groom up evangelists who could tackle specific industries like finance, healthcare, education, and others, but it is really, really difficult to patch together a consistent paycheck to keep anyone engaged. Plus, it seems to take a certain type of obsessive-compulsive personality to stay dedicated to what is going on. If folks are really interested in clearing some of the gunk that is slowing the progress in the banking and credit union API space, you all should get together and establish some sort of vendor-neutral group to help fund and provide a platform for financial sector API evangelist(s) to work independently with banks to help alleviate their concerns, and help showcase the positive motion forward when it comes to banking APIs–otherwise things are going to continue to sputter and jerk forward at an uncomfortable pace.

P.S. The evangelists have to actually give a shit about what is going on and be personally invested, otherwise it won’t be sustainable.


More API Evangelists And Storytellers Please

Everyone once in a while I get a comment from someone regarding competition in the API storytelling space, alluding to someone getting the page views, or audience when it comes to APIs. I rarely worry about these things, and in reality, I want to see way more competition and outlets when it comes to short and long form API storytelling--the API space needs as many voices as it possibly can.

I'd like to see domain specific evangelists emerge, beyond individual API advocates. Someone covering industrial, machine learning, healthcare, and other significant verticals. We need to begin to cultivate domain expertise, and preferably vendor-agnostic, and tooling-comprehensive knowledge and accompanying storytelling. Some of these verticals are in desperate need of leadership, and I just don't have the time to focus in on any single area for too long.

We need more practical, and hands-on API storytelling like we are seeing from the Nordic APIs. They are rocking the storytelling lately, exceeding the quality I can achieve on API Evangelist. They are hitting all the important areas of the API life cycle, and their storytelling is genuine, useful, and not pushing any single product or service. The Nordic APIs is invested in educating the community, something that makes their work stand out--emulate what they are up to if you need a model to follow, don't follow mine. #seriously

If you are an API provider or possibly aggregator and marketplace, consider following the lead of BBVAOpen4U API Market, they produce some interesting content, as well as also have a good way of sharing and syndicating quality content from across the API space. I've seen a lot of companies come and go when it comes to aggregation and syndication of API stories. I like BBVA's open approach, because they have skin in the game, and seem to genuinely want to highlight other interesting things going on in the space--something more API providers should be doing.

If you want to get started in the space, all you need is a blog, a Github, and Twitter account. Come up with a name, and begin learning and writing. Don't worry about page views, or having a voice when you first start, just write. Then as you feel comfortable, and find your voice, begin sharing your work more, as well as highlight the work of other storytellers in the space you are learning from. If you keep at it for a while, you never know, you might actually build a following, and be able to influence the world of APIs through the stories you tell--give it a shot.


All API Startups Should Be More Like Glitch

I was playing around with, and better understanding the new collaborative developer community that is Glitch, and I saw they had published a blog post about how they won't screw up Glitch. The topic was in alignment with another post I was working on regarding what I'd like to see fro API startups, but I think Anil articulates it better than even I could, and I think folks are going to respect it a lot more when it comes from a seasoned veteran like him, over an opinionated evangelist like me.

In hist post, Anil shares five key points I think every startup should be thinking about from day one:

  • No lock-in. We use totally standard infrastructure for Glitch, including regular old Node.js, and normal JavaScript for your code. You can export all of your code to GitHub with a click, or download a zip file of your code instantly at any time. And it’s gonna stay that way. The key thing that we think will keep you using Glitch is by your deep emotional connection to your fellow members of the community. And that’s not lock-in, that’s love! Aww. ❤️
  • We’re not gonna take features away from you and then start charging for them. This is one of those tricky things that a lot of companies do when they start building a business model for their product — they ask, “what would people pay for?” And then they realize… oh crap, the stuff people want to pay for is already offered for free. We’ve thought about this pretty carefully so we’ll be able to support our current features going forward. (It doesn’t cost much for us to run your Glitch app, and that cost is going down each month. No biggie.)
  • When we do start charging for stuff, we’ll check with you firstWe imagine we’ll add some paid features on top of what Glitch has now (maybe domain names? Everybody loves mapping domain names!) and when we do, we’ll let you know they’re coming, plus get your feedback on what you think is fair and reasonable pricing. Because we want you to be happy to pay for these valuable features!
  • We won’t let a bunch of jerks take over the community. Ugh, this one is so annoying. Usually, when a company is trying to grow a community, they’ll let just about anybody in because they’re desperate to show growth, and that inevitably means opening the door to some small number of jerks, who then ruin the whole site for everybody. Instead of doing that foolish thing, we’re going to grow Glitch steadily and deliberately, with tons of room for new folks, but a lot of thought put into preventing abuse and harassment. I can’t guarantee we’ll get it perfect, but honestly the thought of working every day to build something that’s mostly used by jerks would be awful, so we’re not gonna do it. And honestly, Glitch is growing pretty quickly because it’s friendly, so hooray for nice people.
  • We want your fun and weird and “not serious” stuff on Glitch, too. While we’re ecstatic to feature Serious Tools from incredible companies like Slack on Glitch, we think your artsy or silly or deeply personal projects are vital to the community, too. The same people who spend their day building a complex API integration on top of Glitch’s tools will come home and collaborate on a generative poetry project at night, and that’s exactly what we’re designing for. So don’t feel embarrassed to show all your many facets here; that’s what our own team does, too.

There are other things I'd like to see other startups focus on like privacy and security, but Anil really get's at athe heart of much of the illness we see regarding API startups. For me, it really comes down to communication and honesty about the business model, which Anil talks about in a very approachable way. I don't expect companies who are doing startups to do everything that us developers want, but I do want you to be open, honest, and communicative with us about what is going on--that is all.

I fully grasp that startups are in the business of making money, and often have different motivations than many (some) of us developers who are consuming their API focused resources. I do not expect these things to always be in perfect balance, but I do expect startups to be honest with developers from day one, and not bullshit us about their business model, changes and the long term road map. I appreciate that Anil and the Glitch team has started things off on this foot, hopefully providing the rest of us with a model to follow when it comes to not screwing over your developer community, and building more trust when it comes to depending on APIs across the sector.

I am looking forwarding to learning more about Glitch, and the potential for the community.


The Relationship Between Dev Relations And Support

I saw an interesting chasm emerge while at a Google Community Summit this last week, while I heard their support team talk, as well as their developer relations team discuss what they were up to. During the discussion, one of the companies presents discussed how their overall experience with the developer relations team has been amazing, their experience with support has widely been a pretty bad experience--revealing a potential gap between the two teams.

This is a pretty common gap I've seen with many other API platforms. The developer relations team is all about getting the word out, and encouraging platform usage and support teams are there to be the front line for support and being the buffer between integration, and platform engineering teams. I've been the person in the role as the evangelist when there is a bug in an API, and I'm at the mercy of an already overloaded engineering team, and QA staff, before anything gets resolved--this is a difficult position to be in.

How wide this chasm becomes ultimately depends on how much of a priority the API is for an engineering team, and how overloaded they are. I've worked on projects where this chasm is pretty wide, taking days, even weeks to get bugs fixed. I'm guessing this is something a more DevOps focused approach to the API life cycle might help with, where an API developer relations and support team have more access to making changes and fixing bugs--something that has to be pretty difficult to deal with at Google scale.

Anyways, I thought the potential chasm between developer relations and support was worthy enough to discuss and include in my research. It is something we all should be considering no matter how big or small our operations are. There is no quicker way to kill the morale of your API developer relations and support teams by allowing a canyon like this to persist. What challenges have you experienced when it comes to getting support from your API provider? Or inversely, what challenges have you faced supporting your APIs or executing on your developer outreach strategy? I'm curious if other folks are feeling this same pain.


How Do We Keep The Fire Alive In API Space?

It is tough to keep a sustained fire burning in the world of technology, at the individual, organizational, and community level. I have been doing API Evangelist full time for six years, and it is no secret that I have had several moments where I've experienced a crisis of faith, and I do not doubt that there will be many more of these in my future--there is no perfect solution. It takes hard work, creativity, and a myriad of other considerations to keep going, stay energized, and keep other folks doing the same.

I have spent a great deal of time this fall thinking about all of the factors that influence me, and contribute to the fire burning, or acting as a flame retardant to me and the API space. When exploring these contributing factors, it is only logical we start with the external forces right? Because this all sucks because of everything external, aka all of you! Couldn't possibly be me?

So what are some of the external forces out there that contribute to the fire burning brightly, or possibly being dampened across API space are?

  • People Aren't Always Nice - For some reason, the Internet has brought the worst out in many of us. I personally feel this is the nature of technology -- it isn't human, and the more time you spend with it, the less human we are, and less empathy we will have for other people.
  • Everyone Takes A Little - Until you've spent a great deal of time in the spotlight writing, speaking, or otherwise you don't fully grasp this one. Every person you talk to, every hand you shake, takes a little bit from you -- making it super critical for people to give back -- it all takes a toll, whether we acknowledge it or not.
  • Few Ever Give Back - The general tone set by startup culture and VC investment is to take, take, take, and rarely give back. The number of people who want to pick your brain, take your open work, and not ever give anything in return is far greater than the people openly giving back, or acknowledging they should pay you for your time.
  • Use & Subscribe To Open Channels - Follow me on Twitter, and Medium. Subscribe to the Atom Feed and email newsletter. Support those people in the space who provide open channels of information by tuning in and engaging.
  • Fork, Contribute & Build Upon - When you fork someone's work plan on how you will contribute back, build upon, and cite their work. Don't just use open source, contribute back to it, and augment it with the value you bring to the table.
  • Events Are Exhausting - Producing, organizing, and pulling of valuable events that focus on ideas over products are fucking hard, and you should support the open tech events you think contribute most to the tech space. Invest time, money, and your energy wherever you can afford it. I know your company demands you get the most out of your sponsorships, but step back and consider how you can give the most as part of your sponsorship as well.
  • Where We Invest - 95% of the investment in the APi space is into proprietary products, services, and technology. The other 10% is an equal investment in ideas, open concepts, specifications, definitions, and software. If companies do invest in "open" it is in name only, and not a true invest. Everyone suffers from this behavior, making the space pretty fucking business as usual--which is a fire that nobody wants to tend to for very long.
  • Intellectual Property - Unhealthy views on IP lock up ideas. I'm not saying copyright, patents, and licensing shouldn't exist. I am saying that aggressive, greedy views will continue to act as a wet blanket when it comes APIs making a meaningful impact, and making the game pretty untenable for individuals.

Next, up, what are some of the internal forces (aka my responsibility) that can contribute to the fire burning more brightly in the API space?

  • Going To Burning Man - Yes burning man will reinvigorate you each year, but we have to find a way to establish a regular alter that we can burn on a regular basis, finding renewal on a regular basis without so much fucking dust involved.
  • Eat Well - If we've learned anything over the last six years it is that man cannot live on pizza alone. Words of caution for you youngsters--eventually you will start falling apart, and this shit will break if you do not eat well.
  • Alcohol - Drinking is fun and an important social lubricant, but it can also lead to some very bad behavior in real-time, as well as contributing to a multitude of other issues in life ranging from health to relationships. 
  • Exercise - We just can't sit on our ass all the time, as much as we'd like to think we can. Again, this isn't a problem for the youngsters, but as we get on in life, it will catch up with you, and we are better off finding a way to work it in regularly.
  • Family Time - Spending time with family is important. Too much travel, screen time and work all hurt this. Regularly check in on what is important when it comes to family. Even if it is just working on API integrations with your kids (did I tell you I'm doing a project with my daughter) -- woohoo!
  • Creativity - Take time to invest in and move forward creative projects. All work and no play makes us all very fucking boring, and are not conducive to any flame burning. The less I invest in my creative side, the less productive I am in my regular work. As an individual and a business make sure there is the investment in creative projects and space.
  • Money - Money is not everything, but making some is required. I've had several waves of $$ making good in my career, and it rarely ever brought me more happiness, and always brought me more concern. There is a lot of focus on VC investment, and showcasing the successful founders in the space. To keep a sustained fire burning we have to realize there is a lot more to all of this than just making money.

These are just some of the key external and internal forces contributing to the fire burning within me individually when it comes to APIs, and I also feel contribute the fire burning also across the community (which I am part of). Startup and VC investment success do not equal community and individual success. Rarely does a startup winning contribute to any single individual success, or the wider community being more vibrant, creative, and rich? You have a rare rock star founder, and always the wealth of corporate and brand success, but these do not make a fire burn brighter in the community. It might attract a few moths to the flame along the way but doesn't truly enrich everyone, and provide fuel for a sustained burn--it is about burning bright, fast, and hard, which aren't good for most of us humans.

I keep going as the API Evangelist because I'm interested in what I'm doing. I'm fulfilled by learning, writing, sharing, and building. I will keep going for another 10, 20, hopefully until the end of my life, because a real fire is truly burning--not because I met my sales goals, sold my startup, or reached API economy nirvana (that is API singularity). Most of the time I'm learning, I am being creative, and I've made more money than was required to pay my rent, my bills, and could eat well. More meetings. More projects. More handshakes. More money does not always nurture me, and keep the fire alive personally, or within the wider API community.


If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.