Hi Sergey, thank you so much much for agreeing to this interview! Can you tell us a bit about your role at Mongoose OS?

I am a technical cofounder and CTO of a company behind Mongoose OS, and set the  overall technical direction for the project.

 

For my readers who don’t know Mongoose OS, could you please explain in one or two sentences what it is?

Mongoose OS was born from our commercial integration experience. We specialise in building firmware for commercial products, and we found out that firmware development, generally speaking, consists of 10% of product-specific functionality, and 90% of generic infrastructure functionality. That generic functionality includes product configuration, remote management, OTA firmware updates, cloud backend integration, security/encryption, etc. It takes huge amount of time to get it right. And most product companies reinvent the wheel, developing that infrastructure part from scratch, often compromising on things like security.

Consider a simple product – a smart plug. It is, in essence, a WiFi enabled microcontroller, with a relay to switch things on and off, and an LED for status indication. You can prototype with something like Raspberry or Arduino in half an hour.

But if you need a production firmware, with factory reset, configurable via mobile, with secure backend integration, with mutual cloud authentication, remote management, OTA – it’ll take you 6-18 months to get it right and much more time and resources to maintain and support it.

With Mongoose OS, you still can do it in a half an hour. Mongoose OS is a cross-platform IoT operating system, providing a generic infrastructure layer for smart products, targeting production environment. We have taken care of all the intricacies, constantly update and maintain it and provide an ongoing support to enterprises utilising Mongoose OS in their products. All this significantly reduces a time to market and cost of launching and maintaining the product for them.

 

Who is your main target group, do you see the Mongoose OS ecosystem as an alternative to the Arduino IDE or are you focusing more on the professional embedded market?

Mongoose OS’s primary target are professional firmware developers and companies bringing connected products to the market.

That said, Mongoose OS is quite appealing for the maker community, because it has JavaScript engine for rapid prototyping, hassle-free build toolchain, libraries and example apps that can be reused, and more. We believe that Mongoose OS is even easier to start with than Arduino IDE, because of the JavaScript.

 

Where does Mongoose OS shine compared to other ESP8266 firmwares/ platforms like ESP8266/Arduino (C/C++) or NodeMCU (Lua)? What are Mongoose’s strongest features?

I would emphasise several features:

• Remote Procedure Calls – you can write your function in C or JavaScript, and call it remotely via Serial, Bluetooth, HTTP, Websocket, MQTT. It’s magical, and it is the cornerstone of the Mongoose OS remote management.
• OTA firmware update with rollback on failure.
• JavaScript engine for rapid prototyping.
• Many cloud integrations, like AWS IoT, Azure IoT, Google IoT Core, and other.
• Strong emphasis on production deployment. That drove many design decisions, like layered configuration with factory reset support, which are not so vital for makers projects, but a must-have for production.

 

There is a lot of peripheral hardware out there which is often using interfaces like SPI or I2C. How hard is it to get new hardware (e.g. sensors/ displays) to work on Mongoose OS?

In most cases, it is trivial. Mongoose OS provides cross-platform I2C and SPI interfaces, so if you made your device working on one architecture, it’ll work on all other supported architectures. Also, Mongoose OS has an Arduino compatibility library which has Arduino’s SPI, I2C and GPIO API implementation – that means, if there is an existing Arduino driver for your device, it might work as-is on Mongoose OS.

 

A JavaScript engine is running on the microcontroller but developers can also choose to write code in C/C++. Usually interpreters bring a certain amount of overhead in memory consumption and CPU performance compared to firmwares compiled to machine code. Do you see JavaScript code also running in production with thousands of deployed devices or is this rather for fast prototyping during development time?

Both use cases are possible. Our mJS JavaScript engine, which we designed and developed specifically for Mongoose OS, has footprint and runtime cost indeed. We anticipate two major use cases:

1. Rapid prototyping during development.
2. Not performance-critical logic in production that is changing often.

Imagine that your device has a logic that is not performance critical, but you’d like to modify it easily in production. One of the ways to do it is to script it. If you take some sensor measurements every hour, do some simple calculations with varying parameters and report the result – JS can do it perfectly, and that justifies using JS in production. If you need to stream video data from your OV7670 camera module, it is C/C++ full stop, don’t even think about JS.

 

The Particle devices can be programmed through a Cloud IDE. While your IDE also runs in the browser it’s connecting to a local server started by the command line tool. Are there any plans to offer a similar cloud based IDE? A interpreted language like JavaScript would be ideal for such a case…

Yes we have considered that already. There are many other opportunities – like integrating with Cloud9 or other cloud-based IDEs. Or, making plugins for Eclipse, VSCode, etc.

Currently we’re concentrating on the core functionality. Some community members are already working on extending our IDE support, so we expect news on that front soon.

 

Your Mongoose OS has a dual license system. It is either licensed under GNU GPL 2.0 or a user can also pay for a commercial license. I find licensing always a bit confusing. Does the viral feature of the GPL mean that my code written in JavaScript or driver extensions in C/C++ are also under the GPL and therefore must be open sourced? Of course unless I opt-in for the commercial license…

Mongoose OS drivers, and other reusable pieces of functionality, are implemented as libraries. They are also hosted on GitHub, just like Mongoose OS – each library in its own repo, consolidated under https://github.com/mongoose-os-libs organisation. All libraries are also listed at https://mongoose-os.com/libs.html. We deliberately require all contributors to release libraries under Apache 2.0 license.

Therefore, driver code is Apache and it is not infected. Anyone who uses Mongoose OS libraries, does not need to ask a permission from the library’s authors to use the code, or buy any separate license for a library. However, if the final product is commercial and uses Mongoose OS core, then a commercial Mongoose OS license should be purchased, unless the end product’s source is open to public under GPLv2 as well.

 

Now I’d like to ask some more general questions about Internet-of-Things. When I design a new IoT project I am often faced with the decision how much logic I write for the embedded device and how much on the server side. In business application world we had and have a similar dilemma: running more logic in the web browser or more on the server. Recently this shifted heavily towards the client/ browser. Where are we going here with IoT devices?

As with many other decisions in this world, the answer to this is driven by money. In case of IoT, there is a cost associated with:

1. Hardware.
2. Firmware development & support.
3. Traffic.
4. Cloud backend development & support.

If the traffic price goes down a lot, I could stream more raw data cheaply to the server and do data processing on the cloud, and hire less expensive backend developers, rather than expensive and hard-to-find embedded developers, who can program and support local data processing. Here, shift goes towards cloud.

If the hardware price goes down, like with the Espressif chips, we have more power on the device side, and now it is feasible to have more processing locally – the shift goes towards the edge.

IoT is a large niche. Home automation use cases have their own balance for these 4 factors, other verticals, e.g. Healthcare use cases, their own. Which factors are going to win overall, is very hard to predict.

IoT itself happened because of factor (1) and (3): 20 years ago, both the hardware and traffic were already available to make smart products, but yet too expensive to make it feasible for widespread adoption. Following the Moore’s law, hardware and traffic costs dropped immensely, and now it is feasible to incorporate microcontrollers into less and less expensive products. Mongoose OS is targeting factor (2), dropping the price for firmware development down.

 

Do you know the Gardner Hype Cycle with IoT today? Where will IoT have a first breakthrough in your opinion? Industry 4.0, Home Automation, Smart Cities?

Again, that will be driven by money.

Industry 4.0, in my opinion, will use enterprise money to optimise production costs.

Smart Cities – government money to optimise infrastructure costs.

Home Automation – enterprise money to create extra services and upsell. This is a consumer market, and IoT brings something very new. Before, vendors were selling their products, and they were loosing the connection with their customer after the purchase. If I bought a washing machine, a washing machine vendor did not have a clue about my experience, usage patterns, used functionality, etc. Now, a vendor can have a direct and continuous connection with the customers during the product life time. I believe that brands will pump significant resources money into securing and expanding their customer base using IoT technology. Also, consumer market is more agile in comparison with regulated Industry or other markets. Thus my bet would be on the consumer market, consumer-oriented niches, which includes Home Automation, Wearables, etc.

 

Sergey, thank you so much for this very interesting interview!

It is my pleasure, thank you for taking your time!