Internet of Things & Hardware 2.0 – More Thoughts

Screen_shot_2013-03-03_at_8

Image by Vincent Piotrowski.

Last weekend I wrote up the first of my thoughts on the internet of things and hardware 2.0 movements and how they related to Upverter. This is the second half.

The second part of the meetup that peeked my interest was during the talk by Pachube founder Usman Haque on how we might get very, very close to the internet of things – but never actually make it. He cautioned that building IoT-ish devices like the Nike Fuel Band, but then siloing the data, and locking users into close app ecosystems wasn’t the Internet of Things, but rather just the old hardware model with a services business built on top of it and jammed into the cloud.

I think he’s right.

I think an internet of closed, largely unconnected devices, silos full of data, and no real API or interoperability is only marginally better than today. Its not even really an internet. Its much more akin to the old M2M paradigm (a bad thing). I think unless the incentive system is fixed, or the hardware is opened up, or the data is opened up, or the services are disconnected from the hardware and apps, the IoT won’t ever actually happen.

Open data.

I think the goal should be open data. It could be through APIs, or an “internet” where it all gets stored. It could be through more open hardware that posts to a server of the user’s choice. Or through guerilla firmware and hackers.

If open data exists, apps will be built. Just look at the veritable ecosystem of thousands of twitter apps that got built around that datasource. Imagine sensor data from all over the world, or all over your body, and the plethora of apps that could be built to consume it.

People pay for apps.

And people pay for hardware, but people won’t pay for data. So the question quickly becomes how to open up the data, and use the money from both its collection, and its consumption to pay for all pieces of the ecosystem. If the internet depends on open data, and there is no incentive for a silo to open up their data, and users won’t pay to generate open data – are we simply doomed?

Could you sell hardware that came without consumption apps?

Could you sell both the hardware and the apps separately?

Could you convince a hardware maker to give the hardware away and charge for the app?

Could you convince app makers to pay to use open data?

Could you create a marketplace around data?

Could you find a way to give hardware away for free?

Could anyone get large enough to define a standard open data format? (The IoT version of DoD)

Could someone build an open warehouse for open data and apps? (The IoT version of force.com)

Thoughts on Hardware 2.0 and the Internet of Things

Gigaom recently hosted a great get together in San Francisco talking about Hardware 2.0 and the Internet of Things. The meetup focused very specifically on connected devices and the quantified self, but the crowd was much more generally hardware focused. It was cool to see the energy around the event, and the continued growth of the hardware startup theme.

There were 2 parts of the meetup that made me sit up and pay attention, and I wanted to share the first of them here. It was from David Merrill from Sifteo’s talk on designing hardware in the world of the glass slab (smart phone). He argued that the smartphone has and will continue to kill lots of application specific hardware, but that there are 3 very specific reasons to build hardware despite the smartphone.

1. You need to interact with legacy hardware

Nest is a great example. Buying a smartphone and wanting to control the environment in your house simply aren’t enough to replace your whole heating and cooling system. So Nest created a piece of hardware that bridges the gap.

2. You need to interact with atoms

Makerbot is a great example. There is no conceivable way to print plastic from your smartphone without a new piece of hardware. Transportation, telepresence, and distributed sensor plays all fit this bucket too.

3. You need to interact with the human body

Pebble, Nike Fuel Band, WiThings, ibgstar, etc are all examples of this. I think its kind of a combination of the above 2 categories, but it explains better as 3. Quantified self fits pretty squarely in this bucket.

The short version is that as I was sitting there listening to Dave I realized that while he was talking about the reasons and ways to design IoT hardware. The ways not to get killed by the glass slab. And the role hardware startups have in solving problems. Dave was also describing a very large chunk of the Upverter community. He was describing our users and the problems they are using Upverter to solve.

And after I dug a bit deeper I realize a couple of things…

  • Most of the designs in Upverter fit into one of these buckets.
  • Most of the designs in Upverter are Hardware 2.0
  • Most of the designs in Upverter are part of the Internet of Things.

Pretty cool. We set out to build the best design tools at the exact same time as the hardware community set out to build smaller connected devices – it might turn out we’re made for each other.

But realizing this has made us all wonder – how else can we help throw gas on the fire? What features to IoT hardware hackers need that engineers have never needed before? What happens when you engineer a connected device that doesn’t happen when you engineer a phone or a server? What would make you better and what don’t you care about?