I’ve spent the last 13 years as a software engineer, working mainly on 3D graphics and compilers. Developing for microcontrollers had always been a hobby, but I found the existing ARM microcontroller development tools to be very difficult to install and use, especially on Linux. Spending hours wrestling with software tools in the evenings after I’d already spent a full day in front of a computer was extremely frustrating, so I set out to create something I’d find enjoyable to use, not painful.
I wanted to move all of the toolchain onto the microcontroller itself, allowing anyone to program it, from any platform, using JavaScript. My goal was that someone with minimal programming knowledge could start blinking a light on a microcontroller in just a few minutes, rather than hours. With that in mind, I started a project I called Espruino — the name is a portmanteau of Espresso (given the coffee associations of Java and JavaScript), and Arduino (whose “uino” ending has now become synonymous with microcontrollers). I’d written an extremely basic JavaScript-like language interpreter called TinyJS for another project of mine, and five years ago, after a mammoth hacking spree in which I rewrote it from scratch to use statically allocated memory, I committed my first code into a Git repository.
A few months later, on a vacation in Wales with friends, I got it to work. I remember the feeling of accomplishment as I saw the little ST Discovery board print out a Mandelbrot fractal line by line. However that was just the start of a long journey, which has now turned into a full-time job for me.
Freemium Software
Shortly after, I decided to put my work online — not open source initially, but free to download. I soon found myself spending a lot of time trying to help users through the arduous process of flashing firmware onto the microcontrollers themselves. I realized that if I was ever going to be able to keep working on Espruino properly, I needed to spend a lot more time on it, which meant finding a way to provide myself with a salary.
My first attempt involved making Espruino “freemium.” I added the ability to save an image of the currently running code into flash memory and charged $4 for it — unfortunately, over an entire year, I only made $40 despite spending weeks helping users out. I had significant downloads, but very few people were able to install the firmware and get far enough past the “Hello World” of blinking LEDs to even save what they’d done.
I tried to contact all of the STM32 board manufacturers I could find about preinstalling Espruino, but none were willing to take a risk on what was, at the time, a relatively unknown bit of software. So I decided to do something myself.
Kickstarting a Board
At around this time, Kickstarter had just opened its doors to creators in England, and I thought I’d give it a try by making my own board. If it went well, I would open source everything and be able to spend more time on Espruino, and if it didn’t, then I’d shelve it and get a proper job. It went better than I ever could have hoped, and I got over £100,000 in funding from a video my wife and I had knocked together with a cheap camera and iMovie. So I started working on it full time.
The whole Kickstarter experience was amazing — but it was hugely stressful and took a massive amount of time. I was pretty new to designing PCBs, so I used something called the OPL (Open Parts Library) from Seeed Studio. This was a part kit you could buy that also included all the part outlines for PCB design tools. Once I’d put a working prototype together, I was able to give the designs to Seeed, who would manufacture the board with all the parts they already had in stock. This meant that even though everything had taken longer than planned, I was able to ship the boards just one month after the expected ship date.
Seeed mailed the individual Espruino boards for me; however, I had also offered some starter kits to customers containing a lot of different electronic components, so we had to assemble them ourselves. That was a bit of an eye-opener. When I make software, 500 downloads doesn’t seem like that many at all — but it looks quite different when you have to pack kits, label them, and make sure they are delivered!
Now, almost five years after writing my first lines of code, I’ve just completed shipping out all of the rewards for a third Kickstarter campaign: Puck.js, a programmable Bluetooth button. There’s now a great community of users around Espruino and a forum with over 20,000 posts — fueled mainly by the enthusiasm of my Kickstarter backers. Everything is open source (hardware and software), and yet I’m finally at the stage where monthly sales of Espruino boards are enough to pay me a salary — without the need for Kickstarter campaigns to prop me up.
Porting Produces Problems
Because the firmware and tools are open source, Espruino is being used on more and more devices. The Espruino community ported Espruino to the ESP8266, and as of the end of 2016, more people were using ESP8266 than all of the boards I sell combined. In fact, only one-third of Espruino users were actually using a board that I’d made.
This is fantastic, but it does lead to some problems. I’d always prided myself on offering really good support to users on the Espruino forums — often spending two hours or more every day helping out. As the fraction of people using my boards has dropped, I’ve found myself spending an increasing proportion of my time effectively working for free.
There are very clear benefits of an open source hardware business — for everyone. The costs of individual electronic components and production drop off drastically at higher quantities, meaning that most open source hardware companies can afford to sell their products for less money, while still giving you all of the designs so that you can see how they work and fiddle with them.
Open source software usually relies on offering a consulting business around an open source product — where you can work with your software more efficiently than others can. However, things get a lot murkier when open source hardware and software collide — which will be happening more and more in the future.
In Espruino, the aim has always been to replace hardware complexity with software complexity. The hardware is very simple, but the software is extremely complex and takes the vast majority of the development time (at least 10 times more). I have to mark up the cost of my hardware in order to pay for the time it takes to develop the software. This makes my boards very uncompetitive compared to a $2 ESP8266 board that’s had Espruino flashed onto it for free, or even another company selling a board with Espruino preinstalled.
This does hurt sales a little, but the biggest problem is actually that of support. If you have a problem with a normal open source hardware board, you’ll talk to the manufacturer. However, if you have a problem with an Arduino clone that you bought from eBay, you’ll go to the Arduino forums. The same is true of Espruino, and users of these other boards generally have more problems because of bad documentation and out-of-date/buggy firmware. It can be very frustrating to provide an appropriate level of customer support and not spend too much time on everyone else but myself. This is especially difficult when I can’t even determine who is using what board!
In normal open source software, you’d hope that contributions from the community would go a long way towards making up for this, but when writing tools for embedded software, this may not happen as much. The majority of my users like Espruino because they’d prefer not to write C code, so it’s highly unlikely that they’ll dive into the optimized C source code of the interpreter. When writing software for the desktop, you can write tests to ensure it works correctly — and while this is done as much as possible with Espruino, to fully test the hardware APIs, you have to run them on the hardware itself. Although most contributors test their code on their own boards, they’re very unlikely to test it on the four types of Espruino boards I make, let alone the 40 other types of boards that Espruino runs on. So even vetting contributions can take a lot of time.
To top it all off, the software that requires all of this effort to maintain has little to no value. I’m unable to license it to any interested companies, because they can use it however they want without a need for one. Instead, all I can do is charge for services I provide on top of Espruino, such as maintaining a port or adding some functionality.
Although I’m able to pay myself a salary, it’s purely out of the generosity from the community, not because I have a great business model. I can’t help but feel that the lack of a clear business case for the use of open software tools with open source hardware is hurting innovation in the field. I think it’s telling that there are now hundreds of venture capital–funded Internet of Things websites. At the same time, despite millions of users, the Arduino IDE hasn’t noticeably changed since the first alpha release 10 years ago, while the Codebender online IDE has had to shut down.
Having said all that, I am in the very fortunate position of being paid to do my own thing. Espruino wouldn’t be as popular as it is if it weren’t open source, and I use open source software myself almost exclusively. I’ve had some fantastic contributions to Espruino from the community (for example, the ESP8266 and nRF52 ports), and even bug reports from users of other boards have improved Espruino’s reliability for everyone. All things considered, I definitely benefit from open source software, while feeling like I’m also giving something back.
ADVERTISEMENT
