Like it or not, a whole new wave of Hardware Startups is coming our way. Crowd Funding 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 Hackady should get involved and start asking some hard questions. After all, these guys didn’t think they’d be able to get away with some nicely produced videos and a couple of high-res photos, right?
For our first issue, we picked a relatively innocent target – Spark, the team 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.
What sparked Spark
“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 of the motivation behind their original project called Spark Socket – a connected lighting product inspired by the need to help his father overcome the challenges associated with hearing loss. They ran a Kickstarter campaign for the product, 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”
After iterating on product ideas and joining the HAXLR8R incubator program in Shenzhen (a program we first looked at a few years ago), they eventually came up with an idea for the Spark Core and ran another Kickstarter, this time with an astounding response which produced $567,968 with a goal of only $10k. They have been shipping boards since the end of last year; most of us have already had a chance to play with one or at least wish we did.
We were curious about the choice of CC3000 as a WiFi module and [Zach] came back with a reason:
“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”.
In terms of what other modules were taken into consideration, he said that “The main ones that we were evaluating at the time were RN-171, the 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 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”.
Open Development Process
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 the case of device-to-device communication using Spark. While device-to-cloud communication seems to be fairly well specified (after all, that is the main use-case), the device-to-device communications was left fairly open. In figuring out ways to address this, the community seems to have converged into a particular pattern over time. Instead of doing this type of communication through the cloud (which, 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. The Spark team is 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 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 the 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”.
So far everything that the Spark team 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 they actively involve 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 values may be challenged.
We’ll just have to keep an eye on them…