After the current tech explorations and user research phase, IMHO we will have to pick one product to focus all our efforts on. I don’t think we are good enough to successfully build:
- a home automation hub that interacts with IoT devices, as well as
- a Thinkerbell/RemoteWorker runtime device to which third parties can push background code/rules, as well as
- an always-on microphone / voice browser for your living room.
We would be splitting our project into three focuses, and nobody could give a consistent answer anymore to the question ‘what is Project Link’.
Let me try to explain why I think the microphone product should be the one that should win our attention. This is very much “IMHO” and I definitely expect others to disagree with this, so maybe read this mostly as a strawman argument…
IMHO the home automation hub and the Thinkerbell/RemoteWorker runtime are not stand-alone products (by themselves they are a hidden helper product that people need to buy to get a desirable third-party app work). So we will never sell these unless we can identify a third-party whose product is exciting, and is useless if not accompanied by our helper product. Sounds unlikely to happen before December 2016?
On the other hand, as the always-on living room microphone is emerging as a new internet client device (next to laptop, tablet, smartphone) through which people interact with hosted services, I see a clear role for Mozilla. For a moment, forget about home automation and pro-active/learning rules engines, and consider only the ‘voice browser’ as a very simplistic “thin client” product that does very little processing itself.
This is the always-on, 1984-style, living room microphone as an internet client. The Amazon Echo is leading the way, and it’s not a secret that they’re selling it at an attractive price, so that it makes the user spend more on Amazon’s hosted services, and so that Amazon get more intimate information with which they can profile users. It seems likely that Google, Apple and Microsoft will launch an Echo-competitor. Oh and wait, I just checked and it seems that Google just announced theirs a few hours ago! http://www.billboard.com/articles/business/7377470/google-announces-home-competitor-amazon-echo
It’s obvious that these microphone products will come pre-configured to use the hosted voice-controlled internet services of their corresponding vendors. But what if we build one (just the microphone device, a very thin client) that allows the user to choose where to send their voice commands?
And what if the user can send different commands to different voice-controlled services - using multiple wake words to act like DuckDuckGo Bang-operators? It would break open this market (I guess since today’s Google announcement we can suddenly call “living room microphones” a market).
If we use an off-the-shelf microphone array for the hardware prototype, and only have to process the wakeword locally (no other complexity, so a very “thin” client, really just a voice-controlled search browser), all we really have to do is implement abstractions of the different third-party voice APIs.
The pivot would hurt of course (team focus always does, I guess, as it limits team members in picking what you want to work on), but if we assume we want voice (which it seems we’re doing), then consider the only alternative option: we would make voice an “added feature” of the product we built so far. It would mean we also need to do everything we need to do to build a simplistic voice browser device, as well as split our attention to IoT protocol adapters and the runtime device, all efforts in parallel.
IMHO, if we decide we want to do voice then that’s enough to keep our small team busy, and we should temporarily focus on doing only that and temporarily park everything else.
Once we ship and see market adoption, we can then add IoT connections and the scripts runtime back as added features, once we have them shippable, in the next OTA update of the base-product, to further amaze the user.