These are the news items I've curated in my monitoring of the API space that have some relevance to the API design conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is designing their APis and the underlying schema used as part of their requests and responses.11 Jul 2017
I have been following stories about, as well as personally experiencing DJI restricting where their drones can fly, going beyond just warning you about restricted areas and actually locking down or restricting your drone capabilities. So it was interesting to also read a post in Motherboard about the company also locking down drones to prevent against hacking, modifying, and tweaking your DJI drones as you wish. Drones for me are a poster child for the entire Internet of Things (IoT), and I think DJI’s approach is a sign of what is to come for all Internet connected devices.
In coming years, there will be a lot that the IoT community can learn from the drone space. From the technical to regulatory, drones will be pushing forward conversations about our networks, cameras, security, privacy, surveillance, and corporate and government control over us, and our devices. Drones stimulate some interesting emotions within people associated with the industry, but more importantly people who know nothing about drones, and will be weighing in on regulation at the municipal, all the way up to the federal and international levels.
I thought it was interesting when DJI began enforcing the recommendations I get in the dashboard for my drones, and requiring that I update my drones, RC controller, and mobile applications to reduce their liability regarding what I an actually doing with my devices. However, locking down drones so people can’t modify, augment, or fix their own drones is a whole other layer to this discussion that isn’t just about stopping ISIS from strapping bombs to their drones, it is also about maintaining sovereignty over their creations, and limiting what we can do as owners when it comes to fixing our devices. We already see the right to fix conversation bubble up in the John Deere ecosystem, but it is something we will continue to see showing up in IoT ecosystems across many different business sectors.
The bold entry into our homes and lives that IoT device manufacturers are making amazes me, but what amazes me even more is how consumers allow this to happen with little resistance. This is another outcome from the drone sector I believe we’ll see more of, is drone operators standing up to defend their right to fix, as well as push back own data, content, an algorithmic ownership over what is produced using devices. Sadly consumers do not understand the value of their data, but hobbyists and commercial operators of drones, and hopefully other devices, do see the value of it, and will begin to shift the balance when it comes to who is profiting off the data our devices are generating.
There will be many technical, business, and political lessons to be learned from the drone space in coming years. I’m strangely thankful that my Drone Recovery project happened, because before that summer I really was not interested in drones, but now I’m not just interested, I own three drones, and have an active interest in understanding what manufacturers like DJI are doing. I’m feel that what DJI is doing with their platform will set a precedent (good and bad) for other IoT operators to follow–something I’ll be keeping a close eye on.
I received this email from DJI about my drone this weekend, telling me about an upcoming update this week where I will be forced to comply with an update that is designed to limit where I can operate my drone. It is a pretty interesting look at the future of this Internet of Things beast we’ve unleashed.
DJI will soon introduce a new application activation process for international customers. This new step, to take effect at the end of this week, ensures you will use the correct set of geospatial information and flight functions for your aircraft, as determined by your geographical location and user profile. All existing flight safety limitations, such as geofencing boundaries and altitude limits, remain the same.
Even if you have registered when activating your aircraft upon purchase, you will have to log in once when you update the new version of DJI GO or GO 4 App. If you have forgotten your password since your initial login, you can reset it using a function within the DJI GO and DJI GO 4 apps.
You will need a data connection to the Internet for your smartphone or tablet when you log in, in order to verify the account information and activate the updated software or firmware. If this activation process is not performed, the aircraft will not have access to the correct geospatial information and flight functions for that region, and its operations will be restricted if you update the upcoming firmware: Live camera streaming will be disabled, and flight will be limited to a 50-meter (164-foot) radius up to 30 meters (98 feet) high.
The feature applies to all aircraft (except standalone A3 and N3) that have been upgraded to the latest firmware or when using future versions of the DJI GO and GO 4 apps.
DJI encourages pilots to always follow applicable laws and regulations in the countries where they operate, and provides information about these regulations on its FlySafe website at flysafe.dji.com.
Your DJI Team
I find it really fascinating that if you do not comply with the update your device will be limited in where it can operate, and taking away some features. That “this new step, to take effect at the end of this week, ensures you will use the correct set of geospatial information and flight functions for your aircraft, as determined by your geographical location and user profile.”
This email provides us with a look at the future, where all our devices are connected to the Internet, and if we don’t comply with all updates, and forward motion, the objects in our lives can be turned off, or limited in what they can do.
I’m profiling a number of drone APIs lately and I came across some interesting APIs out of Parrot. Not all of the APIs are for drones, but I thought they were clean and simple examples of what IoT APIs can look like.
The API for the Parrot Sequoia camera can be controlled over USB, WIFI, allowing you to change settings, calibrate the sensors, trigger image capture and manage memory, and files.
Here are the paths for the device:
- /capture: to get the Sequoia capture state, start and stop a capture
- /config: to get and set the configuration of the camera
- /status: to get all information about the Sequoia physical state
- /calibration: to get the calibration status, start and stop a calibration
- /storage: to get informations about memory
- /file: to get files and folders information
- /download: to download files
- /delete: to delete files and folders
- /version: to get serial number and software version
- /wifi: to get the Sequoia SSID
- /manualmode: to get and set ISO and exposure manually
- /websocket: to use WebSocket notifications on asynchronous events
I like the simple use of API design to express what is possible with an IoT device and that a small hand-held deployable camera and sensor can be defined in this way. While you still need some coding skills to bring any integration life, anyone could land on the API page and pretty quickly understand what is possible with the device API.
When I come across simple approaches to IoT devices using web APIs I try to write about them, adding them to my research when it comes to IoT APIs. It gives me an easy way to find it again in the future, but also hopefully provides IoT manufacturers some examples of how you can do this as simply and effectively as you can.
I need as many examples of how APIs can be in the cloud, or even on a device like the Parrot Sequoia API.
I am spending time learning more about what Airmap is doing with their digital notice and awareness system. I first learned about what Airmap was up to when I learned they were behind the notifications of national parks, and forest fires that displayed via the iPhone enabled radio controller for my DJI Phantom 3 Pro drone. I found it to be a pretty slick way to notify me of issues with the drone, my radio signal, and the environment around me, so when I came back to civilization I set out researching more about what Airmap does, staying in tune with what they are up to ever since.
Now, Airmap's digital notice and awareness system caught my attention: AirMap’s Digital Notice & Awareness System works by sending an encrypted digital flight notice from a drone operator to a secure airspace management dashboard accessible by airspace authorities. Moving this beyond just the drone operator getting notifications about device or environmental conditions based upon my latitude, longitude, and elevation. This system allows for an event driven notification system to be put in place between drone operator(s) and the cloud, modeling an airplane flight control system, but for the drone universe.
For me, this is just one possible control system for drones--a cloud, mobile, and device based flight control system. I'm thinking about movie production, agricultural, mining, disaster, and many other types of control systems. Airmap provides you with some of the APIs you will need to develop a drone platform and/or application(s) that will deliver in these areas:
- Status API - Provide nearby airspace information, including advisories, and notice requirements.
- Airspace API - Interact with the surrounding airspace including its obstacles, rules, and requirements.
- Flight API - Create and query flights, verify a pilot meets flight requirements, and provide digital notice.
- Pilot API - Manage a pilot's profile, preferences, and provide identity verification.
- Aircraft API - Information about drone manufacturers, models, and metadata.
- Maps - Provides a TileJSON spec map style for use with MapBox GL.
I'm taking these APIs and including them in my drone API research. Next, I'm taking what I've learned about machine learning and API enabled cloud pipelines and get to working mapping out some of the common blueprints for video production pipelines, and data processing workflows. I am looking to identify some common ways that AWS and Google cloud infrastructure can be seamlessly mapped to Airmap, and other drone enablement solutions--providing the next generation digital notice and awareness systems like Airmap is doing.
I am enjoying staying in tune where Airmap is headed with their platform. They have identified a very interesting and important layer to the emerging world of drones. Providing the API for tracking for airspace, aircraft, pilots, and their flights is a super smart approach to providing APIs, as well as leading the charge when it comes to information, advisories, and notices in the real world where drones are operating. This space fascinates me, as well as the production, and post-production API enablement when it comes to processing the video, images, and data these fascinating devices generate.
Overall I am pretty underwhelmed by the Internet of Things. Most of the ways in which devices are being connected to the Internet are not very interesting, if not just a bad idea. Even with the overwhelming ways in which I am being underwhelmed by IoT, there are a handful of areas that I do find interesting, like industrial implementations, drones, and the general potential of the concept when you do it thoughtfully and securely.
One of the differences between IoT and the other areas that are fueling APIs in 2016 is that they can be both an API provider, as well as an API consumer. While mobile applications have historically been the biggest driver of API development, they are just API consumers, as are most websites. There is a handful of API aggregation and integration as a service providers who consumer APIs, then also provide APIs who pay this forward (sadly not all API service providers do this), but in the end, most endpoints are just consumers.
When it comes to IoT devices, this is where it gets interesting to me. These Internet-enabled devices can be both API consumers, and API providers--which I think everyone should be, but that is another dimension to this conversation. Deploying Linux, virtualized containers like Docker, and a web server on Raspberry Pi and other popular IoT devices is pretty trivial. This opens up the ability to not just send and receive data to the cloud via APIs, but also a number of possibilities for redefining the network--where APIs are not just about the current incarnation of cloud APIs.
I'm not saying that all implementations of IoT devices in this way will be interesting, but It does evolve the definition of what is possible when it comes APIs, especially when you couple this with the expanding definition of what is the network (ie. cellular, mesh, SDN, etc.). However, it does also continue expanding the attack surface area when it comes to IoT security, but I'm sure everyone is thinking deeply on this subject when it comes to evaluating whether or not a device should be connected to the network at all. ;-)
I have been spending a lot of time this summer thinking about how devices are being connected to the Internet, specifically when it comes to drones. As I was traveling around the countryside flying drones, I increasingly came across stories about drones being a nuisance, and most notably being a big huge problem for firefighting crews.
I am flying a DJI Phantom 3 Professional drone, so I was interested to see DJI recently enable real-time geofencing capabilities for drone pilots. If you are unfamiliar with how these drones work, your drone controller is simply an iPad enabled joystick and a mobile application which becomes your control center. Before you can fly the drone the application goes through a whole series of checks making sure all of the drones variety of systems are all in check.
These drones are hyper aware of their location, maintaining a very detailed flight and activity log. The new DJI geofencing capabilities will now give you updates on wildfire, military, prison, nuclear power plants and other flight hazards via the DJI GO mobile application. DJI get's its information from airspace intelligence company Airmap, who gets their information from Federal Aviation Administration Temporary Flight Restrictions (TFR) feed--all driving drone pilot(s) decision on whether it's safe to fly or not.
"GEO by default limits flights into or take-off within locations that raise safety or security concerns. If a flight within one of these locations has been authorized, GEO allows users with verified DJI accounts to temporarily unlock or self-authorize their flights. This unlock function is not available for sensitive national-security locations", according to the DJI Geo system overview. It is interesting to see how this update can be used as an advisory, or something that prevents the operation of a very geo-aware, and Internet-connected device.
This is the part of drone activity I find intriguing. I thoroughly enjoy flying them, but the precedent being set for potentially the future of Internet-connected devices is what I find infinitely more interesting. There are a couple of things at play here that I think are important. The fact that an Internet-connected device has the advisory and kill-switch like this is interesting, but also the fact that a manufacturer (Chinese one) has opted to do this on their own (maybe there is another story behind), and that a federal agency data feed can play a real time role in how devices and their operators are making decisions out in the field.
I envision this model being used even more when it comes to federal government regulation of Internet of Things devices, but also within the corporate and institutional governance lifecycle--with devices, and their operators being part of a centralized, API driven, command and control infrastructure. I have a number of stories to work through on this subject, and will keep sharing anything I come across when it comes to direct government connections to the Internet of Things like I am seeing in the drone sector.
Thinking Through How We Handle The Internet of Things Data Exhaust, And Responsible API Monetization, With Carvoyant17 Apr 2015
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.
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.
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.
As I read and listen to all of the Internet of Things stories coming out of CES, I’m happy to be hearing discussions around privacy and security, come out of the event. I feel better about IoT security and privacy when I hear things like this, but ultimately I am left with overwhelming concern about of the quantity of IoT devices.
There are many layers to securing IoT devices, and protecting the privacy of IoT users, but I can't help but the think that Internet of Things security and privacy will always begin by asking ourselves if we should be doing this at all. Do we need this object connected to the Internet? Are we truly benefiting from having this item enabled with cloud connectivity?
I'm going to try and keep up with tracking on the API layer being rolled out in support of IoT devices, but not sure I will be able to keep up with the number of devices, and the massive amount of hype around products and services. At some point I may have to tap out, and focus on specific aspects of IoT connectivity ,around what I consider the politics of APIs.
Saturday afternoons are great for closing out tabs I’ve had open all week, and the theme this Saturday is APIs and the Internet of Things. This time it is about controlling your Internet of Things using voice the Thingspeak Talkback API and the Arduino Yún, which seems to be the darling of API to Internet of Things projects.
The Thingspeak Talkback API allows for the adding, updating, deleting and executing of voice commands. It acts as a middleware for the Arduino Yún, allowing IoT devices to to be able to check for commands that need executing—providing an API driven queue of voice commands for all of the Internet connected devices in your life.
As the cost of connecting everyday objects to the Internet gets easier and cheaper, it is fascinating to see the different approaches that providers take to connect these objects to the web. Thingspeak is choosing to go the voice route, where Temboo is betting on the fact that people want to connect IoT devices with their existing cloud platforms and services.
I have a panel this week at Nordic APIs called Business Models in an Internet of Things, with Ellen Sundh (@ellensundh) of Coda Collective, David Henricson Briggs of Playback Energy, Bradford Stephens of Ping Identity and Ronnie Mitra(@mitraman/a>) of Layer 7 Technologies. My current abstract for the panel is:
As we just begin getting a hold on monetization strategies and business models for APIs delivering data and resources for mobile development. How will we begin to understand how to apply what we have learned for the Internet of Things across our homes, vehicles, sensors and other Internet enabled objects that are being integrating with our lives.
In preparation for the event I am working through my thoughts around potential monetization strategies and business models that will emerge in this fascinating adn scary new world where everything can be connected to the Internet---creating an Internet of Things (IoT).
Where Is The Value In The IoT?
When it comes to monetizing APIs of any type, there first has to be value. When it comes IoT where is the value for end-users? Is it the device themselves, is it the ecosystem of applications built around a device or will it be about the insight derived from the data exhaust generated from these Internet connected devices?
Evolving From What We Know
After almost 10 years of operating web APIs, we are getting a handle on some of the best approaches to monetization and building business models in this new API economy. How much of this existing knowledge will transfer directly to the IoT? Freemium, tiered plans, paid API access and advertising--which of these existing models will work, and which won't.
Another existing model to borrow from when it comes to IoT is the telco space. The world of cellphone and smart phones are the seeds of IoT and one of the biggest drivers of the API economy. How will existing telco business models be applied to the world of IoT? Device subsidies, contracts, data plans, message volumes are all possible things that could be borrowed from the existing telco world, but we have to ask ourselves, what will work and what won't?
Will Developers Carry the Burden?
When it comes to API access, developers often pay for access and the privilege of building applications on top of API driven platforms. Will this be the case in the IoT? Will the monetization of IoT platforms involve charging developers for API usage, number of users and features? Is this a primary channel for IoT device makers to make money off their products? In the beginning this may not be the case, with providers needing to incentivize developers to build apps and crunch data, but it is likely that eventually developers will have to carry at least some of the burden.
The payment industry is booming in the API Economy, but micro-payments are still getting their footing, doing better in some areas than others. Certain areas of IoT may lend itself to applying micro-payment approaches to monetization. When you pass through toll booths or parking, there are clear opportunities for micro-payments to engage with Internet connected automobiles. Beyond the obvious, think of the opportunities for traffic prioritization--do you want intelligence on where you should drive to avoid traffic or possibly pay per mile to be in a preferred lane? Another area is in entertainment, in generating revenue from delivering music, audiobooks and other entertainment to drivers or passengers in IoT vehicles and public transportation.
Will IoT Be All About The Data
As we sit at the beginning of the era of big data, driven from mobile, social and the cloud, what will big data look like in the IoT era. Will the money be all about the data exhaust that comes from a world of Internet connected device, not just at the individual device and the insight delivered to users, but at the aggregate level and understand parking patterns for entire cities or the electricity consumption for a region.
Security Will Be Of High Value In IoT
We are already beginning to see the importance of security in the IoT world, with missteps by Tesla and camera maker TRENDnet. Will security around IoT be a monetization opportunity in itself? Device manufacturers will be focused on doing what they do best, and often times will overlook security, leaving open huge opportunities for companies to step up and deliver b2b and b2c security options and layers for IoT. How much will we value security? Will we pay extra to ensure the devices in our lives are truly secure?
I Will Pay For My Privacy In An IoT World
When all devices in my life are connected to the Internet, but also the world around me is filled with cameras, sensors and tracking mechanisms, how will privacy change? Will we have the opportunity to buy privacy in an IoT world? Will the wealthy be able to pay for the privilege of being lost in a sea of devices, not showing up on cameras, passed by when sensors are logging data? Privacy may not be a right in an IoT world it by be purely something you get if you can afford it. Will companies establish IoT business models and drive monetization through privacy layers and opportunities?
A IoT Las Vegas for Venture Capital
With IoT centered around costly physical devices, and potentially large platforms and networks, will anything in the IoT space be able to be bootstrapped like the web 2.0 and mobile space was? Or will all IoT companies require venture capital? At first glance IoT looks like a huge opportunity for VC firms, allowing them to specialize for the win, or gamble on the space like they would in Las Vegas.
Will We Plan For Monetization Early On In IoT?
When it comes to IoT, it is easy to focus on the monetization the physical device, either leaving money on the table with new an innovative ways of generating revenue, or possibly having monetization strategies that are behind the scenes and not obvious to users--something that could be damaging to security, privacy and overall trust in the IoT space.
We learned a lot from mistakes made in early social, cloud and mobile API monetization. We need to make sure and have open conversation around healthy IoT business models and monetization strategies. Generating revenue from IoT needs to be a 3-legged endeavor that includes not just IoT platform providers, but sensibly includes ecosystem developers as well as end-users.
The world of IoT is just getting going, but is picking up momentum very quickly. We are seeing IoT devices enter our homes, cars, clothing, bodies and will become ubiquitous in the world around us, embedded in signs, doorways, roadways, products in rural and metropolitan areas. It is clear there is huge opportunities to make money in this new Internet connected world, but let's make sure and have open conversations about how this can be done in sensible ways to make sure the IoT space grows in a healthy and vibrat way.
I just spent 30 minutes on the phone with an important group in the European Union called OPENi, which is aiming to be an open-source, web-based, framework for integrating applications with cloud-based services via APIs. Straight from the organization's mouth:
OPENi aims at inspiring innovation in the European mobile applications industry, by radically improving the interoperability of cloud-based services and trust in personal cloud storage through the development of a consumer-centric, open source mobile cloud applications platform.
I will be providing feedback and guidance as a member of the group's user advisory board. While on the call today, there was a mention of concerns around being seen as the usual, heavy handed EU entity that is too focused on user privacy and ownership, which could prevent the group from being well received, but also ignore the economic opportunities APIs and interoperability afford businesses, developers and end users.
This is a reminder for me of how EU tech companies, and the countries where they reside, are often perceived around the globe and here in the US. But also stands in stark contrast to the illness I see from the Silicon Valley, and U.S side of the discussion. In a world where everything is about economic opportunity, and the data in these API pipes are the new oil, aka the new resource, that is meant to be extracted, with little or no concern for privacy and ownership of the end-users.
In 2014, there is a huge opportunity for all of us to meet in the middle, acknowledging that there is great economic opportunity around APIs, cloud services, interoperability and the data that flows between platforms. But there is even greater economic opportunity if we acknowledge and respect the privacy, ownership of users of the web, mobile and Internet of Things we develop in the cloud.
I would also add a 3rd dimension to this discussion. That there is also a massive non-commercial opportunity for APIs, interoperability and cloud services. When it comes to more efficient government, healthcare, education, journalism, media and other aspects of our society, if we can better educate end-users, developers and platform owners while also improve technological approaches by honing concepts like hypermedia, licensing and ownership models defined on top of oAuth--everyone in the game will benefit.
There is a lot at stake right now. It isn't black or white, but many, may shades of gray. It is not all about privacy and ownership, or all about making money. APIs enable interoperability, data portability, transparency and openness that can really benefit society as well as open up opportunities for economic growth for everyone involved.
Even after 3 years doing this, I still get very hopeful for the potential of APIs on the global landscape. I predict 2014 will be a critical year.
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.