Following our post on IoT platforms, Spark guys reached out and asked if we can do a full interview. Given the unique position Spak is currently in (post-successful Kickstarter, betting heavily on Open Hardware and Open Software...) - we were more than happy to do it. And were pleasantly surprised by all the things we have learned along the way.

Here we give a full (uncut) transcript of our interview with Zach Supalla, CEO of Spark.

Hackaday: Tell us a little bit of a backstory behind Spark

Zach: OK, to rewind all the way back.. in January 2012 I started working on connected lighting product. The inspiration for this was - my dad is deaf and he has lights that flash when someone is at the door, when he gets a phone call on his tty etc. He and my mom had this problem that when he takes his phone from his pocket, he is completely unreachable and I wanted lights to flash when he got a text message. So that is really where all this started - I had a problem that was very real to me, which was my parents communicating and I saw a way to solve this problem with connectivity. If we make our lights Internet-connected, then I can figure out a way to get the signal that this behavior happened to his lights. But then of course, that grew into a larger concept of, well, why should it just be limited to the deaf? lights should be a source of information.. what if lights were more than just lights? what if lights conveyed information about the world and they did things automatically, not like... "I have a remote control on my phone", but like... "the sun went down and lights automatically turn on"-kind of home automation. All to do with lights connected to the Internet.

So we launched this product which eventually took the form of a little plastic thing that sits between your lightbulb socket and the light, that was wifi-connected, sort of WiFi-connected light dimmer switch integrated into light socket, called SparkSocket. It launched in November 2012 and failed. We had a goal of $250,000, we raised $125,000. And so we felt like there was something there, we still had 6-digit raise and 1600 backers but it wasn't enough to cover our manufacturing cost. And so, it took us a while to realize that we needed to change. The feedback that we had received from the market was that our product was not good enough and so over the course of the next few months we struggled to figure out what we should be doing and so we have joined the incubator program called HAXLR8R that was based in Shenzhen and moved there for 4 months during this process. 

And we have settled out after a bunch of iterating. We saw an opportunity that there are cool new things you can do when things are connected to the internet and the challenge that we felt firsthand was that it was... hard. The tools that were available were either so difficult to use that they were not really solving the problem or were very closed and very risky for us where as a startup we can't use that because we'll be tied into somebody else's system and we really didn't want that. And so we thought... what if this is what we do? What if we solve this problem of creating a tech stack that people can use for Internet of Things that we can make available to others and that's our business? We were originally planning on going straight B2B like we're going to sell it to Enterprise customers but we saw that there were dev kits doing well on Kickstarter and that Arduino-e stuff did well on Kickstarter... and, of course, that's where we come from - we're all makers, and thought... why don't we make this "Arduino-compatible" (which for us means.. same programming language) and sell it as a dev kit. Because, really, what we're trying to do is make it easier to make these products and that's a problem that is relevant for Enterprise and it's relevant for weekend hobbyist. And that's what turned into the Spark Core. And we launched it May 2 last year which was... a year and couple of days ago. And we had luck. We had a much lower goal of $10,000 this time - it was a much cheaper product to manufacture, we can make them by hand at small scale and mass-manufacture at large scale, so set a very small goal and we passed in a little over an hour and a half. And then the campaign kinda got away from us in terms of what our expectation was. Maker Faire was during that campaign and we had a lot of people stopping by and I think that contributed a lot to our success. And then, yeah, we shipped in November and since then we have been just trying to keep it in stock.

Hackaday: So, you made a comment that tools, devices and whatnot were too difficult to use. Elaborate on that a bit, give me the context. Too difficult for whom?

Zach: I think the good example is.. a lot of Cloud services that are available like Xively and Etherios I think provide valuable service but the challenge is that they are so... they require you to first get your hardware setup, so it might take you, depending on what you're using as a prototyping tool, it could take you a week or two to just get on the service. And when we looked at hardware stuff, there are some hardware modules that are really use to use, like RN171 - it's a great wireless module except that it's really expensive. So you can pick either easy or good for production environment but you couldn't have both and that was important for us - we want to make prototyping tools that people can get started with quickly but then when they have some intent to scale, they're either startup or a big company, when they want to make 10,000 of these things that they don't have to start over. That they don't have to prototype on one thing and then rebuild from scratch. That was very important for us.

Hackaday: So, in terms of the choice of device... what's the retail price on the Spark Core right now?

Zach: $39

Hackaday: OK, so the retail price on RN171 is $26. So, explain your characterization that RN171 was too expensive?

Zach: It's more about the cost when you start to scale. The problem with RN171 is $26, but when you start to scale it $16. When you're buying 100,000s of them, it's still $16. Spark Core is $39 because we're taking a TI WiFi module and adding some other stuff and providing firmware, but then when you go to scale, the CC3000 is a pretty cheap part. Their budgetary pricing is $9.99 at a 1000 units and it comes down from there. So you can buy them one at the time but you can also scale with this product. And that was important for us. We think the money matters in terms of how much product costs and pushing that price down is important. We want to make it available for more people and price when you scale is what's important for us.

Hackaday: So the scalability in that context is the move away from module to individual device, right? Where RN171 is all-encompassing - it is the module. You're talking about the scalability there is really in in move away from the module to the individual device and putting C3000 on the board and that's the secret to my scalability. Is that an accurate characterization?

Zach: Exactly, because our plan is providing dev kits so that people can prototype and so when they go to scale, the follow the reference design or our open source design and implement it in their product. And we're out of the supply chain. And that's great because, in the end, that's the cheapest way. Any time you add an layer to the supply chain you're incurring overhead and cost. So we want to provide a fully integrated solution that's easy to use but then when you go to scale, we want to get out of the supply chain so that you can make it cheap and make your product more affordable to your customers in the end.

Hackaday: Gotcha. Give us some background on the choice of CC3000?

Zach: This might still be true, but at the time of our launch, this was the only affordable WiFi module that you purchase in low quantities extremely easily. For instance, there are other companies that make affordable WiFi modules, when you get to scale - Broadcom and Qualcomm are two of note. One of the challenges of them is that it's difficult to gain access to these chips in low quantities. So, if you do have intent to scale but you're starting small because, maybe you're a startup - you can't. TI's chip is great because it scales but it's also available in low quantities. And to be meaningfully Open Source, that was important for us. And, you know, CC3000 has it's quirks, but that's one of the reasons we thing we can help with our firmware libraries to wrap it and abstract it. But I think it was an opportunity in that it came up just around when we launched our campaign so we have been taking this new product to the market that still haven't been vetted by anybody else.

Hackaday: Yeah, Broadcom and Marvell can be a pain if you're not doing high quantities. Even getting an access to a data sheet can sometimes feel like getting your teeth pulled. But, there are other devices on the market like, for example, Ralink MTK. You were in Shenzhen and there you're surrounded surrounded by all other sorts of devices you don't get to see in the West - devices that run that run Linux at much lower cost, ballpark of $3 and can run OpenWrt. CC3000 can't run Linux, it requires more in the way of traditional embedded. Explain that decision a bit..

Zach: It all depends on what is your application and what are you trying to do. I would say that Spark Core is good for some application and not for others. What we wanted to do is bring this stuff to a low-cost embedded world and there are things that are easier and better to do in embedded world then in a Linux-based system - realtime-stuff, low-level direct access to pins - that's what Arduino is good for. In prototyping world there's Arduino and there's Raspberry Pi. They're good for different things, although you see people using wrong tools all the time - you see people using Raspberry Pi for something that should be done with an Arduino and vice versa. And sometime you look at that and say, well ok, they're both easy to use and there's definitely overlap but we wanted to really focus on this embedded world and providing solutions there.

Hackaday: Tell us a little bit about the details of CC3000. Take us through what are the aspects of that made it the winner?

Zach: Yeah, and there are definitely other ones that weren't available when we started. Atmel has their chip now too and this is a landscape in which a lot of companies are investing. And we're constantly evaluating the landscape as we're thinking about our next-generation hardware. Things change all the time, and we change too because now we have access to things we didn't have access to back then. As a startup, we now can talk to people that we wouldn't be able to talk to if we haven't run the successful Kickstarter campaign and if we weren't already generating an active community around our product. So that changes our perspective. The main ones that we were evaluating at the time were RN171, GainSpan solution and the CC3000. And the main part of it was being affordable. There are some features that CC3000 doesn't have that others did but when it comes to providing something that's cost-effective solutions it's a trade-off you inevitably must make. CC3000 doesn't add up to 11n, it doesn't do SoftAP setup, they have their own thing SmartConfig, which is pretty slick but has its quirks also. And so when we launched this choice felt good, felt like a right mix of what we're trying to do. But as the landscape changes we need to keep changing to, we need to preserve our agility as a startup.

Hackaday: One of the things you're talking about in your top-level video is that "setup is seamless and everything is secure". That's a bold statement. Talk a little bit about the security model and the challenges for security at this level.

Zach: There's a lot of pieces of communication to "secure". One is WiFi setup - you're sending your credentials, how do you make sure those are not (openly) shared? SmartConfig is sending this as AES-encrypted and so that provides some security there, but one of the challenges for us is - we release our Open Source libraries, they contain the AES key. That is kind of half-way. So basically what we do there is - when someone goes to production with the product and it's based of SparkCore design, and they're not Open Sourcing it, they can use different AES key and make it secure. Then the other aspect is device-to-cloud...

Hackaday: Yeah, so you guys are using CoAP? With that, are you implementing DTLS?

Zach: So, we want to be able to implement good encryption standards, but we're also constrained in our application - how much RAM do we have, how much computational capabilities, we're not using a processor that has a hardware crypto... all of which which creates constraints. But we want it to be something that can run everywhere. So basically what we ended up doing was implementing RSA handshake off to a AES tunnel. You can think of it as a very slimmed-down TLS/SSL, we're managing certificates in a slightly different way but we're fundamentally using the same building blocks for encryption. And figuring out how to implement this wasn't a matter of finding the libraries that made sense - there are not a lot of Open Source embedded encryption libraries.A lot of them are under dual licensing, but we ended up finding an old XySSL (now PolarSSL) which was BSD licensed. The most important from security perspective is, I think, the fact that's it's open and auditable, so that anyone can take look at the process we're using for security and make sure it's secure. Because, when it comes to security, and this is true with all the things that have been going on recently in the security world with Snowden, NSA and all that is - what you need to feel secure is an open and auditable process.

Hackaday: It sounds like you're implementing something like what you would have under a UDP-based system?

Zach: Yeah, we really liked CoAP as a protocol, although we run it on top of TCP-based sockets instead. CoAP is designed for constrained environments and I think a big part of the reason it's UDP instead of TCP is how do we make it work on as small of a processor as we can. But our processor comes with TCP and we were like, OK we're constrained with RAM but we do have TCP, so we should leverage that.

Hackaday: So why not MQTT?

Zach: We have debated this for a while. What we didn't like about MQTT is two things: one, we wanted it to do request-response model and MQTT is pub-sub and second, it didn't define the payload which felt to us like it's not solving enough of the problem. So we can say - OK we will use MQTT but what do we say when we actually want to communicate? What does the message look like? So we ended up going down another rathole there... CoAP had much more of that defined and it felt like a more complete solution. In that sense, we are making some departures from standard implementation of CoAP, but we wanted to make sure it's based on Open Standards and the important thing for us is that we open source the libraries so that people can replicate the communications.

Hackaday: So what are the risks with some of these departures from the standard?

Zach: Well, we really liked CoAP as a protocol, but fundamentally, nobody is using it. So in that sense it felt somewhat unnecessary to strictly follow the standard since there was nobody to talk to, whereas if it was MQTT we would feel more pressure to follow the standard and at the end, the purpose of all this is to tell - here's what we think is a good way for device to talk to the Cloud, but if you want other communications, if you want MQTT, you can. It's Open Source, and many people have done that. If you look at our community and look at some things that people have built - MQTT is a common one. And we're all about that. I think that, if you're trying to figure out device-device, MQTT is a great way to do that. But the fundamental infrastructure we're providing is more focused on device-to-cloud and so, for that reason, we felt comfortable with the departure. But it's something we continue to keep an eye on. The nice thing about a system that supports over-the-air firmware updates is that we can make changes to that in the future if there becomes more reasons to be more compliant with the original spec, we will keep that in our consideration set and can make that change.

Hackaday: This raises an interesting question - a question of device-to-device vs device-to-cloud. In terms of speed, we have a different set of expectations if we're receiving a text message vs. say, a phone call. How is that problem solved in the Spark implementation?

Zach: I would say that we have not so much of a protocol, but a design pattern how to do local communication, because, inevitably, one of the challenge of this open source project is - you don't really know what people are going to make downstream, they are going to do different things and might have conflicting needs and we want it to work for as many people as possible without being super-confusing. So, what we have done is said - we have a Cloud communication setup, it's good for global communication, it provides a good authentication layer, you can also use it to do local communication - but it's higher latency. We try to keep latency of the Cloud pretty low, currently it's 100ms + round trip time which is pretty good, but then there are things where you want to have a really real-time communication. So the design pattern that we're encouraging and that we're seeing people really using is basically saying - if you want to do local stuff, you can open the direct TCP socket, but you can use the Cloud for authentication. Say, if I have a phone, I open up a TCP socket on a phone and do an API call to the device through the Cloud that says "hey you, device, open a socket to me...here is my IP address on a local network". So the Cloud have authenticated that request, so you don't have to have ports open, which can be a security issue, and then you can do direct communication. One day we might publish a protocol, maybe for CoAP, maybe for MQTT, maybe something else for what these communications should be, but in the meantime, people are just generally doing custom "this byte means X"-style protocols implemented for their specific application. But it was important for us that we open up TCP/UDP stuff so that everyone can use it and we also have a perspective of, when we're not sure about an answer for something, let's just leave it open and see what people do and see if community starts to fall into a pattern and then let's just adopt that pattern.

Hackaday: Can you characterize the community, what's the size? You have 15000 devices out there, is that spread across 7500 users?

Zach: Yeah, that's about right, it's somewhere in that range. We have a very active community site, I don't know the exact number but we have some over 10,000 forum posts covering everything. When we look at the community what are people talking about - it's very implementation focused but it's a really really wide range. But there are tons of things you would not predict - they're pushing this technology's limits and we're learning from that. It's great to have such vibrant community so that we can also understand what people are up to.

Hackaday: Tell us about the Cloud side of things? What does Spark Cloud look like? What's that implementation?

Zach: I think the best way to describe what our cloud is, because there are so much companies doing "cloud" services for Internet of Things and we're in the world where vocabulary is core, because a lot of these services are different from each other but there are no words to describe this market yet. But our cloud is fundamentally a messaging service - it's making sure you can communicate with your device directly. A lot of other cloud services are focused on data and data visualization but we don't really have that yet. We do hope to add these capabilities at some point, but whether it's building it ourselves or partnering with some of these other services, we're not totally sure. Right now it's really about making sure you get messages back and forth. We provide a request-response model for communicating with your device remotely where you can essentially call function remotely and pull variables out of local memory from the devices. It's sort of 1-1 communications and also pushing firmware 1-1 and we also have a pub-sub model where devices can publish data, we're also implementing devices subscribing to data, I think this feature goes out today or tomorrow. You can publish messages either privately and publicly and also subscribe to these messages from other devices.

Hackaday: Take for example a temperature sensor. If we want to know particular details, like temperature or some register values, is there a shadow instance of that data that exists in the cloud? Or are all these requests going the full roundtrip?

Zach: Yeah. Also one of the things we're not doing right now is queueing messages, if your device is offline - it doesn't respond. There is a whole queueing aspect that we're yet to resolve, there's also something along the lines of "virtualized devices", being able to update their information and change the state when they come online, there's a bunch of pieces we're playing around with and thinking how to implement them, whether they're valuable or not, but for now, it the most basic - getting the messages back and forth.

Hackaday: Let's take for example an ADC where we have accumulation of data which is taking place over time. Are there libraries that would allow you to do things like moving averages of whatever that data is, buffer handling and all that stuff?

Zach: So if I am trying to so something like that, store bunch of stuff locally, do some moving averages, there's some information on the device that I might want to process and some I want to publish, they might be the same but might be different. So in that case what I would do is have a local function running in a loop, write my own buffer averaging implementation with some output and then I can, depending on whether I want it to be push or pull, I can either publish the message every 1 second, 10 seconds... or I can just keep the running average in the local variable and then expose that variable so that I can reach in and grab the data when I want.

Hackaday: Gotcha, so it's basically up to implementer to solve that problem?

Zach: Exactly. And there are some things you want to do in the web world and some things you want to do in the device wold and I would leave it up to you to decide for a particular product where this logic should live. And it's usually a mix of what lives in a Cloud and what lives in the firmware.

Hackaday: In terms of the actual Spark Cloud implementation - it's processing requests, brokering transaction etc. but you did indicate that at some point you'll tackle the data side of this. Do you have sense on how would the model for that look like? Would people pay to store the data in the Spark Cloud? Also there are a lot of problems - data models, history models, permissions etc.. Is that a problem for Spark to solve?

Zach: I wouldn't say I have an answer yet. As far as our development process goes so far we still feel like we're fulfilling the promises from Kickstarter campaign. And I would say we're at 85-90%. We hope to wrap all that up by the summer and all the features we implement as part of that will be Open Source as well. And then, going forward, the next step is to say - what else do we do? What do we do on top of this? And then every feature we create will be a question of - what do we give away, what do we charge for, what do we build, who do we partner with, do we open source or don't and I think a lot of that is still hazy for us. But the most important thing for now is making sure we wrap this up and deliver on our Kickstarter promises and have a base upon we can grow and we're really proud of.

Hackaday: What are some of these things that you still feel you need to close on?

Zach: There are several things that we have been planning to open source but haven't got around to yet, mostly as a function of making them easy enough for somebody to actually use. For example - for publishing the open source Spark Cloud we need to put some command line tools in place and that's one of the next things will be doing. iOS app is not open source yet because there are some licensing issues we need to work out with Texas Instruments and that's been holding up for a little while. There is a patch for improving stability that TI has been working on that we cannot yet deploy because they haven't completely signed off on it yet. There's also bunch of smaller but important improvements we want to make to our development environment that we want to do. There's also some things like library system where we want to make it easy to extend and add libraries and right now it's a pain in the ass. So we're putting in place package management system that I think will be very cool. We also want to make sure that if you want to do development outside our Web IDE, we want to make sure that the command line tool is in the good position to support that. Those are the bigger ones, I am sure there are a lot of smaller ones that are not coming to my mind right now.

Hackaday: Do you think that an effort to build a Web-based IDE might be taking you back in terms of the time it takes to build a quality IDE and quality dev environment? Was building an IDE a prerequisite?

Zach: Yeah so the real "killer feature" that we wanted to have in is over-the-air firmware update. You can build Spark Core into your product or project and then push firmware without having to disassemble or plug into something. And it's really powerful when you have a product in the field. It's definitely not easy both from development and Cloud perspective. I think IDE is not definitely done yet but I think the structure we're building is very powerful but it's definitely not for everyone - I think it's more geared towards the beginners. Basically, we have people coming from 3 worlds - novices, that might be familiar Arduino, but to which most of this stuff might be completely new, you have people coming from the Web world and they're used to using editor - Sublime Text, Vim etc. and there is a third group, coming from the embedded world where they might be more familiar with, say - Eclipse and more comprehensive IDEs out there. And so what we want to do is say - we have a solution for all 3 of these groups. For novice - it's Web IDE, for Web guy we say OK you can use Sublime Text or Vim but command tool provides the build environment that you need and then for the embedded guys it's Eclipse using the command like as underlying build infrastructure. So eventually that's where we want to go and building out the Web IDE and making it better all the time is something we'll keep doing, but it's also important to have other development environments for these other developers and the command line tool is just now getting ready for people to start using it in that context.

Hackaday: How do you solve the "bricking" problem of cloud-deployed firmware?

Zach: That's tricky. It depends on what do you define as a "brick". I have not yet fundamentally heard the case of someone actually bricking a Spark Core, which I am actually happy with. What we do have is a lot of ways in which it can get semi-bricked, like it's not working in the way that's expecting and you can factory-reset to the original firmware, which is a good back fall. It's one of trickiest problems, and I am glad that we have a good factory reset implementation that makes sure that nobody breaks their stuff too bad and, of course, worst case you can use JTAG etc. In theory, you can always get your firmware back but making that robust has been a big challenge and I think with every firmware push it gets better. We're doing a lot of checksumming on the incoming data but there's a lot of edge cases to cover. One of things we have been the most frustrated with is that this is such a common problem for connected devices but there is no open source implementation that we could find that really solved this. So I am looking forward to when it's kinda "done" and we can say "look guys, here is a way" and that can be something that others use in their projects, that we can say "here is the right way to solve all the edge cases to make sure you have a really robust implementation". Because, it is tricky and there so many cases to cover.

Hackaday: You're absolutely right. It can always be recovered, but if I have a seismic sensor somewhere in the middle of Mojave desert I have a long drive to there to plug in my laptop to recover that device. So it's very interesting to hear you're solving that problem. It's a noble endeavor.

Zach: Yeah, and another thing is - we're very much in the world in which we do our development in public, this is all happening in Github repos that are publicly available, tons of contributions come from our community members. There are some massive stability changes that came from one of our top community members that are such an improvement to the firmware. And that's the part we love we love about Open Source - its all, to some extent under a peer review. When people have concerns about implementation, we provide an opportunity for some of them to dig in and say, there is a better way and, say, issue a pull request. And we're seeing a lot of that which is awesome.

Hackaday: Tell us a little bit about supply chain side - supply chain issues, lessons learn etc. as you're building the Spark Core

Zach: The nice thing about Spark Core is that, as far as products go, it's really easy to make. I love that there is no plastic. Of course, that's true of any dev kit, dev kits in general are easy to make, but thank God we don't have injection molded plastic. I am grateful for that every day. So our supply chain challenges are relatively narrow. Supply chain is always hard and messy, but ours is relatively easy. We have a manufacturing partner in Shenzhen, they do everything, which basically involves surface mount and hand-soldering of pins, packaging and that's it. It's a pretty short supply chain. I think in general the main challenge was - we have never manufactured a product before our first manufacturing run. And so, there are always a lot of surprises that come with that. It was things like, teaching our manufacturing partner how to bake components correctly so that the yield was high enough and learning from them about design changes to make on PCB so that we have a good yield. Our first run was 10,000 units and manufacturing process was total just 3 days, because it's just surface mount, which is great, but also a problem because it provides no opportunity for feedback in the process. So basically, you're going to do 'em all so you better hope they come on the other side good. So we had to have a process that we're really comfortable with before actually starting the line. I think on our first run, yield was 95%, our second one was 99% or better and our third one was as well. It didn't take us that long to get to the yield that worked for us.

Hackaday: That's extremely high for boards. Is that all the way through the assembly? Because, there is a tendency for board shop not to return the panels that had bunch of failures on them.

Zach: Right. We don't see the failures there, we just get the good stuff.

Hackaday: What's the monetization strategy moving forward? Is it selling the hardware, selling the software platform? Is it support services?

Zach: It's a mix, definitely, of all three. One of the challenges we have been working through is... how does an Open Source company make money? I think it's not just a question for us, it's a question for a lot of companies that go into this space and there is a bunch of different models that we have been looking at to see who has figured this out and what can we learn on how they have been able to monetize their product. I think the way we have come out of it is basically the feeling that what we want to do is provide basic technology as Open Source and more advanced that we charge for. And so, that will be essentially providing additional features that we charge for and also focusing on helping support companies with large-scale deploys of connected devices. If somebody is deploying 10,000 or more devices, we're building a lot of expertise on scalable systems and our cloud is designed for "infinite scale" and we can sell services, which include SaaS but also implementation and other services along the way to help companies deliver these large-scale deployments. So, there is a core "cloud service" / "software as service" model of helping larger companies and startups to achieve that scale and then other complementary services. But these days, all we make is hardware.

Hackaday: So you need to get the data back-end side worked out to adopt that model?

Zach: Absolutely. And I think that will inevitably be the part of our next feature push for this summer. We have a couple of bigger customers that we're working with that will be helping guide us in terms of what they need. We're very customer-driven in how we do our product development. In Open Source world that means just opening everything and letting people participate and in enterprise world that means, we have some pilot customers, let's work through with them on what their needs are and how we can help them solve their needs.

Hackaday: Is there a path in which you partner with someone to build services you need on the back-end?

Zach: I think we'll end up doing that to some extent, because there are so many ways for data to be used and also many of our customers already have some data infrastructure in place for other data. And so, there are some problems which are device-specific and common problems that everyone will have about, for instance, high-level visualization of top-level metrics coming off the devices and being able to visualize logs that devices generate. I think that we will provide as a common interface because. There are some problems that are the same everywhere and we should deliver that as a service and there are other problems like - you have an ERP system, you don't need a second ERP system, you just want to plug your data into your ERP system and I think inevitably there will be both. And we'll say - look, we'll do some things ourselves but then we can also plug into various systems that you already have to pump the data to where you want it to be. I think fundamentally one of the issues we're seeing in market right now is this question of who owns the data, because you have IoT "platforms" that have the perspective that they really own the data and you as a manufacturers of the product are "renting" the data. I think our perspective is much more of - you made the product - it's your data. And we're here to help facilitate you having access to that. So we're putting in place products that feed your data back to you. But it's not data that we own.

Hackaday: Just one final question - you have gone to the process of being an Open Hardware Company, do you have a sense that that is going to be a problem in the long run? Or do you think it's potentially a big differentiator?

Zach: It's definitely different, I suppose. I think and hope it's more of an opportunity than a handicap. I imagine there will be cases where it is though. We had a conference where someone in the audience was talking about how he was making a decision between Electric Imp and us and ended up choosing Electric Imp. And it was a conference between me, Bunnie Huang and Jason from BeagleBone all on one stage and we asked "Why did you choose Electric Imp?" and he said... "well I thought Open Source means... lower quality, so I went with Imp". Bunnie and Jason and I were like "what the hell?? what are you talking about?". He talked about it - he's not an engineer and he comes from more of a business side and he sees more of a Photoshop vs Gimp and feels like Photoshop is a better tool and that proprietary tools are generally better. Whereas I think, if you're coming from more of an engineering perspective you're thinking Linux vs Windows and Linux feels like a better tool than Windows. And so, I think, in the consumer world, consumer proprietary products are usually better... because, design is hard to do well Open Source, whereas fundamental infrastructure, backbone kid of stuff is better in Open Source because it gets peer reviewed. And so I think it will be an asset but I think it's definitely going to be a marketing challenge or communicating that, we believe that Open Source leads to a better product. And I also think there will inevitably be some customers that we will loose out on because, instead of using our hosted managed infrastructure, they will build their own using our Open Source tools. I think that's OK. I don't think we're a solution for everybody and inevitably we're not going to get every customer in the world. I don't think Internet of Things is a world where anybody "owns" it. It's not the AOL of Things. We just see a huge opportunity and a growing space to solve the problems that companies are going to be facing. And so I am hoping that Open Source will be an asset. The other thing is that, Open Source Hardware... I think it's funny, I don't know why anybody doesn't open source their hardware. Because it is Open Source. All you need is an X-Ray and it's so easy to reverse-engineer a hardware design. I feel that anybody who doesn't open source their hardware is just... he might add a week to the time it take for someone to copy you, but it's just not that meaningful.

Matt Berggren / twitter.com/technolomaniac

Aleksandar Bradic / twitter.com/randomwalks