Erik Kettenburg Founder Digistump


Osborn: Say  somebody who’s new to the whole maker  thing, but they want to get plugged into the culture or movement, or whatever you want to call it. Do you have any advice for the complete novice who wants to start learning things?

Kettenburg: With the Digispark, I see a lot of people who are just starting because I think the price point appeals to people wanting to jump in, but not willing to fork out one hundred bucks in parts. I think my biggest piece of advice is to find something that you think you’ll be passionate about, that resonates with you. I mean, the maker culture is so big now. There’s 3D printing. There’s electronics. There’s all the subparts of electronics. There’s the craft side of it, the clothes making, and then of course combining electronics and clothes. I just see so many different  aspects of it. I see a lot of people jump into whatever’s hot. “I’ll get a Digispark  because I want to be a maker!” But I think you need to pick an end result that would be cool. Are you after  blinking  LEDs? Or would you rather make a toy elephant, plastic elephant, or something? So I think that’s the first thing. It’s so big now that you can really just look around and pick where you want to jump in. Then once you do jump in, I always jump into things with two feet for better or worse, so I always recommend that. Go for it and get involved in the com- munity. I know we have  a lot of beginners who read our forums3   and don’t ever ask questions. And they should be asking questions, because for the most part, the maker community is very friendly. More than any other community, there are so many people who are new to it. I would say that compared to Massimo [Banzi] over at Arduino or Bre [Pettis], you know, those people, I’m pretty new to it even, at least new to having it be a large  portion of my life. And I’m still on those message boards asking the stupid questions and getting great answers. So I think the first step is to jump into the community. And there are so many communities  to choose from. It’s not hard to find one that both has the same interests  as you do and is very friendly.

Osborn: So there’s  kind of the next step, a lot of people have projects  or ideas that they’re working on that would bring it to the market. Do you have any advice for those people?

Kettenburg: Build a prototype. I get so many e-mails about that. E-mails, Kickstarter messages, and they  all start like, “I have this idea. I think it will be a great  product. What was your secret? What should I do next?” All those kinds of questions. When the Kickstarter [initiative] was going, I’d get about one of those a day. Now I probably get about one of those a week. Mostly I get people who have an idea and haven’t tried to build anything yet. I think often we get held up on, “I have this idea. How do I build that product?” And, really, the thought  process needs to be, “I have this idea. How do I build—to use a startup term—how do I build the minimum viable product?” But a better ques- tion is,“What can I tape together, stick together to do what I want this product to do, even if it doesn’t work right, even if it costs five times as much?”

Personally, I always get held up on things like, “I have to design the perfect circuit board.” Instead, I should be building it on a breadboard  first. So I think the best advice is to do it, build it, test it, and tell people about it. People are always afraid  that their ideas are going to be stolen, but you know, you’re really not that important. Your idea isn’t that important. If it’s worth stealing, somebody will pay you for it then. And talk about it, be passionate about it, and actually build it. I think once you actually  have a working prototype, the way the economics of starting  a hardware  company or launching a hardware  product,  just now with Kickstarter, with all the clones of Kickstarter, is once you have a proto- type, you can test your market really fast, which is amazing, because you don’t have to invest the tons of money that I’m sure Arduino invested before they launched their product, and then all the money they invested to get their product out there and get it known, and how many years that took. Now you can do it in thirty days. I think it’s important to not spend too much time building that first prototype, to not make it perfect, because the laws of busi- ness still apply: most things will fail. I actually had a Kickstarter  project before the Digispark that failed. It fell flat. Nobody was interested in it. And it was a software  project. It was a software as a service  dashboarding  application,  intended  to provide real-time metrics. And I thought it was such a great idea. I thought it would  be a big hit, and it fell completely flat. With the Digispark, I thought maybe I could sell one hundred of them, and it took off. So I think you’ve got to build it and test it, and test the waters and not spend too much time on the details until you do that.

Osborn: Great advice. Can you tell me a little bit about—can you give me some examples of hiccups you’ve had along the way or maybe speed bumps— unexpected  challenges that you’ve had?

Kettenburg: Yeah, definitely.  Well, the first unexpected  challenge was we set out to raise $5,000—and we raised $330,000 and about another $60,000 in preorders.

Osborn: It’s not the worst problem in the world to have.

Kettenburg: Yeah,  not  the worst  problem, but logistically   that’s   a  big problem. I went from being a small customer  for a surface-mount  assembly shop to requiring a significant percentage  of the factory, of the whole factory, to produce our product.  As a point of reference, to produce thirty thousand of them kept the factory—a good regular-sized production facility—working for three weeks. I’m sure they had other little projects, but that was their main project for three weeks, the first thirty thousand. So that created  a lot of scheduling problems,  a lot of sourcing problems.

The first thing I found was there weren’t thirty thousand ATtiny85 chips, which is the main IC on the Digispark. There weren’t thirty thousand of them produced. So we had to go to Atmel, the manufacturer, and say, “You’ve never heard of us, but how fast can you produce thirty thousand?” This chip generally doesn’t sell that well. I think ATtinies—used for hobbies, and another Kickstarter project, the Blink1—was  also trying for the same chip and had just been fairly successful. But, generally, the ATtinies were used in things like alarm clocks, where the production was scheduled  months and years  in advance, and they worked directly with the manufacturer. So we ended up with a ten-week  lead time to get those parts. Ten weeks was the longest lead time for several parts.Almost every part had a lead time. Most had to go back into production to meet our numbers. That took several weeks to get straightened out and get the right manufacturer who could make enough of them.

We knew—at that point, we already had this looming problem of shipping everything. We sold twenty-five thousand Digisparks through Kickstarter  and the preorders that followed immediately. At that same time, we sold twelve thousand kits because we offered about twelve different shields,4 you know, same  idea  as Arduino shields, but to plug into the Digispark. We did that because people  were asking for it, not fully comprehending what we were getting ourselves into. By the time we shipped everything, we had twenty-six different things that could go in any given package, because we offered them both as a kitted version and as just the PCB board.

On Kickstarter, you’re always  getting pushed  to set goals, bonuses  when you reach a certain amount—stretch  goals, that’s  the word I’m looking for. If the project reaches certain funding milestones you might offer add-ons or bonuses. So we did free stickers with that. We discounted one of our kits down to $1, which resulted in eight thousand of them being ordered. We had this huge logistics problem. We had to order all those parts. We had to kit them all into little bags, and we had to ship them all.

The biggest issue there was that the Digispark  was so cheap that it didn’t make sense to pay a fulfillment  house to pack them for us. To have a fulfill- ment house pack them was going to cost about $6 on average per package— not including shipping—and we had put $5 of shipping into our price. So we ended up doing all of that in-house, my wife, Jenni, and I. We pretty much immediately started kitting things and ordering parts. We filled an entire bed- room, probably floor to halfway up to the ceiling, with just boxes of parts and boards. So that was a huge challenge, and it took us just about two months to ship everything, and we ended up shipping sixty-five hundred packages. I had never shipped anything commercially before that.

The other bump in the road—we ran into several bumps in the road with the factory—was that we were programming the chip in a slightly  uncom- mon way, and so their programming hardware wasn’t working. So we sent them  samples. I hand-assembled some samples and sent them, and then they 4A shield is an add-on circuit board that attaches to the main microcontroller  to provide additional functionality or peripherals.tried to match that exactly. I sent them five test jigs on which you could hold a Digispark down and it ran through all these self-tests. They couldn’t get it to pass the test because it wasn’t being programmed  quite right at the factory. That threw another month and a half into back and forth—videos, phone calls, e-mails—just trying to get it right. Eventually, they got  the right combination of programming  hardware, and it  turned out that they had tried to  cheap  out and bought this slightly cheaper version of the ATtiny85 from Atmel. Luckily, they had only gotten the sample quantities  at that point. That version didn’t work because  it couldn’t run fast enough to run the USB end of things. So there were plenty of hurdles there. Then aside from the hardware side of things, we were trying to do something in software that had only kind of been done. Making an ATtiny chip talk over USB isn’t a standard function  of that chip, so we were completely bit-banging the USB functions.  The version that I showed on my Kickstarter video was the first time I had ever gotten those functions to work. They still had some hiccups in them. I think it would have been no problem, again, if we had had five hundred or so, or one thousand, or even five thousand. But so much time ended up being consumed just by managing everything  that it left a whole  lot less time for the software end of things. So  in the end, we got  help with the bootloader that would actually  do the USB functions—do  the programming over USB. You know, I had some starting points, I had it mostly working, and then one of our supporters actu- ally stepped in and helped put together the final bootloader that we ran with, and that’s an open-source  project.  In return, we essentially sponsored  that project. We kept it, but we don’t own it, we don’t have any rights to it, so we used it and we sponsored it to keep them going and inspire them to get it done in time for the factory to ship it. I think in the end that was a really great outcome, because in the end that got the community more involved. The bootloader created this entirely separate project that I know other people are already looking at. Adafruit has a device  called  Gemma,  a device coming out that’s based on the ATtiny85, pretty similar to the Digispark. It’s made to be sewable. I think it has three input/outputs  instead of six, but I  saw  they’re considering  using that same  bootloader.  And people have started contributing to it. It’s now on GitHub. There’s now like three different versions of the bootloader. When you first power up a Digispark,  there’s  a five-second delay before it runs your code, while it waits for a USB program- ming signal. Some people didn’t want that, so they made the microcontroller check if a pin is tied to ground instead, and if it’s not tied to ground, then it boots right into the user code, so already that’s evolving. So that ended up being a bump  in the road that turned into an even better thing, and a com- pletely new project launched out of it too.

Osborn: That really is a nice result, saved you some time and really got the community involvement going. Building  a community  behind these projects is a great outcome.

Kettenburg: Yeah, definitely.  And I’ve spent a lot of time on the community end of things like, “This library could use improvements,” or “We could use another release of the software that fixes the known bugs so people don’t have to download this file or that file depending on which version of Linux they’re using.” All those things are on my list, but an emphasis has been on the community  and it’s paying off. We have a fairly active set of forums, fairly active in posts, and extremely  active in views. People are helping each other on them  a lot already.I would look at new topics on the forums and anything that hadn’t been solved, I would try and help out with. That went from taking me hours a day to now probably  fifteen  minutes a day because we have some real dedicated community members helping out, and then a lot who just help out here and there when they see something. That’s been great to see. I think one of the challenges for Digistump   as a company, with the Digispark and with other products I have in the pipeline now, is I’d like to see the Digispark commu- nity and the Digistump community tie into the broader Arduino community more. You know, you have people running official Arduino hardware on their Arduino forums. You get people running the Teensy5 hardware by Paul, who is in—do you know Paul? I can’t ever pronounce his last name.

Osborn: Stoffregen, yeah. I’ve met Paul a couple  of times. Seems like a nice guy and his product  is super useful.

Kettenburg: He’s right outside Portland there, and he’s got a very active community. He’s great with his community. He offers  a lot of really technical help. He’s pretty undisputed in his technical expertise on all things microcon- troller. And we have all kinds of distinct communities that grew out of the original Arduino community, and they don’t tie together very well. Adafruit is going to have their ATtiny-based  device and Todd Kurt—the maker of the blink(1), BlinkM series of devices, down in LA—has  a community,  and the Digispark  has a community,  and we’re all running the same hardware.  So I think that’s maybe a challenge of the maker community at this point, or I see it as one, that we need to join together  a little more and tie that information together a little better. And the same for Arduino libraries. The other day, I was looking at the universal TFT library for driving color LCD displays, and it’s like there’s this really nice universal library, and then Adafruit has this really nice library too. I can’t imagine how much time was spent on both of those libraries, and then in the end, they do the exact same thing. They both do it almost the exact same way. They both have the same issues remaining that no one seems to have time to get to.

Osborn: One thing that I’ve seen that kind of bugs me is not only that there’s duplication, but finding the right library for what you’re doing is somewhat difficult. And then for a lot of people, just figuring out where to put those files in the right place in the file system  is a challenge. If you’re new to it and you find this library, what do you do with it? So I’ve always thought  it would be a great project to see somebody  build a package manager.6

Kettenburg: I was just about to say that, yeah! With the Digispark, we have to modify the Arduino distribution slightly, and it’s such a pain because it’s not built for that. The Arduino guys, all the thanks to them, created this whole Arduino  ecosystem. They started it all. But they’re relatively resistant to com- patible hardware  being made truly compatible. And I think that’s seen most in that there’s no plug-in system for the IDE to support other programmers. There’s some there. There are board files and you can define other devices, but it still assumes that they’re exactly like the Arduino. So you got Paul, who had to make a special version  for his Teensy, and we had to make  a special version for the Digispark, and it seems like a package manager could solve all that too. I’ve put a lot of thought into how to make a good package manager for it, but it’s kind of one of those jobs that take a ton of work and very little payoff. If I had, if the Digispark hadn’t happened, that’s the kind of thing I would pursue but don’t have the time now. But it’s certainly something that the community needs. I’ve even thought  about making a Kickstarter  project for sponsoring a package  manager, and then hiring someone to do it, or something like that, because Digispark/Digistump would benefit from it greatly.

Osborn: This is something the community needs.

Kettenburg: The next project I have in the pipeline is probably going to need modifications to the Arduino IDE too.

Osborn: Yeah, I definitely think that’s something the community  needs. I’ve looked at the internals too. Even in places where they had made some effort to make things more generic, for instance, the Avrdude uploader.  There’s an uploader  base class and then there’s the Avrdude subclass, but the base class has all this very specific code that makes it not generic at all. Even the places where there was some effort or forethought to make it generic, it has been bastardized to the point where it really no longer functions generically. 6A package manager is tool that manages project code requirements by automating the downloading, discovery, and updating of libraries the project is dependent on.It’s certainly not insurmountable  by any means to accomplish this. It’s going to take some work cleaning it up, I think, before you could start really building on top of it.

Kettenburg: Yeah, definitely.  The biggest incompatibility  we had integrating the Digispark into the ID was that you have to use Avrdude,  and Avrdude didn’t work with our bootloader. We needed  a specific  specialized  upload tool, and we had that in a command-line form, but I ended up having to replace Avrdude with a dummy  executable  that’s  called Avrdude,  and then rename the real Avrdude, and then pass the flags over to that unless the flags say it’s Digispark, and then we pass it to our command-line program instead.

Osborn: Wow.

Kettenburg: It’s one of those I could have gotten as an Avrdude source and added support for the Digispark, but you know, then it’s like we’re getting into branching yet another project, and in the end, it seemed cleaner just to put a  proxy in between. And, the—oh, I can’t remember  the project—one of the robot projects off of Kickstarter, they were taking the same approach, and we exchanged notes to make sure that our proxies wouldn’t conflict with each other.