{"API Evangelist"}

My Open Data Panel At APIDaysBerlin and APIStrat This Friday In Berlin

In addition to helping be the MC for the API event, one of the conversation I am facilitating at @APIDaysBerlin / @APIStrat Europe this Friday in Berlin, is an open data discussion on the main stage. What better place to discuss the world of open data and API, then in Germany. The country has some of the strictest laws when it comes to protecting the privacy of German citizens, and when it comes to API access to data, I couldn't think of a better place to have an open discussion in 2015.

I have invited two data specialists to the stage Friday afternoon:

Ali Jelveh (@jelveh), CEO & Founder Protonet GmbH and Free Your Data -  Ali Jelveh is Co-Founder and Chief Revolutionary Officer of Protonet. Protonet builds Personal Severs for small and medium sized teams. The German-Iranian software engineer has been amongst the first developers at XING after dropping out of his college career. He is on a mission to transform the internet from centralization in the cloud to a state of distributed infrastructure and independent users.
Jonathan VoigtDigital Strategy Advisor / Country Representative of UN Influx - Jonathan Voigt is a startup founder, corporate entrepreneur and digital strategy advisor. Following a master’s degree in innovation management, he co-founded a digital marketing start-up and is now supporting Germany's leading agency for digital transformation. In an honorary capacity, Jonathan is the German representative of UN Influx , a charity that organizes hackathons to help the UN and the public engage better with one another.

I am looking forward to hearing what Ali and Jonathan have to say about open data, from a European perspective. To help stimulate the conversation, I've also invited one of our keynotes to join us:

Chris Taggart (@countculture), EO & Co-founder of OpenCorporates - Chris Taggart is the CEO and co-founder of OpenCorporates: The Open Database Of the Corporate World, which has worked with the open data community to build a database of over 25 million companies, all open data. Originally a journalist and later magazine publisher, he now works full time in the field of open data, and is on the UK government’s Local Public Data Panel, and Mayor of London’s Digital Advisory Board.

I do not have a list of questions prepared for these gentlemen. I think we all know the space well enough, just discussing who they are, their projects, and the wider open data space is sure to fill up 30 minutes of main stage action. I am eager to hear Chris's keynote as well, as I'm extremely interested in what OpenCorporates is doing.

If you aren't registered, there are like 20 tickets left, so you better jump now before the conference sells out. Feel free to send me any questions or topics you'd like to see disccussed, and I'll see you in Berlin this Friday and Saturday.



Weekly API.Report For April 20th, 2015

My Weekly API.Report represents the best of what I've read throughout the week, and is only what I personally felt should be showcased. Each news item comes with a link, and some thoughts I had after curating the piece of API related news. I'm trying to break down stories into as coherent buckets as I can, but it remains something that is ever changing for me, but ultimately I will settle on a clear definition for each of the research areas.

Accessibility is something I'm pushing more on:

A handful of interesting Acquisitions:

Not sure if it is API, but some scarey Agriculture data:

A few Analytics stories that caught my attention this week:

Some interesting API Deployment lessons:

More API Deprecation out of Google and Blackberry:

The required API Economy talk:

A healthy dose of API Evangelism:

The API Event goings on:

The neverending API Lifecycle:

Couple of API Management lessons I pulled out of this week:

Some API Monitoring wisdom from the past week:

The growing area of API News:

Increasingly popular API Performance related stories:

A free range API Reciprocity story:

An intresting Application story from legal realm:

The Architecture big picture:

Cool Audio offering out of Pop Up Archive:

Authentication stories out of Azure and SalesForce:

More the Banking industry:

More Blockchain education:

An API Book to look out for:

Valuable Business data resources:

All about the Business of APIs:

A lone computer aided design (CAD) story:

A general Camera story:

The Career opportunities this week:

Cloud Computing stories from across the leaders:

A single Cloud Storage product:

AWS has a pretty big Command Line Interface stack:

Containers is mostly about money this week:

An education story, but pulling out and showcasing because it applies to larger Content conversation:

China rock'n the Cybersecurity war front:

All about the Data:

And the Data Portability:

Specifically about the Database world:

Not your usual Device company:

The Document space:

Just a couple Drone highlights:

New APIs, and some Education stories:

The Embeddable discussions:

A single Entertainment focused API:

Out of the Federal Government:

In the Fitness arena:

The Hackathons that made the cut:

Always my favorite, the area I call Hacker Storytelling:

The Healthcare sector:

History is important:

On the connected Home front:

At the HTTP level:

Plotting the future of APIs at the IDE level:

Something you don't see much in my roundups, Infographics:

Trying to keep the Internet of Things compelling, but I only can use what I find:

Lot of Investment to go round:

I wish there was more Library news:

The Local discussion around data and APIs:

Tracking on Location focused details:

The Mapping discussions that caught my attention:

Microsoft is all about the Media in the cloud:

A single Microservice story:

The Mobile items from the week:

Separating out the Museum element here:

Not API news, but News, news:

Beyond just data with Open Data:

The Open Source talk out of Box:

Highlighting the importance of Partners:

A few Patent blips this week:

Had to highlight this Policing data story by itself, hopefully we'll see many more:

Beek week for the Politics of APIs, being led by Twitter:

The important Privacy stories I read:

Just keeping an eye on Push Notifications:

Always keeping it Real-Time:

Resources are so important to API operations:

I love Robots:

Two Scraping things to share:

Some interesting SDK moves:

Let's talk Security:

A single lonley Sensor:

Always Showcase your important integrations:

Single Page Applications (SPA):

I spend a lot of time in Space:

Good to see this State Government story:

From the land of Telecommunications:

Something Trademark related I felt should be liberated by APis:

Keeping the Transparency conversation moving forward:

Move forward Versions:

An API pioneer makes some Video moves:

SalesForce talking Visualizations:

Watching the world of Watches, for anything interesting:

We need more Water APIs:

Another player in the Wearables space:

That concludes my report on what I read last week across the API space. I'm still working on pulling together a summary e-newsletter version, allowing people to get an executive summary of what I thought was important from the week--I am hoping it will be available next week. I'm also going to auto-generate some visualizations, and summary counts for each week. I'd like to see a tag cloud, and overall counts to help me understand the scope of news I cover each week.

If you know of something I missed, feel free to email or tweet at me, and make sure I know about your company, and have a link to your blog RSS. If you don't tell the story and share, the world will never know it happened.

It is a good time to be tracking on the API space--lots going on!



Quantifying My Minimum Viable API Footprint Definition As Real API Portal

I wrote a post the other day laying out what I'd consider a minimum viable footprint for API operations. My vision of just exactly what an API is, has gone beyond just the technical, ever since I started API Evangelist back in July of 2010. Early on I saw this was more than just about the API endpoints, and documentation, code samples, and many other building blocks were essential to the success (or failure) of any API platform, area, or ecosystem.

This recent post was an attempt, here in 2015, to quantify what I would consider to be a minimum definition for API operation. After writing it I wanted to take another stab at actually creating a portal, that would stand up to the API rhetoric that I regularly produce. What better place to start, than my own personal master API stack, where I am working to get control over my own infrastructure. Once I got a version 1.0 definition, I forked it, and setup a default API portal that I am calling my demo APIs.json driven portal.

I have published to Github, a version of my minimum API footprint, which I'm using APIs.json an engine. After looking at 10,000K+ APIs, I have a pretty good idea of what I like to see. This is my interpretation of all that monitoring of the space--a distillation of what I've seen while reviewing APIs. It isn't perfect, but neither is the space that we have, and my portal is just an attempt at quantifying what I'm seeing.

I'm going to create a minimum viable Internet of Things (IoT) version of this portal as well, and use APIs.json to deploy different interpretations of what constitutes a minimum viable API presence. If you have anything you'd like to see in my base template, let me know. If you want to fork and add to, then submit a pull request, even better. I'm just playing around, but also looking to establish a suite of APIs.json driven tools, that help me(and you), better understand the API space.

To help on-board you with my vision, I also added a walk-through for when you land on the site. Something I will be adding to when I have time.



Quantifying A Minimum Viable API Footprint Definition As Real APIs.json Driven Portal

I wrote a post the other day laying out what I'd consider a minimum viable footprint for API operations. My vision of just exactly what an API is, has gone beyond just the technical, ever since I started API Evangelist back in July of 2010. Early on I saw this was more than just about the API endpoints, and documentation, code samples, and many other building blocks were essential to the success (or failure) of any API platform, area, or ecosystem.

This recent post was an attempt, here in 2015, to quantify what I would consider to be a minimum definition for API operation. After writing it I wanted to take another stab at actually creating a portal, that would stand up to the API rhetoric that I regularly produce. What better place to start, than my own personal master API stack, where I am working to get control over my own infrastructure. Once I got a version 1.0 definition, I forked it, and setup a default API portal that I am calling my demo APIs.json driven portal.

I have published to Github, a version of my minimum API footprint, which I'm using APIs.json an engine. After looking at 10,000K+ APIs, I have a pretty good idea of what I like to see. This is my interpretation of all that monitoring of the space--a distillation of what I've seen while reviewing APIs. It isn't perfect, but neither is the space that we have, and my portal is just an attempt at quantifying what I'm seeing.

I'm going to create a minimum viable Internet of Things (IoT) version of this portal as well, and use APIs.json to deploy different interpretations of what constitutes a minimum viable API presence. If you have anything you'd like to see in my base template, let me know. If you want to fork and add to, then submit a pull request, even better. I'm just playing around, but also looking to establish a suite of APIs.json driven tools, that help me(and you), better understand the API space.

To help on-board you with my vision, I also added a walk-through for when you land on the site. Something I will be adding to when I have time.



Thinking Through How We Handle The Internet of Things Data Exhaust, And Responsible API Monetization, With Carvoyant

I'm very fortunate to be the API Evangelist, as I get to spend my days discussing, some very lofty ideas, with extremely smart and entrepreneurial folks from across many different business sectors. An ongoing conversation I have going on with Bret Tobey (@batobey), the CEO of Carvoyant, is around the big data generated around the Internet of Things. Many companies that I engage with are very closed about their big data operations, where Carvoyant is the opposite, they want to openly discuss, and figure it out as a community, out in the open--something I fully support.

In reality, the Internet of Things (IoT) is less about devices, than it is about the data that is produced. If someone is exclusively focusing on the device as part of their pitch, it is mostly likely they are trying to distract you from the data being generated, because they are looking to monetize the IoT data exhaust for themselves. Carvoyant is keen on discussing the realities of IoT data exhaust, and not just from Internet connected automobile perspective, but also the wider world of Internet connected devices. If you want to join in the discussion, of course you can comment on this blog, and via Twitter, but you can also come to Gluecon in May, where 3Scale, API Evangelist, and Carvoyant will be conducting an IoT big data workshop, on this topic.

If you aren't familiar with Carvoyant, they are an API-driven device that you can connect to your vehicle, if it was manufactured after 1996, and access the volumes of data being produced each day. Carvoyant's tag line says "Your Car, Your Data, Your API" -- I like that. This is why I enjoy talking through their strategy, because they see the world of APIs, connected devices, and big data the way I do. Sure there is lots of opportunity for platforms, and developers to make money in all of this, but if there is user generated content and data involved, the end-users should also have a stake in the action--I do not care how good your business idea is. 

Carvoyant does a great job of acknowledging that the car is center to our existence, and the data generated around our vehicles is potentially very valuable, but it is also a very personal thing, even when anonymized. Here is how they put it:

Connected car data tells the repair industry when a vehicle needs service – the moment it happens.  Connected car data tells an insurer how a driver actually drives and if they are eligible for a better priced policy.  Connected car data tells gas stations if a vehicle is low on gas.  If a vehicle has not been to the grocery store for a while, than it may be time to make an offer.

The difference in this conversation, is Carvoyant isn't just making this pitch to investors, the automobile industry, and developers, they are making it to the automobile owners as well. They are working to establish best practices for gathering, accessing, storing, and making sense of Internet of Things data exhaust, in a way that keeps the end-users interests in mind. Every platform should think this way. There is too much exploitation going on around user-generated data, and Carvoyants vision is important.

Monetization Via Classic Affiliate Program
When it comes to figuring out a healthy monetization strategy for the Carvoyant platform, and resulting data, the company is starting with a familiar concept, the affiliate program. Establishing potential referral networks, where end-consumers, and developers of apps can refer potential customers to businesses, and when there is a successful sale, an affiliate commisison is paid out. This is a great place to start, because it is a concept that businesses, developers, and consumers will understand and be able to operate within, without changing much on the ground behavior.

If you identify a customer in need of vehicle servicing, and successfully refer them to a local service center, you can be paid money for making the connection, something that when done right could also be applied to the end-user in form of credits, discounts, and other loyalty opportunities. An affiliate approach to the monetization of data via the Carvoyant API makes for an easy sell, but one that can be applied to a myriad of business sectors ranging from automobile services to food, shopping, travel, and much, much more. While an affiliate base is being established, Carvoyant can also begin to look towards the future, and shifting behavior.

Monetization Beyond Affiliate
While I'm fine with Carvoyant kicking off their monetization strategy with a calssic affiliate program, I feel pretty strongly there are many other opportunities for monetization, something that Bret agrees too. When you think about the central role cars play in our lives, the opportunities for inciting meaningful experiences, are endless. While the real money is probably around the mundane realities of the average car owner, the chances for serendipity, beyond these known areas is the exciting aspect. How do you not just help users find the best time to get their oil changed, but also take that side street, instead of freeway that might involve a chance experience that could range from dinner, to concert, or just find that right sunset location.

There is a pretty clear conversion event involved with the affiliate model. A user clicks on just the right deal, a sale is made, and revenue is kicked back from the business to the platform, developer, and is something that hopefully reaches the end-user in meaningful way. What other types of "conversion events" (man I hate that phrase) can we identify in car culture. How do we encourage people to take public transit, share vehicles, or how do we make large fleets operate more in harmony? With the right platform, I think we can quickly go beyond the traditional affiliate transaction, and develop a new wave of monetization around IoT data, that goes beyond just eyeballs, and links, and is more about engagement and true experiences.

Experience Credits Not Just Sales 
Just like moving beyond the affiliate conversion event, I think we can go beyond the transaction also being currency or sale based. How do we create a more experience based currency or credit system that can be used equally to help businesses generate sales, and establish loyalty with customers, but also allow developers and end-consumers to exchange units of value, attached to valuable automobile data? If a $20.00 deal on a $30.00 oil change, results in a $2.00 affiliate revenue share, what would the value of pulling off the freeway, taking the side road and catching just the right sunset picture be worth? How do we incentivize experiences, not just sales? If we are continuing to weave data generated from our physical worlds, it cannot always be about money, there has to be other value generated, that will keep end-users engaged in valuable, yet meaningful ways.

Sharing Economy
As our worlds continue to change, partially because of technology, but also because of other environmental and societal pressures, what value, sales, and experiences can be generated from the data exhaust produced as part of the sharing economy? If its our car, our data, and our API--does this apply when it involves our ZipCar usage, rental car, or possibly Uber? How does the sharing economy impact data generated via connected cars. When the end-user is the center of the conversations, these alternate use cases have to be included, and make sure privacy is protected, but also opportunities around that data to be securely shared with users. This isn't just a shared automobile data conversation, it is potentially applicable to any other objects we rent and share like tools, equipment, supplies, and anything else we may use as part of our business and personal lives.

Commercial Fleets
Just like the data exhaust from personally owned vehicles, or automobiles used as part of the sharing economy, the opportunities, and patterns available for commercial fleets will look very different. How do we incentivize efficiency, cost savings, and safety in fleet operations? What do the affiliate deals, and experiences look like for fleet vehicle drives, and the companies that own and manage them. Think of the implications of big data exhaust from vehicles in heavily regulated industries, and public service entities like police, and fire. We will also have to think very differently about how revenue is generated and shared, as well as look at privacy and security very differently. This doesn't reduce the opportunity in the area of fleet management, it just needs a significantly different conversation about what we need for this class of automobile.

Establishing Common Blueprints 
Beyond the individual conversion events for individual drives, or the wider opportunities for sharing economy companies, and commercial fleet operators, where are the opportunities around identifying common patterns of vehicle usage at scale? How does the vehicle usage of the LAPD differ from NYPD? What does the average residential vehicle owner in San Diego look like, versus the rental car tourist for San Diego? Using connected vehicle technology like Carvoyant opens up a huge opportunity for better understanding car culture at a macro level, beyond what the auto industry, or maybe Department of Transportation sees. How do we begin having honest conversations about our vehicle usage, and allow drivers to be educated about larger studies, allowing them as a company or individual to opt in, and share data, to participate in larger studies? We have to make sure and consider the bigger opportunities for understanding beyond any single endpoint on the connected car network, and look at entire cities, states, countries, and other meaningful demographics.

Lots More To Discuss, Something That Needs Transparency
This is just the beginning of these types of discussions. I have a handful of companies, like https://www.carvoyant.com, who have access to huge volumes of extremely valuable user-generated data, who are trying to figure out how to developer useful tech, make money, all while doing it in a healthy way that protects end-users privacy and security. I am not opposed to companies making money off their API platforms, and user generated data, I just insist that APIs always be used to make it more transparent, and technology such as oAuth employed to give end-users more control, and a vote in how their data is collected, stored, shared.

This post is about me working through my last conversation with Bret, and hopefully will result in several more stories here on the blog. I also want to prime the pump for the APIStrat IoT Big Data Workshop at Gluecon in May, and make sure my readers are aware the workshop will be happening, and if you want to join in the conversation. This is just one of many posts you'll see from me discussing the big data exhaust generated from Internet connected devices, but also the potential for transparency and healthier platform operations when APIs and oAuth are employed. These types conversations are only going to become more critical as more of our physical worlds are connected to the Internet.