The long game


(Reza Akhavan) #1

I came across this and thought I’d share. In one day, these two brothers connected their home and made it smart, including custom rules. This is the first time I thought to myself, “I want that.”

It’s clear that core services (secure networking, speech, intent, rules engines, etc…) are what enable this kind of easy composition (as seen in the video). You could label these things as “services”, “platform” or “developer tools”. All things we’ve been told we shouldn’t be working on right now.

It a no-brainer that we (CD) need product trains and to focus on end-user value. From nothing to today, I’m proud of the progress with the trains. I worry though, about our lack of long term efforts/vision/thinking.

We need to budget resources along side our trains for these things. This is what’s going to enable our community to build the future of IoT with us. To create their own trains. To bring our values to IoT.

We have the unfair advantage to pull these things off and be trusted by the community while we do it.

Thoughts?


(Fabrice) #3

fwiw, the technical idea with Link has always been to build a platform, and to reuse results from other teams like vaani. To say that this has been a hard sell so far would be an understatement…

Here’s what Link, as a platform, is for me: We are building a solution
to let users delegate to 3rd party applications access to the devices
and services they control through their foxbox. That enables a full
ecosystem and not just a silo of apps “Link approved”: the user is in
the driver’s seat.

Pretty much like you delegate to your web browser a number of tasks when
you go to a website, I want Link to be a new kind of user agent that
people can trust. In our case, instead of trusting their browser (eg. to
not allow a dubious root CA), they have to trust the foxbox code and the
cloud services it relies on. Trust but verify! You can still build your
own foxbox software and hardware, and self-host the cloud services if
you prefer. We care very a lot about security and privacy, and I think
we have something that gives a very good balance of openness & privacy.

Having a cloud component is controversial for some people, but that can
actually benefit our users. Imagine that you granted access to your
devices to GreatApp, because they check all the marks in your book.
Sometimes later, GreatApp is bought by EvilCompany. Most people won’t
notice the difference. We should implement a system similar to the
malware/fishing blocklist that we have in Firefox, to protect users by
now preventing GreatApp from accessing the user’s resources.

The very flexible solution we are building is only showing a very small
part of its potential with IoT use cases in my view. But we have to
start somewhere, and build from there. Integration with 3rd party services
done right is a key feature, and I’m convinced we can truly come up with
something unique if we focus properly.


(Marcus Cavanaugh) #4

Composable software is key. “Do one thing, and do it well.”

Then, build products out of these strong, reliable building blocks.

That philosophy is the fulcrum that gives the Internet of Things so much potential: a world filled with simple devices, communicating intelligently together.

Today, our project trains have rightly been asked to take a step back to find concrete product ideas with tangible markets. This is important. But we have had great difficulty in coming up with inspiring product ideas that don’t sound completely infeasible for Mozilla. Why? Here’s one reason:


Achieving the Impossible

Grand ideas are composed of less-grand ideas. Big problems are composed of smaller problems.

If we wanted to build an “intelligent assistant”, we must first solve a number of largely independent subproblems:

  • Speech recognition
  • User Intent parsing
  • An abstraction layer over supported IoT devices and services
  • Algorithms for building “intelligence”, such as a basic IFTTT engine or machine-learning behavior

Building an “intelligent assistant”-like product becomes more feasible when good solutions to these subproblems already exist. Eventually, big ideas don’t seem quite so unapproachable after all.

Building products out of reusable, loosely-coupled pieces gives us the flexibility to quickly explore and execute on new products and ideas.

Mozilla is at a values-driven disadvantage, unfortunately. State-of-the-art proprietary services from Amazon and Google greatly simplify building powerful products. Many of the product ideas we’ve tossed around would be much more achievable if those services were available to us. However, because we stand for user control and privacy, we must take a different path: for some cases (and often the hard ones), building blocks that support our values do not yet exist.


Trains can’t solve Foundational Problems

Many problems don’t require a dedicated team. A product train can produce a reusable component that, in the open source tradition, other trains can use independently. But for an important subset of the problems we face in Connected Devices, casual code reuse is not enough.

Some problems are truly, deeply difficult. I often use “speech recognition” as an example, because speech is a difficult, hairy, but foundational aspect of IoT now and in the years ahead.

“Product Trains” are a wonderful idea for quickly testing new product ideas, but they cannot solve important, hard problems in a sustainable way. Product trains should be lean, agile, and focused, quickly proving the worthiness of a specific product idea. They don’t have time to dive into foundational problems without distracting themselves from their product.

Product Trains cannot build great products without proper building blocks. Dedicated teams can turn foundational problems into building blocks; trains alone cannot.


What about dependencies? Failure?

Leaders have expressed concerns that we should not place dependencies between trains. Indeed, having a “Speech Team” would place trains’ speech capabilities into the hands of one team: a capable, responsive, dedicated team who understands how to solve one problem well.

Granted, dependencies are points of vulnerability; that’s why defining clear, focused interfaces is so important when building software from decoupled pieces. Ultimately, the benefits of building products out of reusable, focused components far outweigh the inherent risks. Failure, in some ways, is the bread and butter of building blocks: when one fails or becomes obsolete, it can be replaced with less hassle.


Put simply:

  • Great products are built out of composable building blocks.
  • Proprietary competitors have powerful building blocks at their disposal; we have fewer.
  • Solving foundational problems requires sustained investment. Product trains are insufficient.
  • Dedicated teams can turn foundational problems into reusable building blocks.

(David Teller) #5

I’m basically going to agree with what @mcav writes, just with a different formulation.

Google/Apple/Microsoft/Amazon/… are now in position to offer great products because they have spent years investing in the foundation services/platform/tools. Moreover, a number of third-parties are in position to offer similarly great products by building upon the foundation tools provided by such companies.

Attempting to compete on the full product puts us at a strong disadvantage. It seems pretty clear that if we have access to no such foundation tools, it will take us years to catch up before we can compete on the same products, if ever. So we want to play smarter than that.

The good news is that our objective is not to sell products. Our objective is to contribute to shaping the future of IoT. As long as there are third-parties developing a product using one of our bricks, we are part of the future of IoT – and from there, we can go further.

So, one way to play smarter is to:

  1. Provide value early, without waiting to catch up with a moving target that has a big advantage on us. In other words, release reusable bricks, even without products.
  2. In turn, reuse existing open-source & privacy-friendly bricks as much as possible.
  3. … in particular, reuse our own, when we already have them.
  4. … and, for prototyping products, it might be acceptable to reuse less open-source/privacy-friendly bricks. This is something that needs to be decided on a per-prototype basis, I suppose.

(Reza Akhavan) #6

Are you sure about that? Please re-review the “Connected Devices Q2 Goals” internal email from Ari (April 22nd). And be sure to review the slide deck.


(David Teller) #7

I didn’t get it. It seems that I’m not on all internal mailing-lists yet.


(David Teller) #8

Well, it looks like I was wrong. But the fact remains that we need to play smart.

  1. Aim to solve simple problems. Not complex ones that would require us to catch up with a moving target that has years (or decades, in some cases) of R&D on us.
  2. Provide value early. In other words, release reusable bricks, even without products.
  3. In turn, reuse existing open-source & privacy-friendly bricks as much as possible…
  4. in particular, reuse our own, when we already have them.
  5. … and, for prototyping products, it might be acceptable to reuse less open-source/privacy-friendly bricks. This is something
    that needs to be decided on a per-prototype basis, I suppose.