Yes. My name is Jon McKay. I am originally from San Diego, California and I went to engineering school at Boston, at Olin College of Engineering. When I was there I majored in computing. So I did a lot of web development and mobile development for the first few years and then I started to get more into hardware development and how you actually make printed circuit boards. During my course load there, I met my cofounders and throughout our time in college, we knew that we wanted to start a company together and we were just looking for a good opportunity of something that we felt was –something fun to work on, but also something that could grow into a sustainable business.
2. So the Tessel boards were this idea?
Yes. Exactly. My cofounders and I, we did those web development classes together and we loved how quick and fast and easy it was to iterate on an idea. So, you can have an idea and by that evening have a prototype of it and show it to people and prove whether it is viable and we had a really good experience of web development. Then, in our final year of college we had an outside company come in and asked us to essentially teach other developers how to connect devices that do not have screens to their online platform so that you can gather data about real life and send it back to their platform. So, that was our first foray into hardware and we realized that the hardware tools are really not as good as software tools and it took us a long time read the documentation and see what tools are available, order them, wait for them to be shipped, figure out how to connect them, write the libraries for them in new languages that we did not know. We felt like it was a very different set of tools and paradigms and we thought that we could take all of the knowledge that we had gained from building software and apply it to hardware. So we thought “A lot of web developers are interested in learning how to get into hardware. Why don’t we redesign a hardware prototyping platform but design it specifically for these web developers”.
Ralph: Yes, that is a cool idea actually. You did this by crowdfunding with Kickstarter. Can you tell us a little bit about that? Did you have some knowledge before about crowdfunding and about actually developing a hardware product? Because that is something I would not have any idea how to start this.
Yes, we had no experience and we picked prototyping tools because it is easy to build a prototyping development board because compared to building tools , when you want to take a hardware product into manufacturing because that is just like exceedingly complicated. So, I think we scoped a good project to start with, even though we had no experience and we got lucky when we – I would not say lucky – but when we started actually prototyping and building the thing, we also built out our web site at the same time to try to gather what interest people had in what we were building. One of our team members started following influential software engineers from our Twitter account and finally one of them looked back at who was following them and saw what we were building and got excited and posted it to a popular software development forum where it just shot up to the top and we got a huge amount of traffic and we got like 10,000 people signed up for the product in 2 days. This was about 2 weeks before we started our crowdfunding. So we were worried that we had all this interest, but it was a little bit too early. But we started the crowdfunding campaign, and about 1 minute into it, we e-mailed those thousands of people who signed up and they flooded to our crowdfunding page and we had our goal within 3 hours. So, it was having that huge list of people who we knew were interested before we started the campaign that really led to it being a success.
Ralph: So, you seem to have the one idea that was really a huge success.
Yes, I think that we were able to capitalize on the fact that there are already huge excited communities around technologies like JavaScript and Node.js and around Node Package Manager. It was like we built those communities into our product so we did not have to go out and convince all these people about a new technology and that it was worthwhile. They already had experience using those tools and they understood the connection why it was viable in hardware.
I think that the biggest use case today is, like you said, private hacking. People who were previously not confident enough to start hardware, but they bought one and now they were tinkering with that at home. I think a lot of people bought Tessel because they were excited about the technology and not so much with an end-goal in mind. So they are still learning about hardware, learning about the different capabilities are and they are slowly working towards figuring out something that they want to build. Then there has been quite a big pull from education. Two weeks ago, I was in Guatemala and I was holding a workshop with one of my coworkers for a roomful of first year engineering students who had never done any programming, they had never done any hardware, but because we made it so easy, they were able to make simple demonstrations like if I clap, it will post the temperature to Twitter, which sounds silly and trivial, but for them it was really exciting.
They had never been able to have this sort of magic before in their life and now they are able to do something and they can explain a little bit about how it works at a high level. So now they have the confidence to dive deeper. Another big use case has been a Hackathon. There are a lot of companies that have started recently about the idea of cloud back-ends for Internet or Things and we don’t make the cloud. Our company does not make cloud. We simply make hardware. So, they are very excited to say “here is this Cloud Agnostic hardware. I’ll buy a lot of it, I will bring it to my Hackathon and then people will start sending data to my cloud”. So Hackathons have been a really big purchaser of Tessel.
4. An the production systems or the production environments – is Tessel suitable for such environments?
No. It is not. Interestingly, that is where we are spending a lot of our time now. For people who did buy Tessel with an idea in mind or a product in mind, they are able to prototype it quickly and then get to the point where they want to move forward with it and they come back to us and they ask us how they can do this. Really you do not want to use Tessel in production because it is a lot of parts in there, it is an expensive bill of materials and also you probably do not want to use JavaScript in production yet because you could simply run out of memory and your product will crash which you do not want for your user experience. So, we are working now on tools to make the transition from prototype on Tessel to a manufacture product really smooth so you do not have to start completely from scratch once you make something on Tessel.
5. How many Tessels did you ship or is this some kind of business secret?
It is no secret. We have sold about 2,500.
Ralph: Are you working on your sales channels because for Germany it is still a little bit problematic to get a Tessel. I don’t know whether this is better in other countries.
Yes, it has been a problem in a few countries. We ourselves were actually surprised about how hard it is to get something from point A to point B in the world. People have been doing this for hundreds of years. You would think this would be a solved problem by now. But, yes, we are starting to work with distributors. We just set up one in Japan, with Switch Science and that has been a really good experience and so we are starting to extend out other distributors as well.
We are not actually running JavaScript on the board. For example, you could use V8, the engine that Google uses to run Node, but the problem is that it uses a lot of memory and it is not optimized for an embedded device. So, if you used V8, you would have 8-10 megabytes taken up just at boot up and that is a lot of memory for an embedded device. So, we sort of set ourselves up so that we are transpiling from JavaScript to Lua, which is a small, embeddable language and they have really similar semantics. JavaScript has a lot of cornercases but it is not too difficult to transpile from one to the other and then we can run that Lua directly on the device.
The roadmap is to actually switch from a Lua virtual machine to a LuaJIT, which is an extremely optimized JIT written by a guy named Mike Paul and it is ridiculously fast. I was Google-ing the other day like how fast it is and I came across a couple of forum posts where some people say that sometimes LuaJIT can be faster than C or C++ which is amazing for a dynamically type language. So, we have been doing some work on getting LuaJIT ported over to these small embedded micro-controllers and just in our early benchmarks we have seen that it is about 120 times faster than the virtual machine that we are running now. And it is even faster than running it with V8 in which Google invests a lot of time and money optimizing. That is really impressive that one man and our team – essentially one person and our team – can build something that is even faster than that organization can put together.
Yes. There is a couple of limitations in terms of what our architecture is now. Right now we are transpiling from JavaScript to Lua on a host machine, before sending it to an embedded device and that means you can’t use functions like eval() or the function constructor on Tessel because it needs to have that JavaScript string converted to Lua, but that functionality is only on the computer and eventually we would like to move all that logic onto Tessel so that you can do that now. In terms of limitations of using Lua on an embedded device in a product, it is tough to say because right now, if you have a dynamic language like that, it is always going to be prone to running out of memory at any time, depending what your code is. So, right now, we are advocating that people move their code over from JavaScript to another type-safe language like Rust before they move into production.
Yes. Right now we throw a lot of Hackathons so we have 2 or 3 events a month with customers and so we have that direct feedback like “It would be great to have this module” or “It would be great if I had this module”. We e-mailed like 500 customers directly just to ask them what they think of Tessel and what sort of new features they would like. Then we also have a survey on our modules at the bottom of the page where, if someone scrolls through all of them and they do not see them, we have a button where you can suggest the modules. So, we have data about which modules are most requested and what people want. And it is also sort of about following the trends of seeing what type of applications people do. So, is it just people putting one sensor on Tessel and then putting it up on a wall and logging data or they try to do more real-time applications like having a proximity sensor on there and moving it on a robot and seeing what type of applications in general people are going to do dictates how we build modules in the future. So, that is the sort of information we look at.
It is a good question. In a large part, it depends on what the module is, but the short answer is that it takes a lot longer than you think. The hardware is usually pretty quick because for most applications – for example AdaFruit and SparkFun have done a really great job on open-sourcing their designs – so for a lot of the modules we had made already it was mostly looking at the their designs, seeing if we needed to tweak anything for our micro-controller. If not, we put it on hardware, get a spin of the circuit board within a week or two and then we have hardware that we can test out.
Then, while that hardware is being made, we write a software that we are going to use to test the hardware so that when it comes in, we just put them together and we try it out. Now, that is only part of the story because once you have that, then you have to make the test rig. So if you had the design files that you sent to China to manufacture, you have to also make the test rig so that once it comes off the assembly line, they put it in a Tessel, they push a button and then it is going to do all the tests on the hardware and the software to see if that works.
Then you also have to write all the software tests to make sure that the driver, the code itself, not the hardware, is working. So right now, our solution is not very elegant, but basically, what we have in our office is a laptop connected to 4 Tessels with every different module plugged into it and every module has its own suite of test. So for every change in our firmware or our run-time, we run those tests on every module to make sure it does not break anything. So, in reality, the actual building of the module itself is a small part compared to all the test infrastructure that has to go into making sure it does not break the entire system.
Ralph: If you look in the market, my impression is that a lot of competitors in the meantime also have the advantage that their boards can be used very easily and can be programmed with JavaScript too. Is this a problem for you? Because after all, Tessel is a fun project for the customers, but for you it is your business.
Yes. It is great, really. Back when we started this, almost two years ago, that ecosystem did not exist. There was Arduino, you know and there was the Raspberry Pi and there was nothing that could get you connected to the internet easily. Now there are tons of those devices out and that is actually good for us because it is really expensive to make hardware. So, what we have built and we are sort of polishing right now is this sort of idea of a portable Tessel platform. So, we think that we have the best developer experience in terms of being able to write code and then being able to prototype really quickly and we just want to enable that same experience on these different platforms that exist. So to be able to say “Here is a back pack for you BeagleBone. You can put it on and then you can plug in Tessel modules in there and program them just as you would on Tessel”. That means we do not have to necessarily make as many Tessels and people can have that same experience across all the different hardware platforms.
10. What updates are in the queue?
There are a couple of things that we are working on - the portable platform Tessel is one of them – and we are also working on this idea called Fractal, which is basically, at a high level, how you take a firmware and from that firmware create a circuit board. So, we want to enable people who don’t necessarily have the experience of building hardware, designing schematics, the ability to just say “Ok. I have this firmware. Now give me 5 of these circuit boards so that I can test it out on my own and eventually move them closer towards manufacturing”.
You mean, besides my own?
Ralph: Besides your own.
One project that I really like – we have a developer in Mexico, I believe, who has an apartment building with an elevator in the middle and the elevator would go right through his room. But the elevator button was broken so he connected it to his Tessel and then connected it to the internet so that he can just text the elevator and it will come down to get him or he can give out the phone number to his maid or his friends and it can just automatically take him up and down. I thought that that was a better solution to the problem then the button originally was because before, he had to go out and let the maid in, but now everyone can take care of themselves and the security is all in the phone number.
Ralph: That is cool. Thank you very much for giving us the time to talk to us. It was great fun.
Thank you.