3 ms·

I agree that the IoT should be about improving lives but that's true of any new product/service/thing and is not specific to IoT. I do think the post misses th

by amirmc 12y ago

I agree that the IoT should be about improving lives but that's true of any new product/service/thing and is not specific to IoT. I do think the post misses the much larger point of how such services and products get created and deployed. Right now, developers either have to (1) use someone else's platform and be locked in or (2) build a system completely from scratch. We've already seen what happens with option 1 on the web, where the company providing the platform can make an arbitrary decision that puts you out of business - or they get acquired and shut down or a whole host of other things. Option 2 is just too difficult right now unless you're doing nothing but 'appccessories' (toy devices that have some networked functionality) - mainly because we're dealing with distributed systems and the problems they pose. What's needed are open-source tools to make option 2 viable for a new wave of developers. In other words, we need the equivalent of the open-source LAMP stack but for distributed systems. Just think for a moment of the billions of dollars of value that this open toolstack enabled. We need an equivalent stack to solve the modern problems and empower developers to make new products and services. I see these modern problems as related to (1) how we create and deploy applications, (2) how those applications store and sync their data and (3) how they identify and securely connect to each other. Of course, there are solutions to all of these right now but they're cumbersome and inappropriate for the environment we're deploying to. I'm working on a toolstack that deals with these issues but in a much more scalable and resilient way. We're calling it the MISO stack and I'll be writing more about it soon. In the meantime, you can look at following post to get an idea of what we're doing and why. http://nymote.org/blog/2013/introducing-nymote/ http://nymote.org/blog/2013/introducing-nymote/

digitalengineer 12y ago
I think we love to think that. Developers care about the 'how'. Most of the users, sadly, don't. And –to be perfectly honest– most developers will sell their service/product with the client data should a big fat offer come along.
- amirmc 12y ago
  It's the developers I'm talking about, not the users. I've yet to see any breakout company that's using a proprietary IoT platform (but correct me if I'm wrong). There's an inherent risk associated with trying to build a big company that way. Yes, the developer could still sell everything to a third party but that's not really what I'm trying to tackle. It's the problem of building and connecting such applications/services in the first place. You shouldn't need a 'platform' to do that.
  - digitalengineer 12y ago
    I agree, you shouldn't. However, I think dev's will flock to the first commercial API that allows them to concentrate on the specific problem they're trying to tackle. They'll worry about the 'walled garden' if it ever get's so far that it would become a problem. It could even go the Twitter-way. Open for all and pinching down on devs when they've grown (too?) succesfull.
  - timthorn 12y ago
    AlertMe has done pretty well for themselves, although they do now recognise the need for an open platform.
Sanddancer 12y ago
To be honest, your tech, while interesting, is a step or two above the typical Internet of Things device, and the problems that will creep in there. The chips I'm working on for my projects that I'd like to have Internet access have at most a luxurious 32 kilobytes of RAM available to them, with some of them having 256 bytes; the closest they're going to get to a kernel is a set of utility functions. The problem isn't the sparsity of space -- explicitly defining variable sizes becomes second nature pretty quickly -- what is is a lack of well-defined, tiny protocols for sending data up and down to the devices. By the time that the device has even gotten to the uPnP stack, it's already been encapsulated and scrambled in some proprietary format because the developers have pretty much no other choice. The part of the stack you're focusing on already has lots of real smart people working on it, we need more people working on the front lines, building good open protocols designed around sharing so that one's sprinkler can talk to one's weather station so that it knows not to run while it's pouring rain, regardless of who makes it. Until we have those, all the TOR in the world isn't going to protect the huge corpus of data that is going to spring forth into the world.

by amirmc 12y ago

digitalengineer 12y ago

I think we love to think that. Developers care about the 'how'. Most of the users, sadly, don't. And –to be perfectly honest– most developers will sell their service/product with the client data should a big fat offer come along.

amirmc 12y ago
It's the developers I'm talking about, not the users. I've yet to see any breakout company that's using a proprietary IoT platform (but correct me if I'm wrong). There's an inherent risk associated with trying to build a big company that way. Yes, the developer could still sell everything to a third party but that's not really what I'm trying to tackle. It's the problem of building and connecting such applications/services in the first place. You shouldn't need a 'platform' to do that.
- digitalengineer 12y ago
  I agree, you shouldn't. However, I think dev's will flock to the first commercial API that allows them to concentrate on the specific problem they're trying to tackle. They'll worry about the 'walled garden' if it ever get's so far that it would become a problem. It could even go the Twitter-way. Open for all and pinching down on devs when they've grown (too?) succesfull.
- timthorn 12y ago
  AlertMe has done pretty well for themselves, although they do now recognise the need for an open platform.

Sanddancer 12y ago

To be honest, your tech, while interesting, is a step or two above the typical Internet of Things device, and the problems that will creep in there. The chips I'm working on for my projects that I'd like to have Internet access have at most a luxurious 32 kilobytes of RAM available to them, with some of them having 256 bytes; the closest they're going to get to a kernel is a set of utility functions. The problem isn't the sparsity of space -- explicitly defining variable sizes becomes second nature pretty quickly -- what is is a lack of well-defined, tiny protocols for sending data up and down to the devices. By the time that the device has even gotten to the uPnP stack, it's already been encapsulated and scrambled in some proprietary format because the developers have pretty much no other choice. The part of the stack you're focusing on already has lots of real smart people working on it, we need more people working on the front lines, building good open protocols designed around sharing so that one's sprinkler can talk to one's weather station so that it knows not to run while it's pouring rain, regardless of who makes it. Until we have those, all the TOR in the world isn't going to protect the huge corpus of data that is going to spring forth into the world.