Like it or not, a whole new wave of Hardware Startups is coming our way. Crowdfunding campaigns are making it possible for everyone with an idea to "test the waters", tech-savvy Angel investors are eager to help successful ones cross over, and Venture Capitalists are sitting on the other side, always on the lookout for potential additions to their "hardware portfolio". It's these billion-dollar acquisitions that made everyone jump on the bandwagon, and there's no going back. At least for now.

That's all great, and we want to believe that good things will come out of this whole frenzy. But instead of staying on the sidelines, we thought we should get involved and start asking some hard questions. After all, these guys didn't think they will be able to get away with just some nicely produced videos and a couple of high-res photos, right?

For our first issue, we picked a relatively innocent target - Spark.io, guys behind the Spark Core development board. By embracing Open Source and Open Hardware as the core part of their strategy, Spark has so far been a positive example in the sea of otherwise dull (and potentially creepy) IoT "platforms". So we thought we should give Zach Supalla, CEO of Spark a call...

"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," Zach says explaining the motivation behind their original project called SparkSocket - connected lighting product inspired by helping his father overcome challenges associated with hearing loss. They ran a Kickstarter for this one, but only managed to get halfway to their funding target.

"The feedback that we had received from the market was that our product was not good enough," Zach said.

After iterating on product ideas and joining the HAXLR8R incubator program in Shenzhen, they eventually came up with an idea for the Spark Core and ran a Kickstarter, this time with great success. They have been shipping boards since the end of last year, and most of us probably already had a chance to play with one. We were curious about the choice of CC3000 as a WiFi module.

"This might still be true, but at the time of our launch, this was the only affordable WiFi module that you can 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 with them is that it's difficult to gain access to these chips in low quantities. And to be meaningfully Open Source, that was important for us," Zach said.

In terms of what other modules were taken into consideration, he says that "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 its a trade-off you inevitably must make. CC3000 doesn't add up to 802.11n, it doesn't do SoftAP setup, although they have their own thing SmartConfig, which is pretty slick, but has its quirks also."

On the communication side, Spark is using a slightly modified version of CoAP. "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. CoAP had much more of that defined and it felt like a more complete solution," Zach says.

Spark's approach to solving problems seems to be pretty open and hacker-friendly. Instead of trying to specify and define standards for everything in advance, they adopt a "learning" approach. "When we're not sure about an answer for something, let's just leave it open and see what people do, and see if the community starts to fall into a pattern, and then let's just adopt that pattern."

A good example of this was device-to-device communication using Spark. While device-to-cloud communication seems to be fairly well specified (after all, that is the core use-case), device-to-device aspect was left fairly open. In figuring out ways to address this, community seems to have converged into a particular pattern over time. Instead of doing this type of communication over the cloud (that might introduce latency unacceptable for real-time applications), devices use the "cloud" only for authenticating socket open requests. After this, all communication is done locally. Spark guys are now promoting this as an "official" design patterns for device-to-device communication and will probably end up building protocol-level support for it.

An aspect of Spark that we particularly appreciate is that, at least so far, their "cloud" infrastructure is only focused on one core and truly valuable use case - scalable messaging between devices. Usually this part is where there's much handwaving and magic involved, but in their case it seems pretty straightforward. And that's a good thing. They will also be open sourcing Spark Cloud in the next couple of months, so we'll be able to judge internals at that point too.

Even more important is their attitude towards the question of who owns the data that gets pushed into the cloud. "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," Zach says.

So far everything that Spark guys say checks out. They're doing all the right things; they have a healthy attitude towards privacy and data ownership; they're embracing Open Hardware, Open Software and actively involving community in the process. But as they keep moving forward, they will face a lot more pressure to monetize. And with that some of these core values might get challenged...

So I guess we'll just have to keep an eye on them.

Listen to the full interview recording, or read the transcript at The Hardware Startup Review.