“The chip on this SDR is something special”

The Maverick-603 FT8 receiver was developed by RadioStack and is the first RF receiver to contain an open source chip. This receiver is an FT8 focused device with a frequency range from 7-70 MHz and a small (1.75in x 2in) form factor. But it’s not just the capabilities of the Maverick that make it stand out, it's the chip. As said best by Gareth Halfacree “the chip on this SDR is something special”. This chip on the Maverick-603 is indeed special, as it is the only open source RF chip commercially available. 

A Brief Lesson in FT8 - via RadioStack

“FT8 is a digital mode (this basically means that it requires the use of a computer) in Amateur Radio that can be sent and received at weaker signal strengths than almost every other form of amateur radio. Meaning you can receive signals with much less hardware and software than would be needed for other modes. A good analogy for FT8 is texting on your phone, although if you dig into FT8 it becomes a bit more complicated.”

Setting an Example

This accomplishment paves the way for open source technology in an industry that has seemed immune to it. The resources required to be successful in the semiconductor industry usually act as financial and technical barriers for young companies and developers. However, with the use of open source technologies, RadioStack has overcome these roadblocks, and with the launch of the Maverick-603, they have proven their abilities.

From Start to Finish

In addition to RadioStack’s chip, they also designed the PCB with components that make the design into a fully functional FT8 receiver. It is rare to see a company develop a product from a chip all the way to a final product, but RadioStack has done this with the Maverick-603.

The Maverick-603 is currently available on Crowd Supply: The Maverick-603

Subscriber Appreciation

We want to thank you for being part of the Opened Hardware community and helping us grow it. Click this link (Opened Hardware Giveaway) and follow the instructions to get free Opened Hardware gear!

“I saw all the flaws and I designed a board that would cover those flaws, and it helped to alleviate them.” 

“I like to think of boards as art. A good board, when you look at it, looks good. That’s a good board. There's a certain amount of pride that goes into making everything look just right.”

“But we made the thing and it actually worked. And that was really hard. I had never worked so hard in my life. I worked 20 hour days, slept on the floor, and did that for months and months.” 

Building a Business

“When you're an entrepreneur, especially if you're just a bootstrapper you have to learn all that stuff on your own.”

“If you get somebody who's run a hundred startups and made money on every one, then you're gonna get money.” 

“And you can't convey that kind of urgency and stuff to somebody and say, imagine you're on fire, you have that long to make this thing work.”

“That was one of my goals, as the CTO there, was to show that we could do something better than anybody else in the world. Something, just something.”

Open Source

“The world could use hardware object technology being open source.” 

“I just think that we've gone a little too fast down the path of HLD to hardware.”

“And that's, like I said, the key problem now is changing the behavior of the FPGA. You have to change the behavior of what it does in an extremely short amount of time, to keep up with the GPUs and the CPUs, if you really wanna do it right.”

“There hasn't really been a breakthrough in low level state machine work since 1970, basically.”

Charles: We learn in school how to do digital design. Maybe we use logic gates and we draw them, that's the first basic approach. You need to abstract things out. So you could regroup some of those individual gates into components, but still, you end up doing a lot of wiring by hand, and it's really messy if you want to modify a design, because it's graphical. You need to shift around all the wires and rearrange things. It's like when you write a word document, you end up spending more time on the layout than on the content. 

And for instance, we learned to use VHDL or verilog as a way to describe digital hardware. And it's great, but when you think about it, those languages are not designed for digital hardware. It's like a paradigm that you can interpret as digital hardware. If you want to use them to describe hardware, we don't really want to use an event driven paradigm, but we have to because they're made like this.

So what I've seen and heard in industries is that, to overcome the shortcomings of verilog, especially in term of elaboration. In VHDL and Verilog for instance, you have for loops, modules, parameters.

Things are a bit better since system verilog, but still, there are quite a few limitations. And in VHDL there is the 2008 and some other versions of VHDL, but the foundation is kind of broken.

So what I've seen in industry is, people for instance, will write some script to generate VHDL or Verilog files to overcome those limitations, they are using a programming language which can model things to generate what they really want as hardware. And we could say it at the first evolutionary step. 

And SpinalHDL is a step further where we still use general purpose programming language to do the elaboration of what we want. At least instead of ourselves managing a weak string of Verilog or VHDL code, you want to add into our file, instead of really having to put together the strength to compose our Verilog files in Python or whatever you want to use. Instead of this, we have a software library, which provides an API which allows you to capture the design that you want, like say I want a register of this type and it'll create it for you. SpinalHDL is really about capturing the full graph of the hardware you want, having some automatic checking done on it, like checking if there are some unconventional loops, if there are some latches, some unwanted cross clock domain, checking a lot of things. And at the very end, generating the verilog as a net list. So that's the concept.

Colby: Who are the main users of SpinalHDL, because I see it in a lot of different places, but who are the main users you see? Because I see it being really helpful in schools and everything, when you're doing complex projects, especially when they're teaching verilog, to have something that can streamline the whole process.

Charles: There are two ways to answer that question. One way is, it's really hard to know who is really the main users of SpinalHDL, because it's an open source project, and because it's open source it's hard to keep track of it. You don't have customers.

So I don't have a real main user. I would say, instead, there are some main projects which use Spinal, which is Vex RISC V. And that's the thing which really bootstrapped Spinal. Without RISC V, SpinalHDL would have been much less successful. Many people are using it in FPGAs as well. 

Colby: How did SpinalHDL start in the beginning and develop, was it just you in the beginning or did you have a small team of people. 

Charles: It was just me for a very long time. I was in university, and I had a project where I had to present Chizel. So I tried a Chizel, it was great because the paradigm was great. At that time, the Chizel implementation was not good. It was Chizel two or something, I don't exactly remember, but at that time, it was really lacking in many places.

Because of this, after a few times I tried to implement my own implementation of the paradigm to understand how it could work how Chizel could be implemented. And because it was working well, I continued my way. And little by little, for at least three years, I was mostly alone.

It was mostly a hobby, pretty much part time. And then for three years I was in a university to get a bit of money on my side. And 60% of my time I was working on SpinalHDL, and in my free time, doing different projects and stuff like that. And for two and a half years now, I've been full time on SpinalHDL and related projects like Vex RISC V.

Colby: That's awesome. And that's something that, for open source tools, especially in this area, like Xschem and Klayout and everything, a lot of the creators aren't doing it full time. It's still a hobby project for them. What made it take off so that you were able to switch completely to full time? Was it mostly the RISC V that made everything explode and get popular? 

Charles: There are two ways to see the question, like there is a financial side and the motivational side. So it first started with motivation. I worked for one year in a company where we had to do really big designs in VHDL and it was really tedious. And the thing is, once there are ways to do things better, it really feels painful. So I worked there for one year there and then when I came back it became my full-time occupation.

To make these kinds of things possible, there should be a lot of different things going well in parallel. You have to be motivated, but also, you really need to have quite a bit of financial security. You need freedom, and to have that freedom, you really need to have some money on the side.

I was in that situation, so I was able to do it. And then on the financial side, it came much later mostly because of Vex RISC V. And that opened some funding, some open source foundations provided me a bit of funding to add some features. Some companies gave me some funding to add, for instance, multi cloud support and these kinds of things.

Colby: And speaking on that, you mentioned it with the commercial and support and everything. As an individual developer of this program, was it difficult to wear every hat, and be responsible for support and development and kind of all these different things? And GitHub helps a lot with the pulls and everything and the forums, but was it hard to do everything at once?

Charles: So in some ways I didn't really have to do a lot of commercial support. It really depends on the time of the year for the workload for support. It comes in waves. I don’t why it's always in waves, really heavy waves. And then for a few months, nothing.

The thing is, really often it's little questions, simple things asked by many people. So you can't really charge people for that. And very often people who work in companies don't want to mess up with the bureaucracy above them. If they twist the portfolio maybe one or two hours, but it's so much bureaucracy to get that funding through the management of the company, and they haven't tried because, I know, it's really a pain. So that's the thing, for commercial support, I don't have much, I'm trying to get some funding for projects I wanted to work on, so I didn't have to do a lot of commercial support.

There is a lot of answering question, managing Github issues at the same time. This is a bit depressing because it's not something which pays you a meal. But sometimes there is a wave of students asking questions that the teacher will handle because it's his job to handle his students. And that, sometimes, is a lot of emails to handle. And that's a bit depressing sometimes.

Colby: It's a lot of work to have to manage all of that. 

Charles: And that's work, you can do out of the goodness of your heart. But the thing is, to keep the motivation to go forward with the rest of the project, you have to limit that part. Cause it's sucking the energy out of you really fast compared to doing things you want to really want to do. It's a lot of managing your willingness to do things for free, contributing in open source.

You have to protect yourself from doing too much support or else nothing will move forward. It's really a hard situation. I'm really trying to find contributors to handle Github issues and all these kinds of things. And it's starting to come. People are starting to be ready to be helpful, and not only relying on me to map things and it's really coming along. 

Colby: It's really cool to see your tool get popular enough to the point where people can help each other. And something I also wanted to ask that I jumped over before SpinalHDL, because it's difficult to learn HDL, all the languages, and verilog and design and everything like that. And usually it's restricted to specialized programs and everything. And on top of that, you also obviously had to do some work with software development and everything like that. What was your background in education and everything throughout school?

Charles: So my background is from the Switzerland system. It's driven by, there's many ways, many different ways, but the way I talk about it is, I was 14 years old, I started an apprenticeship. It's a little bit like the German system where there is really the industry way, where you go into industry at 14 or 15 years old.

You go in apprenticeship for three or four years where it's maybe one and a half days of school per week or something like this and the rest at the company. 

Colby: What  was the apprenticeship for?

Charles: Electronics, I was soldering, PCB design, these sort of things.

Colby: That's really cool to be able to do something that technical at such a young age. 

Charles: Yeah that's that's the thing, there is the more generalist way where you go in a general public school until you are 18, and then you go in your university and this kind of thing. But I really didn't want that to go that way because I wanted to learn a bit more technical, more math things. So I was lucky I had this possibility. 

Colby: And then in college, I'm assuming, you started to focus more on the digital design side. 

Charles: The thing is I started doing FPGAs at the end of the apprenticeship on my own time for fun. Then I started doing FPGA at the end of the apprenticeship.

So in some sense, everything about digital design, I learned the basics in the apprenticeship and from there, everything else came a bit from my free time at home. And then at university, you call that the bachelor degree? And there, it was a mix of software and electronics, and we did a bit more too.

Colby: And with the education and everything, for SpinalHDL and for teaching people how to use it, one of the things that I really like about SpinalHDL is how good it's documentation is. Because for open source tools there are huge gaps in the documentation for some of the tools, especially the newer ones and less developed ones, and the documentation isn't really that well managed and maintained. Was that one of your main goals? To have a really good and thorough documentation for the tool?

Charles: I would say, the first three years or the first four years of SpinalHDL. My main focus was really the language. It was not as much of a focus, but also to have documentation which was okay, mostly filled with examples. Because I always learned by taking a piece of code and modifying it. I didn't learn things by reading books or reading scripts. I always learned by taking a thing and modifying it to see how it works, to see what happens. But there is also somebody else who helped me with documentation, which helped quite a bit.

Colby: That's a huge help, because for me, at least as an engineer, writing documentation is definitely not my favorite thing to do.

Charles: Yeah the thing is, often we're underwater with all the things, all the priorities. It's a question of having the freedom, having the time.

Colby: And now, for Spinal, how many people do you have working on the project with you or for you? 

Charles: There are two things. First, it's really a project that I already started a long time ago on. And then people joined with contributions. Currently, I would say there are maybe four or five really active people on it, which do requests, managing issues, math things, maybe four or five people.

Colby: And I kind of wanted to touch on that part because it's pretty rare to see an open source tool like this develop into something so big. Basically like a company. And for you, getting the funding in the beginning you mentioned, and the financial support. And for a lot of technical founders, dealing with the finance side of things is difficult because they're trained in engineering and science, was working through all the funding and financial parts of the project difficult for you? Or was that just something that you learned on the spot? 

Charles: So for the funding side of things I would say it really doesn't pay well at all. If I would go work in industry, I would at least double my pay. So I would say it's more because I'm relaxed, on my side, having a simple way of life without a lot of expenses that I can do it.

And for all the authors which are contributing to it, from my understanding, it's mostly people who work in a company, use SpinalHDL as a tool to do things, and contribute on the side. 

Yeah. Personally, over the last two years, I was quite lucky because there was a foundation made to help open source people to do projects by giving them money, like maybe 50K to do a project. And so one of those foundations contacted me and asked me if I had a project that I wanted to do and that they could give me funding. 

And the reason why they contacted me is, people that they were already funding were using my things and spoke to them about my things. So I was really lucky. That's the thing. It's a lot of luck, being somewhere at the right time.

Colby: And for open source, you mentioned the foundation and the funding and everything, because the field has grown so much, did you see how much it was growing? And what was your decision to make this an open source tool instead of something that you could go out and make completely closed source?

Charles: So for the last part of the question, I would say maybe it's a cultural thing. At the time when was a kid, I was just downloading music files on websites, those peer to peer things. Growing up in that environment where you can download things like a pirate, and basically where you really feel like you are just a kid, you have no income, you have no access to things where there are are infinite results, technically speaking.

It maybe changed the way of thinking a bit. So for me, there was really no way to develop some code and keep it closed source, locked somewhere. It's not really part of my philosophy. I'm more into sharing things. Like currently, I'm using Linux and I'm happy I can use it. And it's all open source. So it's a way of contributing to the cause. 

Colby: And you mentioned, learning a lot of the stuff by yourself, which is really cool, especially with all these open source tools, it gives people access to programs that are usually very expensive and only used by larger companies. When you were figuring everything out and learning everything, is that kind of how you look at SpinalHDL? Because there's a lot of SpinalHDL examples and tutorials and everything like that. Is that something that you continue to do? And I even see some classrooms and universities that have lessons and tutorials and everything. Is that something that’s a goal of yours, to be able to teach as many people as you can how to use it.

Charles: Yeah, my goal was that if somebody wanted to pick it up, they could pick it up with enough resources that if they tried it, he could look around code and modify things to see, at least, how it works. My goal was initially to provide a proper replacement to the VHDL and Verilog, that was really my goal.

I didn't want to have to deal with those languages anymore. It's really frustrating. Especially when you come from a software background, and I have more of a software background than a hardware background. 

Colby: Yeah. Because a hardware language is difficult for software engineers.

Charles: Yeah. Initially it really came just as a replacement for VHDL and Verilog. But with time, you could go so much further. And the thing is, the more I was using Spinal, the more I was discovering or realizing new ways to use it with more abstractions, smarter ways to do things over time. The project evolved from being a replacement for VHDL/Verilog, more into exploring even more new ways to define hardware. Because for instance, the thing with SpinalHDL is it’s great because it is a programming language. You can layer abstractions over abstractions. For instance, you can have a state API, or you could have a pipeline, API pipeline, all these kinds of things. And this is really the growing part. 

Colby: And also I wanted to touch on Scala, the language. Can you describe that a little bit? How you got into that?

Charles: So Scala, it was one of the first lessons I had to follow in my master degree, I had one semester where I had a lesson of Scala, and it started from there. 

Scala is far from being perfect. I would say it's getting older now. The thing is with scala, you can do functional programming and VHDL programming. And the one issue is that, really often, when you look for resources about Scala, you find resources which go into the really functional way of describing Scala instead of the easy to approach way. So it's a bit of an issue. Scala is very scary if you look online but can be used quite easily, if you don't go into too many crazy concepts. 

Colby: Yeah because it seems like a really cool language. I also wanted to touch on the development of the open source community and, especially because you have success stories, like SpinalHDL is so popular now and there's so many different tools. Have you seen it, especially in recent years, start to grow very rapidly? 

Charles: So yeah, I don’t know how popular SpinalHDL is, but the last growth I have seen was a lot in China. I'm not sure exactly why, but in the software world, for instance, things evolved a lot. In part, because the software engineering field and the number of people working in that field grew a lot really fast.

So there were constantly new people coming in with new ideas and trying new things. And maybe in China, it's the same. Because maybe it's really growing there, the users of VHDL and stuff like this. So new people are getting trained,  new people are being open to new things, like SpinalHDL, maybe that's one reason why. It's the right timing. 

Colby: You mentioned SpinalHDLs has more of a digital focus. Do you think that you'll ever let analog or make it compatible and be able to do analog designs, because those are two very different areas?

Charles: Yeah. I would say it's out of scope.

Colby: That would take like a whole team of engineers to make a tool like that or make it compatible. 

Charles: It's really not my background. So the thing is I will try to avoid going into things that I don't have mastery of. Because it'll not end up good and I will not really use it. So because I'm not using it, it'll not be published enough. Often I'm trying to avoid going into features that I would not really use, because if it's not in use, it's not tested, it's not stable. 

Colby: What do you see as the future for SpinalHDL and do you see this as continuing to be your full-time project and job and your main focus?

Charles: SpinalHDL itself, I think now, is mostly stable there. Most additions done are libraries of components, like for instance, CPU and this kind of thing. So currently I would say it is on bug fix mode if there is bugs or little additions. But most of the effort is really done on libraries. And personally the last part was to add, for instance, it was a pipeline in API.

Where you can define a state, how is that connected? And you can define a signal. I want part of the pipeline and then retrieve that pipeline value somewhere else, automatically, these kinds of things. This came, because I was using that in Vex RISC V. It was a lot of fun. Its goal is to get Debian working on it. 

And then I don't really have any plans. So we'll see, I'm trying to not have too much, a long term vision to not have a stack overflow.

Colby: And for the RISC V, that seems like enough work as it is to do that. Are you involved with the RISC foundation and directly with them? 

Charles: Not really. So RISC V, to be honest, it's probably nice people in it, but the foundation, for me it's really, maybe a bit too corporate. Especially the RISC V summit and these kinds of things where, it's not always true, sometimes it's good, but really often it's too much business, too much corporate, too much RISC giving you the slides. Nothing really technical.

I would say it depends on the people who organize RISC V’s, sometimes it's hosted in a given university and they have a word to say. So yeah, it's a bit sad, it's not enough academics right now, I would say. 

Colby: I also wanted to touch on events like those, especially now that everything's in person. Have you, do you try to participate in a lot of the different types of events? Like the Paris conference coming up and the RISC foundation conferences and everything like that.

Charles: I was in the Paris one, which was one month ago, a RISC V spring summit. So yeah, I’ll be in the one in two weeks. After that I have no plan at all, to be honest. If there is something, I may go, but the thing is, mostly, normally all the fees are out of my own pocket. So I'm doing that if I really have something new to talk about, but otherwise it's a bit expensive.

Colby: What are you speaking on at this coming conference? 

Charles: So the Vex RISC V, I have been designing since October, so I will try to focus on the SpinalHDL side of the project. For instance, there is a pipeline API, there is a plugin system to compose the CPU with plugins. Often if you have a big design, like a CPU and you do this in Verilog or VHDL, you would have a really big top level, which connects everybody with everybody. Which is really fast, really messy. And if you want to change something in there. 

And so for instance, in the next RISC V  has a system of plugins, where for instance, each plugin can ask the pool of plugin services, if they have a given service, for instance, one service could provide a jump interface from the program content plugin, this kind of, it's really a modular approach. And the CPU is defined with plugins. So there is no top level. The top level itself is maybe five lines of code used to put in place the framework and everything else is modular. So you can come and for instance, define a new execution unit. So you instantiate a plugin to do that. And you can add your custom solution into the execution unit by adding plugins. It's quite modular. So yeah, we'll talk about this mostly. 

Colby: That's pretty much all I had for today, but I really appreciate you meeting again.

“Once there are ways to do things better, it really feels painful to keep using the old tools.” 

“My goal was initially to provide a proper replacement to VHDL and Verilog.”

“So for me, there was really no way to develop some code and keep it closed source, locked somewhere. It's not really part of my philosophy.”

The Prerequisites

“You have to be motivated, but also, you really need to have quite a bit of financial security.” 

“You need freedom, and to have that freedom, you need to have some money on the side.”

“That's the thing, it's a lot of luck. Being somewhere at the right time.”

Building and Developing an Open Source Tool

“SpinalHDL is really about capturing the full graph of the hardware you want, having some automatic checking done on it. And at the very end, generating the verilog as a net list.”

“I try to avoid developing features that I would not use, because if it's not in use, it's not tested, it's not stable.” 

“And the thing is, the more I was using Spinal, the more I was discovering and realizing new ways to use it, smarter ways to do things over time.” 

Supporting the Community Using your Tool

“You have to protect yourself from doing too much support, or else nothing will move forward.”

“Often we're underwater with all the priorities. It's a question of having the freedom, having the time.”

- Matthias Köfferlein, Creator of klayout

“A lot of people had a lot of different opinions on what to sell and how this all should work, and this was the reason why, at the end, it was not successful.”

 - Frank Karlitschek, Founder of Nextcloud

“That was one of my goals, to show that we could do something better than anybody else in the world.” 

- Steve Casselman, “The Father of Reconfigurable Computing”

“That's the thing, it's a lot of luck. Being somewhere at the right time.” 

- Charles Papon, Creator of SpinalHDL

“Making money means that you're selling something”

 - Frank Karlitschek, Founder of Nextcloud

“One of my goals in life is to have a positive influence on the world. I want to do something good.”

  - Frank Karlitschek, Founder of Nextcloud

“I worked 20 hour days, slept on the floor, and did that for months and months.” 

- Steve Casselman, “The Father of Reconfigurable Computing”

“I've only been successful when I've hired people who have been really fantastic and very self-motivated and self-driven.” 

- Rob Lauer, Director of Developer Relations at Blues Wireless

“I just want xschem to be usable, get the work done, have a low footprint and be as useful as possible.” 

- Stefan Schippers, Creator of xschem

Steve: Yeah. That was another portion of everything. I started DRC with a guy named Larry Laurich who had been, well let me backup a little bit.

So I'm in this book written by Dr. Fred Haney, because he was on my board at VCC and his thesis basically is you gotta get somebody who's really fungible, to get money. If you get somebody who's run a hundred startups and made money on every one, then you're gonna get money. 

So he went out and got this guy for me Larry Laurich, who had been the general manager at tandem computer. And he had 1500 people working for him. So together, he and I started up DRC computer. That was an interesting thing because I had these patents about putting FPGAs together with CPUs.

 And then the Opteron came out and Opteron was the first processor that really had a multiprocessor mentality. So every workstation really was set with two opterons right. And they talked over this open source bus. 

So when that came out, I immediately knew that this was the perfect thing for me because I could take the processor out and put in a FPGA and then I would have a tightly coupled system where the CPU is a world class CPU and the FPGA is right there next to it, over a high speed interconnect.

So that was very important. So the minute I saw that, I was like, oh my God, this is gonna happen. We could do this. And I got hooked up with Larry and he helped raise our first money. And it was very interesting because I was in Reseda, which is in the San Fernando valley and then I had to move up to Silicon valley. 

So we were up there, and when I came up with it down in Southern California, I was like, I went to the AMD and said check this out, I could go right into your socket. We could do this. This would be great. And they were like are you okay?

So then I went up to Silicon valley and we actually made one, so we made this one fit in the socket. We called in AMD. This guy comes in and he goes, oh you're not the only smart person. And then we started talking, then he said, you're not the only smart guy. There's other people that have been thinking about this. I go, did they live in Reseda and he goes, what? And he gets out his PC and he goes, oh, that was you . Yeah, I was the really smart guy in Reseda. 

But, we made the thing and it actually worked and I got it to boot myself. I did all the work to get it to. And that was really hard. I had never worked so hard in my life. I worked 20 hour days, slept on the floor, did that for months and months. 

Colby: And that's crazy, because I was looking and you were CTO there and usually the CTO kind of gets to take a break from some of the technical stuff, but you just kept working on the technology. 

Steve: Yeah, we had several PhDs working for us, but there would come a point when they couldn't do it, they couldn't figure it out. And so then it was my job to do it. And I did, and there were other things just like having to reboot in the Opteron socket, and these guys said, oh, it can't be done.

But I figured it out, I got a patent on it. Everybody's going, oh, we can't reboot in the socket, I go, it's a reconfigurable computer, you have to. You don't understand, there's no options here, right? And you can't convey that kind of urgency and stuff to somebody and say, imagine you're on fire, you have that long to make this thing work.

So I got it to work and that was really great. And then the CEO went to Cray and said, check this. And they came down and it was a big hit with them because basically you could, you didn't have to change your design to put it in an FPGA thing.

You just put this thing in the processor socket, right? Yeah. So we sold some stuff with them, still, all the stuff is still so hard. It's getting easier because of some of this open source stuff and a lot of stuff going on, but I really think there's a way to kick FPGAs up to the processor style, ease of use.

And that's all doable. And some of it's been done before, so eventually whatever I'm doing, I'm going to head toward that point. It's gotta be so that the guy, whoever's programming, just programs. They don't care. There's only one thing, you have to think about pipelining stuff and whether your code would be pipeline-able.

And it turns out that's actually good for regular computers. So somebody gave a paper at a supercomputer conference where they go, oh, we decided we would pipeline these algorithms and do them in little batches, and we got a 40% increase. 

So that has always been like my 20-20 vision, if you could get some language where somebody could, on a regular computer, get 20% more. Then, if you went to the FPGA, you would get 20 times more then nobody would argue with that ever, right?

Colby: Obviously right now, you're doing an awesome job explaining this technology that most people don't understand. Was that a difficult part, try to actually sell it because you know it works and you know how it works, but to get those ideas out. 

Steve: Yeah I'm not the best sales guy because I look at something, I have a vision of how it works, I understand how it works, and it's at a gut level. I could tell you how it works, but it might take a couple years to get you there. And that means I'm not all that good at this, so that's one of the things that I'm trying to get better at, to be able to explain what my vision is and how it comes across.

But the problem now is it's still many years ahead, and venture capital guys don't understand this. I'm not all that fungible because I was never in a big company and led a whole team and did all that kind of stuff.

Colby: How did DRC come to a close cause I saw a couple articles and everything. And you mentioned the algorithm and everything like that? 

Steve: That was one of my goals, as the CTO there, was to show that we could do something better than anybody else in the world. Something, just something. So that ended up being the Smith Waterman algorithm, which is used to find an alignment in the DNA sequences.

So that project started with, I had a really smart guy working for me and he, who eventually got his PhD at Stanford, but he would get done with something he'd be playing around and I go hey, whenever you're in that position, just look at this stuff and do this stuff. And he goes, okay.

So eventually we got all that to work and it was pretty awesome. And it was just one of those things that I had to do behind the scenes. There, there was also stuff that I pushed people to do, when you're not doing something, look at this. You'd like it, it's interesting. And that got a lot of things going 

Colby: I like to ask ASIC designers and FPGA, how it was learning everything. Because when you used to have to draw the circuits, I can't even imagine doing that or teaching it. How were curriculums, did you learn most of your stuff at college as opposed to at work?

Steve: I got a degree in math. So I went to UCLA and I was gonna be a EE, I was gonna be a computer science and math double major. So I went to the computer science stuff and they had this weird language that's dead now. And they wanted you to do that and I'm going, I'm not doing that.

And I figured, what I will do is I'll get my degree in math. And then when I get a job, that'll come in handy. And if I sit in front of a computer all day, I'll just learn about the computer, whatever it is, I'll learn that system and it'll be something I can do. And, and so I sat down and the first system was really the Daisy systems.

So I learned all about CAE, how to, actually they had a Pascal behavioral language I learned and I learned spice and I learned to do all sorts of stuff on my own, in the meantime, while I was putting in other people's schematics. So for me, that's how I got into computer science was through mathematics, which has helped a lot because in reconfigurable computing, what happens is that people have very hard problems to solve.

And usually these problems involve math. And so if you can understand the math, you can pretty much understand the problem, and if you're good, you can understand how that maps into hardware, right? So that turned out good. And I didn't regret that.

Getting a computer degree back when I was, in the early eighties, there just weren't that many computers and they weren't that much fun. So I was in the CAE lab and the mandelbrot came out in the Scientific American. And we had just gotten one PC that had a color monitor and it was a really slow IBM. And so I would write programs to do the mandelbrot and then I would leave, and I was working the swing shift so I had a lot of time. I put the mandelbrot on there and I leave and then come back and everybody would go, oh, that was really cool. But we had to reboot it to work, so I never got to see the many ones I generated. That was fun because I would do every 10th dot or every hundredth dot.

And if I had a lot of colors, then I'd shoot it off and it would take all night. I wouldn't get to see it, but it was fun. So that's why I did the mandelbrot on the FPGA. So I'm the first guy to do that. So the picture that you see in the background over there, that's all done on an FPGA.

 It was so funny because at a demo night, what they call demo night. I was showing off the mandelbrot and some guy, who was like six six or something, comes up and he's looking down at me and goes what do you got? And I go, I got 24 bit multipliers.

And, they were very small multipliers because I used Booth's algorithm, but that was really, it was running faster than the sun workstation. So he goes, okay. And he comes back and he comes back with his friend who was like five six, and there's those two weird guys, and they're just going, and the big guy's hitting the little guy saying, see, I told you they could do it. See, I told you! And I got some email from a Bob Smith. And I replied once I tried to reply again and it was gone. They turned out to be NSA guys. Very interesting. 

So in the very early times, I was trying to get things going, so I called up the founder of Xilinx, Ross Freeman. And I said, here's what I'm doing, and I wanna work for you. And he didn't think I had a position there, but he said to me, you have to talk to these guys in the government, and tell them what you're doing. And I go, okay. 

So it was The Institute for Defense Analysis. I called them up, talked to a guy and he goes, can I see your proposal? I go, can I get an NDA? He goes, no, whatever comes in here, doesn't leave. And I go, okay. So I sent it in. And then of course later on that same group came out with one of the first reconfigurable computers.

So they went from their splash one, which was loaded serially and they were trying to make an ASIC that they could search everything on the internet. But then I gave them my paper and the next thing, they came out with the slash two, which was a real reconfigurable computer.

And their demonstration was actually Smith Waterman. Because in a Smith Waterman, you're looking for a string in DNA, but if you make it a little bit bigger, you can look for words in streaming paragraphs and it could stream as fast as the internet could go at that time. 

Colby: And the last thing I wanted to touch on was your current project that we first connected on. Is that the smart nic one? 

Steve: What I'm working on right now, my business plan is a smart nic, plus computational storage . So my thesis is basically that computers have evolved silos of optimization. So the CPU is optimized. The network card is optimized. And the storage, it's all optimized for their areas. And the only way now that you're gonna get more performance, is if you can bang two of those together and optimize over the boundaries, right? So these silos have clear boundaries, and if you can push them together, then you're gonna get something a lot faster. So if you take an FPGA and you put networking on it and you put storage on it, and then you put it into the storage card format, you can actually put 32 of these things in a two or Three-U cabinet.

Not only do you have a lot of storage, but you have a lot of networking into the storage. So it's directly networking into the storage. So you got a huge pipe into your storage. It's huge. It's way faster than anything that's out there. They can't do what this card can do, anywhere.

Although, what I hear rumors of, is they're trying to do that. They're trying to think how to do that. So one of the companies has their data engine or something, and now they're trying to do that NVMe over fabric. And then as soon as they start thinking about that, it's gonna get to the point where like, why don't we just put the fabric right next to it. 

But these data processors that are coming out, they suck too much heat. So that's why FPGAs are great for the job. I can fit it in a 75 Watt envelope and I can get a lot of work out of it and I can manage how much power I take and all that kind of stuff. And I think, those will only get bigger, more powerful, storage wise.

 If they get to 150 Watts, then it's gonna be obvious to everybody. But I've put in a patent and I'm trying to work to get that funded. It's a little more difficult because it's a board, but my bootstrap plan is to work on this algorithmic state machine. So it's really made to be the back end of a high level HDL, kind of a high level language compiler.

 The state machine is very small. It's very efficient. And you could have, instead of one RISC V, you could have 20 of these things, all running concurrently. And I just think that right now, we've gone a little too fast down the path of HLD to hardware, not hardware description, but HLD, high level language design. We've gone too far down that path too quickly, and there's a data plane and a control plane.

And right now, the control plane we're using is one hot state machine. They're not reloadable, they're not reusable. They're very hardwired and they're not really efficient and they're not, they're just a conglomeration of one hot state. There hasn't really been a breakthrough in low level state machine work since 1970, basically. Was the last time, right? 

So this is a whole new way to do state machines. And it's very fast and you program it in C, you can debug it in GCC. You can reload it at run time, so the idea is that you have one algorithm and you got all the hardware data path for that, and you put it down and then you hook it up to one or more of these state machines.

And then you take another algorithm and you try to overlay that on top of the first algorithm and you do resource sharing, and then you run those extra lines of control into one of these state machines. Then what happens is that, to go from one algorithm to the next, you just reload the state machine, which is extremely fast. We're talking less than a thousand bites of stuff can completely change the behavior of your algorithm.

And so nothing's for free so both of those algorithms will go a little bit slower. But if you look at Amdahl's law, that's nothing compared to the overall gain you'll get by putting more software into hardware. 

So that's the thing that you need to do, overlay these circuits. And then my general thesis on that is that in an area, you'll start doing that and then you'll get to the point where you don't have to add any more mux's or anything. And the next algorithm that comes in, you just have to generate microcode bits for it. And swap those in and you'll get like a kind of general purpose, ugly looking thing that could probably help with AI and all the stuff that's going on now for it to be efficient.

And that's, like I said, the key problem now is changing the behavior of the FPGA. You have to change the behavior of what it does in an extremely short amount of time, to keep up with the GPUs and the CPUs, if you really wanna do it right.

Steve: That's where I started, they were doing that. They were drawing stuff out by hand. And one of them, this guy, was telling me they had to print out the huge ASIC design that they were doing. It's a Gate Array. The gate array they were doing. And he had to crawl on the floor until he found the one via that was missing in the design. At that time there were very few automation tools to do any of this stuff. 

When I started in the CAE lab, entering schematics, and daisy was pretty good. I was good at all that stuff. So one day one of the top guys comes in and goes, looks in the lab and he goes, Casselman you like weird stuff, come out here and look at this thing with me, and I go, sure. And we went out and it was actually monolithic memories, which Xilinx was the second source to get a military contract. So it was a sales guy from monolithic memories. We went over that and I was looking at it and I go, this is awesome. If you hit a button for record or play, you could switch the whole FPGA out before anybody would know it. I go, yeah, that's probably right.

And then I was walking around, and that was in like 80 or 86 so I went back to work and thought about it. And basically the next day somebody came in and said, oh, they're gonna do a demo for a Silicon compiler. I go, wow, those guys already know how to compile down into these FPGA things, that's great. But I went in there and the Silicon compiler and I saw the demo. It was basically a form where you would enter your parameters for little components, and then it would build a schematic with this. And I go, that's not a Silicon compiler. I know what a Silicon compiler is. So that's when I started writing my SBIRs in 86. 

Colby: Were those for the FPGA stuff? 

Steve: Yeah, to take a FPGA, and make a computer out of them. And at that time there were like 64 lookup tables, right? So I was gonna have a big old board with lots of stuff, which I eventually did make. And interestingly, so that board there, and if you look at it, it's almost exactly what we have today in FPGAs. 

So there's an area where I was planning to put a processor in so that it can compile programs and it can make its own bit streams running on the device. And then there was a big array of FPGAs and interconnect chips, which I did a full custom interconnect chip, any pin to any pin that had two different configurations paths. So you could be using one and you load the next one, and then you could just flip between them. And that's important in things like butterflies and stuff like that and FFTs and all that kind of stuff. So just thinking ahead. \

And then on the board, I also had these really big Rams, right? SRams, they were the biggest things at the time. I think they were a megabyte per and there were like eight megabytes on there. And then there was the dual port Ram on the edges, and then it wrapped around. So it was to, so it's basically the SOC architecture that we have today in FPGAs.

Colby: And did you have a goal for it? Like a main focus, because now they have FPGAs for RF and pretty much anything you want to do? Or did you just wanna show that you could make one? 

Steve: I got a SBIR contract to make a hierarchical database search engine. It was hard to make this to begin with, and I was hoping that I would get some follow-on money to do the actual application, but that didn't happen.

So I had a little interface board that went from the sun workstation into this big monster in the background and it had a FPGA on it and I could configure that on demand because I had set it up to be able to configure on demand, and so I go, oh, maybe I'll just sell this thing. So I started, I'd had a bunch of pins to go to something else, so I swapped that out for a couple of the nice connectors. So you could put a daughter board on top of it, right? And then I just did this easy, what I thought was easy, interface. 

And it was pretty funny because 10 years, 15 years later, some guy comes up to me and says, I still have one of your boards on my desk and whenever I want to try something out, I pull it out and I use that, because it was so easy to set up and talk to. 

Colby: So you were actually able to sell it? Did you do it yourself?

Steve: Oh yeah, I sold it. I had a company, it was called virtual computer corporation. I won the SBIR under imagination works, which was the name of the first company, but then I wanted something a little more industrial. So I got virtual computer corporation as a name and VCC as a domain. And I should have kept that. 

But I had four or five people working for me. And I made all sorts of stuff . One of our biggest customers was the government, which I'm sure they were doing encryption, but they never told me but you could see it roll out. They bought one, then they bought four. Then they bought 30, then they bought a couple hundred. So that was good. 

Colby: And I also wanted to ask, because right now, especially with the supply chain, and all the getting parts and stuff, how was it to piece together? Because now, I can pretty much go on Mouser and type in micro controller and there's thousands to pick from. How did you select parts for the board? 

Steve: The board is basically, the big board, is Ram, FPGAs, and an interconnect chip. So for the first prototype, I did the full custom ship myself.

Colby: Oh, wow. 

Steve: Yeah. Especially since nobody asked me if I could do that. So they asked, as part of the proposal, can you do that? I go, I've never done that before.

Colby: PCB and ASIC design are very different. 

Steve: Yeah, doing the ASIC full custom, I dropped a boron layer the first time it was like, ouch. But that was with Moses, which was a great little thing that was one of the first multi-project things to happen and it was mostly for students, but anybody could get in on it. So that was very cool. And I finally got that thing to work, but in the meantime, somebody else came out with a chip that you could load and configure all the routing.

Because in the beginning, the FPGAs weren't so good at routing. They didn't have enough wires. So on my board, I had added a whole lot more wires. See, and that's why it's more like today's modern FPGAs. I saw all the flaws and I designed a board that would cover those flaws, and it helped alleviate them. 

So this was a big board and I turned the interface card into a product. And then I was walking around Xilinx and they go, oh, we got a PCI, not PCIE, but PCI interface macro and we're gonna build a board so that you can use it. And they showed me what it was and it looked like a terrible, horrible looking board.

I like to think of art, boards are art. A good board, when you look at it, and it looks good, that's a good board. You can have a good board that looks ugly, but there's a certain amount of pride that goes into making everything look just right.

And I looked at that. I go, no let me do the board. So I actually did the board that they shipped out with their PCI interface. Because I got that to reconfigure on the bus and do all this stuff. So that was a good product, because that's about the time I started working on the hardware object stuff because I was doing a lot of different designs and I was tired of trying to port or build up a new kind of interface to each board because each board was a little bit different.

So with the hardware object technology, what I did is I separated everything that had to do with the actual physical board from all the rest of the stuff that you'd need to do. So that made it very portable. So I could just port things in a day or, my guys could. So you know, the hardware object technology, as you take the bit stream and you turn it into a static array so you can compile it right into a program.

And then the hardware object part is, you add this bit stream. So you make a class called hot and then the bit stream is a field, but then there's a whole bunch of other stuff where you write your code to use that bit stream. So you got the bit stream as part of the object and the code to use the bit stream as part of that. 

So that's hardware object technology in a nutshell. Is that you're able to make these C plus objects that are bulletproof, where they could be Python now or whatever the favorite language of the day. But it's really convenient because it's very fast, as far as loading and unloading and doing things like.

And I developed a whole client server thing where I could throw a hardware object over to another workstation somewhere and it would load and run and then return the results. There's all that stuff. It was a plugin technology. 

You know, I'd really like to get that to be open source. That's one of the things where I keep looking around and I go, oh, this guy's got this stuff. What does it do? I go, oh, that's almost nothing. And everybody's all happy with it. And the hardware object technology is well thought out, documented, and has all sorts of features. 

You basically treat anything inside the FPGA as a memory location, and you have a memory map, and then you know where those are and then you just use regular C read and write commands. You get a handle and the driver knows what's going on and it's very simple to do. But nobody's done it yet because there were no customers for it for 30 years. Now there's all these people doing all sorts of stuff as a hobby and open source. The world could use hardware object technology to be open source. 

Colby: I'm glad you brought up open source. Because I was wondering, was it a thing people were focused on or knew about when you were first working on these things? 

Steve: When I first started working, there were some things that were open source, for example, Linux. And there were some other little tools and things like that, but for any kind of really big job, you paid money for it. Look at what cadence and synopsis just got a hundred thousand dollars a seat, 30 years ago. And so, are you gonna open source that? I don't think so. 

This thing I'm working on now, which is the state machine is totally awesome in my opinion, it's unlike any other state machine because it has way more states at runtime. But it takes more memory, so there's no magic in it.

When I read the C and I have these two bits and one bit is for the actual state bit, and the other bit is the clock enable bit that’s actually a latch. It's a latch enabled bit to actually latch that in. So once you do that, it's like a don't care. You can make it into a don't care kind of situation. 

So on that, in all state machines that I know of, you go to an address and you get a state vector out, you go to that address again, you get the same state vector out. But in mine, if you go to the address, you get a state vector, and you can go to other places that set the other don't care bits before you get back, you go to that address and it's a different state vector. So no, no other state machine does that. So this is like a quantum state machine in some ways, because the number of states is exponential, right?

If I have five states, in a line, in an output and I'm only setting one, the other four could be anything. So that's two to the four, right? So basically, you can have 32 different states at one address. That's the thing, at the same address. So it's extremely versatile, extremely powerful.

I'm just about to release it. I've been working on a website for what seems like a long time. It's about a month, but I had to learn how to do modern website tools and all this kind of stuff. When you're an entrepreneur, especially if you're just a bootstrapper you gotta learn all that stuff.

And I'm very close to being done with that. And then I'll release a paper that I've written, maybe 10 years ago, but I've updated it. And it's basically why use FPGAs for computing in the first place? Why are FPGAs more special in some ways than GPUs and CPUs? And there are a lot of different reasons for that.

And I outlined some of the things that are physical. And so you've heard it from Xilinx lately, right? Where they say no dark Silicon. I was surprised to hear that because that's the first thing I go into is the dark Silicon. And why FPGAs don't suffer from that. 

And basically, you can think of a CPU as a tight, little mound of silicon working really hard and it gets really hot and it just sucks the electrons from the substrate faster than the substrate can get the electrons to it. But in FPGAs, those are all pulled apart. So they're all pulled apart and there's little islands of lookup tables. And so they don't get nearly as hot because they're separated. They're not concentrated.

And then there's other things in the paper you read about Rents rule, for example, that not many people understand. If you look at a processor, there's data coming into it. It's maybe a hundred wires or 200 wires or something. You take that same area in an FPGA and you have thousands of wires going into that area. So they're way better at delivering the data to where the computation has to happen than CPUs.

Colby: Can you touch more on the dark Silicon, because that's a phrase that I haven't really heard.

Steve: Oh yeah. That's been around for a little while. But there's a Scaling factor that happens. So when you go down in power or in size, those transistors are still going pretty fast. And so they're taking more power per area. So now you've got 20 gates in some area, nowadays you have 10,000 or a million gates in one area; they're just so small.

And so what happens is that everything's working and you can't deliver electricity fast enough to the inside of the ASIC to keep up with the power draw in there. And so what actually happens is the voltage rails drop, and then it just blows up, you lose your program or whatever you're doing there, because it just can't do it. 

So even now in the processors that have 24 cores and stuff, they have little things that they turn off if they're not using them to make sure that they can go better, doing this. So that's how they're addressing it.

But in an FPGA, all the compute things are all spread out already, right? With the interconnect between. So you don't get this phenomenon where you're just sucking the electricity right out of the voltage rails and dropping the voltage locally. 

However, there is a problem with FPGA, if you have dark Silicon, but it's the configuration. So when you configure an FPGA, if you do it too fast, what'll happen is the voltage rails will drop and then you'll lose all your configuration bits. So you have to go a certain speed, and they're limited by how they set things up and how things are going. And right now it's just like a big frame buffer that goes in and they have to go really slow because the one thing that processors have over FPGAs is the ability to change the functionality in a heartbeat. 

So for a CPU, they just pull in some more instructions. They're doing something completely different than they were doing before. And that didn't take much time at all. So in the FPGAs, we gotta get to that point or at least half of that, maybe 10 times slower right now we're a thousand times slower.

Addressing small subroutines was very hard unless you could get them all in on the FPGA. It's hard to do partial reconfiguration because that takes a lot of time. And then you have to make up for that time by how much speed up you get. And sometimes that just doesn't work.

So then you're stuck having that function over on the CPU and Andels law that just starts to kill you, right? If that 10% can't possibly be put in hardware, then the best you could do is 10 X. And if it's more like 50%, then you're getting two X. Which could be a good thing.

“In my particular case no one was interested in such a tool inside the company, so they wouldn't put effort into developing such a tool when you can just buy it”

The Process

“You start with an experiment, then it grows, then you think it might be useful, then you develop it on your own”

“What I think is important is, you need to have a vision, the path you want to follow and the goal you want to achieve.”

A Fork in the Road: Business or Open Source

“During the financial crisis I considered making a business out of that, but I dropped this idea because of the level of entry. And as a single person, you cannot really make a business; it's too specialized as people can just buy mentor or cadence”

The Motivation

“I felt that there was a lot of positive feedback which gives you a good feeling about what you do, and for me, that's payment enough.”

“And, you go to India, one and a half billion people, and they know you. So that's actually pretty rewarding.”

“My experience is that people like to try things, and then once they are stuck, they approach me. And this is exactly what open source is about. There's no barrier, you can just install it and try it yourself.”

Maintaining and Growing and Open Source Tool

“Now it's actually growing and I feel that it could grow a lot more. And there's a point now where I'm happy that people jump in and take over these kind of let's say, add on activities. I feel that right now it's going to become a community project rather than a single person activity.”

“I still try to keep the documentation effort lower than the coding effort, so that it prioritizes code still.”

I think there are many ideas, and I still pursue some of them, but it's too much to do everything that people request. But it's not closed, it's not in maintenance mode only, it's not bug fixing only.”

It's hard to even pick where to start. I don't know how you find time for all this stuff, but to start just kind of your background and learning in school. And I always like to know what open source looked like when you first started 

Frank: Since I was really a kid, since I was seven years old. My uncle gave me a programmable pocket calculator, which really got me started with writing software. Writing software was a big thing because it had a one line display. So it's really hard to write complicated software if you can only see one line at a time. But that really got me started, and since then I really got into computers and really got into software and computers overall. Then after school I decided to study computer science, did this at a university.

And after that, I started in industry as an admin slash developer slash manager of development teams and all kinds of things. In parallel, I really got into open source in the middle of the nineties. This was really fascinating because until then, I only knew computers and software, where everything is done by companies. But then a friend of mine basically showed me the very first version of KDE of the KDE desktop. And I found it super fascinating from a software perspective, but also when I learned that this is actually not done by a company, but this is just done by hundreds or thousands of volunteers all over the internet.

Just volunteers who have never seen each other in person. Collaborating through the internet and building a software, which is super cool. And I just thought that this is the most amazing thing. Again, not only the technology, but also from a social aspect and society and how to work together.

Super fascinating, because it's just open, those communities. You don't even have the classic structures. You have a lot of companies, like with management and product management and sales and marketing and team leads and stuff, that don't really exist because everybody's a volunteer. So everybody does what they want to.

I thought it was really fascinating. And I got into the KDE community, was active for quite some time, and did all kinds of things there. Little bit of coding, little bit of artwork, little bit of event management. And I was a board member of the KDE foundation for a while, and was really deep into all kinds of open source topics. 

Colby: You did a ton of projects and you mentioned, even in the nineties, there were hundreds or thousands of developers involved in the project worldwide.

Frank: It's really fascinating because a lot of things changed over time. There was no Github.

Colby: I can't even imagine how you collaborated on projects. 

Frank: Yeah, exactly. The whole workflow was so different. There, there was a time where patches were sent around by email and everything in the organization happened by mailing lists. Mailing lists are not that big anymore nowadays. And there was nothing on the Github level, like a real collaboration platform didn't really exist.

It didn't have the sophisticated branching or reviewing. All this complicated or sophisticated collaboration, workflows and tools we have nowadays didn't really exist. It was mostly like one person or a few people had commit rights and they were just committing all the stuff. The reviews happened by mail or chat mostly. But it worked, it really worked. 

Colby: How many people were on like the actual KDE team to manage all of these, like thousands of people and requests and everything. 

Frank: I don't really remember. And, of course there were lots and lots of mailing lists. There were some core mailing lists which were super active and hard to follow. But yeah, there were hundreds of mailing lists, hundreds of ISC channels, quite complicated. 

Colby: And off of KDE, I saw that you had a few different projects that were spinoffs or directly related to KDE. Were those all like right under KDE, did you branch out and do those projects individually or with a team? Like the KDE open desktop.org, which is the one I was really interested in, those projects. 

Frank: Good question. For KDE and these open projects, I don't really have this hard boundary where something is in the project or out of the project. It was the ideology behind it. 

So the whole website thing I started was KDE look.org. This was the first one I thought of, because the development process that I described with sending patches by mail and ISC channels. This was really optimized for development of code. But if you really want to do something else say, create a cool wallpaper or cool sound theme or I don't know, something else more visual then I thought that there's a need for an easier way to collaborate and contribute something to a project or to the world. In the end I built it like in 2000 and I think it was launched in 2001. KDE look.org, which was I don't know, nowadays we call it a social network. It was just a platform where people can come together. You can upload something like a wallpaper or an icon or something, and then other people can comment on it, can read it, can like it, download it. Of course, groups and messaging and all kinds of things. It became a really big platform where people collaborated around the more visual side of open source. 

And then the GNOME project, which was always sort of the sister project, as KDE had similar goals, but existed in parallel. There was also a need for a platform like that so I launched GNOME-Look.org for them.

Colby: Now with GitHub and all the forks, it's hard to differentiate project from project really specifically. But for those projects, especially KDE look with the social networking aspect and everything, that's like a different animal. Were you developing these tools directly or were you more, at that point, in a managing role of those teams?

Frank: No. This is a once a one person operation. I did everything alone. I wrote the core software, hosting the server, which was not that easy because the traffic was huge, also paid for the server on my own, and had two banners on the website that paid for the server. This was a bit of my contribution to open source. And I was running that for a few years.

And then you mentioned open desktop, which was basically the umbrella. Because over the years, more and more projects came to me and said, Hey, I want to have a website like that. And I launched all these websites and it became a bit confusing and considered everything under the open desktop org umbrella, basically. 

Colby: This is a bit of a side question, but I like to ask how you learned all this, especially for you, because you had your hands in so many different fields, all these different languages and infrastructures. Now, open source tools, to learn them, there's YouTube videos and there's a lot of resources now, but I'm guessing when they first were made, the documentation was not as good as it is now. 

Frank: Oh, no, I feel really old, I have to say. It was possible to learn technology before YouTube. I mean I bought books. Books about how to write C, and how to write a sampler and how, I don't know, how TCPRK worked, and had all these books. That's how it worked. 

But of course, I mean the internet still existed. And there were website's, forums, where you could ask questions and exchange ideas and everything. This existed, but no YouTube and no stack overflow and no github. 

Colby: After those projects, did you move into roles like CEO and founder and roles like that, did that happen right after KDE? Or did you step into a couple other roles before?

Frank: This was a process. At this point in time, I basically had a split personality, because I was doing all this IT work in my day job where I worked for different IT companies and I was mainly managing engineering teams, management, customer relations. But in my other life, I was just an open source fan and did all that stuff for fun. Basically the KDE stuff was always a hobby for me. And then at some point I just thought, is there like an opportunity to bring this together somehow, to make a living out of open source somehow. This was when I founded my first company, which was like half successful I would say. But then a side project of that was Owncloud basically, which is an open source Dropbox, that's what I called it in the beginning, that you can host yourself.

It was also something I wrote like a hundred percent on my own to version 1.0, which was not that good at the time. I think none of my code still exists, which is good. But I did this and talked about it, built a community around it. And then there was also an opportunity to build a company around it. This is when I became like a real founder and CTO and we had some venture capital investment and became like a real big business. 

Colby: I'm glad you mentioned that, because for investments and stuff, it's often hard for investors to grasp how you can make money with open source tools because they're open source. So how did you explain it to them? Or pitch your idea to them? 

Frank: So for me, it's quite obvious. Because making money means that you're selling something, and of course you need to sell something, but you don't necessarily need to sell software licenses. There are lots of other things you can sell. Like you can like your expertise, support, for example other things. And there are good examples for that, red hat. At the time, there were a lot of successful companies who didn't sell software licenses, they didn't have to, the software is free, but there are other things they can sell, like helping companies to run it on a big scale, security patches, consulting workshops, all kinds of things.

Colby: And was that it for Owncloud? Was it a software package or were you offering something else? 

Frank: No. The business model was, the Owncloud times, it was actually a bit unclear. Because this was also one of the problems of Owncloud, that a lot of people had a lot of different opinions. What to sell and how this all should work, and this was the reason why, at the end, it was not successful. 

Owncloud was many things. Owncloud sold the support we just discussed, but Owncloud also sold an enterprise version, which was proprietary. But there was a community version, which was open source.

 But if you want to have all the features, you need the enterprise version and this is not open source and this costs money. And I always disliked that, because then open source is just used as a marketing tool. 

There were also experiments with dual licensing and all kinds of, I would say, not so good business models. This was also, you're right, this was partly influenced by the investors who didn't really understand it. And I also made some mistakes with picking my co-founders, to be honest, and at the end, this was also the reason why Owncloud was not successful. And then of course, the core team, including me, decided to reboot everything as Nextcloud and I think we made some better decisions about the business model and strategies and community and many other things. And I'm really happy that Nextcloud is now fully working. So we are profitable. We’re growing organically. We don't have any external investors. 

Colby: You don't have any external investments. Wow. 

Frank: No. This is all self-funded.

Colby: Off of that and managing and becoming CEO and all these different kinds of executive roles. I mean, you got the chance to do it early on, those roles, but for a lot of really technical engineers and technical founders, it's difficult to be a software developer and then the next day after you get money, you're in a leadership role, was that difficult? To go from working on technical projects to managing, or was it just a natural transition?

Frank: No, no. This is difficult. As you said, this is a process. For me, this really happened over 20 years. This really happened over a long time. It was really in the nineties, after my studies at my first job where I think I was just a developer for a few months and relatively quickly, I became the deputy head of department and the later head of department. So it's interesting how everything's developed and done, how it works technically, but then also explain it to customers and try to convince them that it's something useful for them. 

Colby: That's why that's usually why there's two founders.

Frank: And then also working with people and then this leads to management. I always thought, combining those two different things is interesting. Of course, in the nineties and the beginning, I made, obviously, so many mistakes and so it's a challenge, but then over years I just got better and better. And now, I basically don't write any code anymore at all. I'm only working with customers and team members.

Colby: So are you involved in a lot of the real business stuff and kind of seeking investment and everything, because that's also another major you can get in university too. Did you pick up that stuff as you went? 

Frank: This again was a process. There were some times, also at the beginning when I started with Owncloud, where I thought that this needs some magical expertise that I don't have, because again, I don't have an MBA or something.

And I thought I cannot do that. I leave this to other people which then didn't work out. And nowadays, I came to the conclusion that first of all, it's not rocket science. You can really learn it. You can get into it. Now the insight I have, is that it all belongs together somehow, you cannot have one person who thinks about business and the other talks about technology and the third about marketing and the fourth about community. It's all disconnected, which just does not work. This all needs to come together. What you sell is also what you build and what the community motivates. It's also something that you can use, and you have to give back to the community what they want, and it all needs to fit together somehow .You cannot really have one business guy and one technology guy and one, I think this is a mistake. It needs to have one strategy. 

Colby: Exactly. It's really hard to sell something if you don't understand how it works either. Off of picking up those skills, I wanted to talk about your speaking engagements and going to all these conferences, because looking through these conferences and looking at the talks, it seemed like you mostly did the high tech open source fields, like the Silicon conferences and everything like that. How did you first get involved with these, because you have a pretty big range between conferences and speaking at schools and with different audiences. 

Frank: It was a process. I really didn't like it at all 20 years ago, and then got an opportunity to give my first big talk. It was to the KDE community, I gave a keynote at the KDE academy conference. I just did it because I wanted to pitch my ideas and tell the story I wanted to tell. It was not about talking, this was not the purpose on its own. I wanted to communicate something and this is why I gave this talk.

And then another one, and then it somehow grew. For me, it's a part of communicating with people, exchanging ideas. That's what I find interesting. I don't think I'm someone who really likes to give talks. For me, talking is not the point. For me, the content is the point not just giving a talk. It's because I want to share it with people. I want to hear what they're thinking about the ideas. So the talking itself, I still hate, but I love to communicate with the community.

Colby: And off the content, do you stick with the same rough topic or area? Because you go to a lot of different conferences that are in various different fields. Do you kind of stick with the same talking point or not talking points, or the same areas of discussion, or are you having a different talk every time. 

Frank: For me, it's again, I'm not giving talks to give talks. For me, I want to talk about something that I find interesting or that we are working on, to communicate or share. So I don't have that many different topics basically. So for me, it's always about the importance of open source, privacy security, how software is written, what it can do.

 I'm not able to give talks about something that doesn't interest me. I really need to be passionate about the topic and then I give a talk. Also, always speak freely, I don't really write down the sentences I'm going to say. I really always like to just improvise, and this only works because I care about the topics.

Colby: That's much better than just listening to a lecture. And your talks and what you're focused on now, growing open source and everything. It's getting recognized and it's cool to see more and more larger companies actually be able to, and be willing to start using these tools. But obviously there's concerns about security and everything.

Because people just naturally think that open source means no rules and there's no maintenance or anything, privacy with the open source. How do you go about that? Because that's something where it's hard to find good resources and people looking into it. It seems like people are mostly focused on developing actual tools and not worried about privacy and security and everything. 

Frank: That's a good question. A lot of people have stereotypes about open source who think that it is just some nerdy things, which are not really usable for normal people. Which is of course obviously wrong. And then I often like to point out examples; hey, do you use Android? Yes. It's open source. Okay. Do you have a Linux server somewhere? Yeah. That's open source. Do you use any modern programming language, then they're all open source.

There are lots and lots of examples that you can give. And then all these open source tools can also be professional and useful. That's one stereotype. And you also mentioned privacy and security. This is something people need to be a bit more conscious about. What they're doing, how everything works, what it means, where it comes from, and so on. If you just go to some website, you use it, don't even think what's happening with the data, who has your password and so on. You need to think about it and know the transparency, like what code is running there, who has access to it, where is the data stored, and so on?

Then open source of course, very important because since it's open source, you can actually check what's happening. Is the encryption of my password good or bad? Or is there a back door somewhere in the code or something you can check with open source?

Colby: And which fields do you see growing rapidly? Because with Linux, it was operating systems and now there's a lot of open source operating systems and the chip design open source community is still relatively small comparatively, but it's definitely growing, especially with SkyWater and everything. Are you seeing other fields that weren't open source start to lean into open source and explore some of the tools or is it mostly still what it's been the last dozen years?

Frank: That's a very good question. Open source seems to grow from the bottom up. That's the kernel right? Linux is everywhere. Most of the devices we have use Linux; IOT devices, phones and connected coffee machines, cars, or planes. Linux is everywhere. And then of course nowadays you also have a lot of middleware, like services and infrastructure and libraries and all the things on top of it, the databases and storage systems and networking and application servers and all that stuff.

It's also like more and more open source nowadays. There's still some framework, I guess if you're into apple development, for example, then a lot of the APIs and frameworks are not open source, but for the rest of the world, most of the middleware stuff is open source nowadays. What's mostly proprietary still, is the application layer on top of it. A lot of companies think that this is their secret sauce they need to protect. I think this should change at some point, I mean this is also what we do with Nextcloud. Nextcloud is user-facing. Nextcloud is really on top of the stack. It is what people interact with. That's the area which is mostly proprietary and we based Nextcloud to do a full open source alternative. 

Colby: That would be awesome. Because that's one of the last areas that is still almost completely proprietary, and mentioning the UI stuff and everything, and your role. I even saw you were an advisor to the UN, which was something that I can't believe you're doing too. But making tools like that available to everyone, that's something I'm interested in too. Being able to use these for education, because in developing countries, I talked to a couple developers in Pakistan and India, they can't get the cadence and synopsis licenses for chip design. So they have to use open source tools. And now that they're at the performance they're at, it's possible to use them for education and everything. And for the UN and everything. What's your role with that? Are you focusing more on expanding open source or educating people on it.

Frank: The UN role I have, the advisory stuff I'm doing, that's not a big thing. The UN is developing some best practices, some policies, and some ideas on how to handle open source licenses in the right way. I'm just helping a little bit to build up these frameworks, how to do that.

Because as you said, open source is super important. For example, for developing countries. From the UN perspective, it's very important that if some money goes into a developing country, that it goes there in a way that it helps everybody. It doesn't go into the hands of a few rich people, and then most of the people get nothing basically. 

And this is of course where opensource can come in, because if you help them with technology, with software, and some funding to write software, or even funding a school that people learn how to write software. If all the software is open source, then it can be used by everybody and everybody can contribute and learn from it. And you can teach it in the next school because you can actually study how it works. This is why open source is so important. If you give some Oracle licenses to developing countries, this doesn't really help society, right? And this is where I'm helping there a little bit, but this is just a tiny hobby of mine. That's not me. 

Colby: Spinning off the future of open source and the future of your career. Because now, comparing it to your earlier career where you were doing all these crazy projects individually, you're a leader of developers and companies.

Do you think you're gonna try to pursue Nextcloud and speaking more? Or do you think you're gonna still keep your hands in all these different open source projects and everything? 

Frank: Of course. One of my goals in life is to have a positive influence in the world. I want to do something good. And I believe that giving a collaboration tool, like Nextcloud, to the world, which everybody can use. As you said, developing countries can use and study it. And without money, just put it on a raspberry pi and run it. This has some value. And if you care about privacy and security, I don't want to have surveillance then open source is very good. 

Without something like Nextcloud, everybody would use Microsoft or Google or Facebook or Dropbox. Then in five years, all the information or communication of the world is stored by five companies. And this would be weird. For me, this is the vision, to try to prevent this, to make sure that there is a free alternative to these big tech companies. So that's what I want to achieve. Those are my goals in life and all the other things I'm doing, like being CEO of Nextcloud or giving talks and other things, this is just to achieve that.

Colby: I would say that you've already achieved it. If I were you I'd be retired by now. But for Nextcloud, I forgot to ask this earlier, but currently, who are the customers and who's starting to use Nextcloud and become interested in it because it's always cool to see companies, and major companies, start to become involved with open source.

Frank: So there's actually very diverse, different kinds of users. First of all, Nextcloud has millions of uses all over the world, right? Because it's open source, everybody can use it. You just download it and just use it right. You don't need to register, create an account, or pay Nextcloud. That just isn't open source. So I don't even know how many users are out there, but from rough calculations, most likely many millions. But they're mostly home users or small users.

The big organizations, they probably come to us as a company because they want to have support and consulting, all the stuff companies want. We have some bigger customers. So it's a lot of governments, we have the German government, we have the French government, Swedish government now European commission lots of governments in South America, Asia. Basically organizations really want to keep their data secure. 

Colby: Getting recognized by governments is the top of the line for open source. Because usually they're the last ones who want to use open source tools. 

Frank: That's actually what I thought too at the beginning, I thought that clearly, we will sell a lot to companies and private businesses and government comes last, but actually governments really like what we are doing. So they're quite active.

Another big area is education. We have hundreds of universities all over the world using Nextcloud because they want to provide a collaboration environment to their students. And they often have their own infrastructure already. And for them, throwing Nextcloud on the server or cluster of servers and providing it to the students is relatively easy. We have a lot of companies like classic companies, enterprises, like I know Siemens or Infinian you might know as a chip guy. 

And several others and then also service providers, which is also interesting. So the German telecom companies are OVH in France or American mobile in Mexico, and several others are just cloud service providers who want to provide a service that competes with Google and Microsoft. And then rebrand it, usually under their own name and put it on the infrastructure and then they have something to sell to their customers.

Colby: This was really awesome to talk to you. I appreciate it.

Making money means that you're selling something, and of course you need to sell something, but you don't necessarily need to sell software licenses.

It's interesting how everything's developed and done, how it works technically, but then also explain it to customers and try to convince them that it's something useful for them. 

Now the insight I have is that it all belongs together somehow. You cannot have one person who thinks about business and the other talks about technology and the third about marketing and the fourth about community. It's all disconnected, which just does not work. 

I'm not giving talks to give talks. I want to talk about something that I find interesting or that we are working on, to communicate and share. 

I'm not able to give talks about something that doesn't interest me. I really need to be passionate about the topic and then I give a talk. 

I always speak freely, I don't write down the sentences I'm going to say. I always like to just improvise, and this only works because I care about the topics.

One of my goals in life is to have a positive influence in the world. I want to do something good. And so I believe in giving a collaboration tool, like Nextcloud, to the world, which everybody can use.

To make sure that there is a free alternative to these big tech companies.

Open Source Technology

A lot of people have stereotypes about open source, who think that it is just some nerdy things which are not usable for normal people. Which is of course obviously wrong. 

From the UN perspective, it's very important that if some money goes into a developing country, that it goes there in a way that it helps everybody.

If all the software is open source, then it can be used by everybody and everybody can contribute and learn from it.

The Challenges in Building a Company

A lot of people had a lot of different opinions on what to sell and how this all should work, and this was the reason why, at the end, it was not successful. 

I always disliked that, because then open source was just used as a marketing tool. 

This was partly influenced by the investors who didn't really understand it. 

I also made some mistakes with picking my co-founders, to be honest, and this was also a reason why Owncloud was not successful.

Matthias: I hope it's not disappointing, but this is exactly how this tool started, basically. I used to work for Qimonda which was a memory company, back then in 2004, five, something like that. They were only doing memories and so they did not spend a lot of money on licenses. So the tools we had were limited. My job was doing physical layout in a sense, so software development, plus physical layout. I thought I would apply my knowledge to building the tools I would like to have. So this was the initial motivation. You want to learn, you want to apply your knowledge. And in my particular case no one was interested in such a tool inside the company, so they wouldn't spend effort on developing such a thing when you can buy it.

Colby: What year was that? 

Matthias: Before the financial crisis, 2008. Because this is when the company went bankrupt so I think it was like 2005, six, something like that. 

Colby: And what did the open source tools look like at the time for layout, especially analog, cause even now there's not many good analog tools or tools that support analog.

Matthias: I think essentially there was only magic and static electricity, but not much else. Xschem was already there, but I didn't really investigate at this time. Whether there's a lot on the market already, they were small, a couple of small projects, but they were not well maintained and performance wise, they were pretty disappointing.

At this time, my particular concern was that we had pretty huge files. Because we went into a 14 nanometer node. You had pretty large file sizes and I couldn't use any of the existing free tools to do anything.

Colby: And did you do this individually from the start? Developing it? 

Matthias: Yes. To be honest, I cannot really remember how it actually started, but it was like, you start with an experiment, then it turns out to grow, then you think it's, it might be useful, then you develop it on your own.

Then, it took two or three years until it was major enough. So I put it on the net. That was pretty boggy, that version and slow. And then people discovered that they contacted me and I felt it's time to get more involved. And actually during the financial crisis I considered making a business out of that, but I dropped this idea because of such level entry. And as a single person player, you cannot really do a business there; it's too specialized and people would just buy mentor or cadence. 

Colby: And for the development part in actually creating the software behind everything, because software engineering is very different from hardware engineering. Was the software development part difficult for you? Or are you a software engineer by trade? 

Matthias: Yeah. I worked as a software development engineer and in the past I did some software engineering. But originally I studied physics.You need some reasoning, some logical thinking, right? 

What I think is important is, you need to have a vision, the path you want to follow and the goal you want to achieve. And this is easy for me as a single person, because I know what I want. I think that it’s rather underestimated how difficult it is to follow a path consistently and try not to deviate too much. Try to keep the big picture in mind. Try to focus on things like that. And it's far easier for me as an individual when I know what I want to achieve. 

Colby: When it first got really popular in the beginning, who was jumping on board, was it mostly other individual designers and developers? Or did any companies start to get in on it early?

Matthias: Yeah, mainly layout engineers like me. For companies, usually people who had some experience. NXP, for example, apparently they had a culture where they were actively looking outside for what's going on, that was my impression.

I didn’t know this company as an insider, but I was contacted from different sides by NXP and they didn't offer money or support, but they showed interest. That motivated me and was very useful for me initially. 

Colby: And I see that a lot of companies in education use K layout, because it's one of the closest tools to being at the level and look of cadence and synopsys. Did you try to model it close to cadence in those tools? Or were you just trying to get the capabilities that you needed for your projects? 

Matthias: In general, what cadence offers is much more powerful of course. And it's well designed. So what they now expose is a very nicely designed and consistent architecture. And this is not something that K layout actually offers. So it doesn't integrate schematics. For example, it's a pure layout tool. If I really would like to replace cadence, then I know that I have to spend a lot of effort in rebuilding such a similar ecosystem. 

And the scope initially was a different one. It was not about layout, but about visualizing huge data sets. And that is technically a different requirement. And cadence cannot visualize these. It's just awfully slow, would not display properly and so on.

Given that background, it doesn't model cadence. But of course there's an overlap and you can use it to do layout, but you cannot, for example, link it to a schematic. Of course, you don't have virtuals or excels or you don't get nets highlighted and things like that. You don't have a program as involved, so it's not really cadence, but it's part of that. 

Colby: And if you wanted to make something like cadence, they've used hundreds of engineers, so to do it by yourself, it would probably be a lot of. 

Matthias: I don't know how many engineers Cadence actually employs. I think the core team isn't that big. They do bug fixing, but they have maintained the same architecture over decades now. Which is of course good for people asking for backup compatibility and sustainability.

And of course it's good for cadence because they do not have to spend money on such basic work. On the other hand, you feel that cadence now is aged, right? It's major maybe, but it's also aged. And I actually believe that if you would do that from scratch, you wouldn't need hundreds of developers.

Maybe if you take a team of people who do it from scratch with modern tools and modern frameworks and modern languages, they would actually be capable of redoing it. 

Colby: To see an open source one would be really cool. 

Matthias: The problem I see here is that maybe it's legally risky because you don't know how much is actually patented. So it's not good advice to rebuild something that is available, and cadenced managed to tie people quite closely to the ecosystem, because it's not compatible with anything else outside. It's not impossible to redo, but I just don't know whether it's a good idea.

Colby: Speaking on the beginning of K layout and being a developer of an open source tool, especially an individual one. You're responsible for the maintenance and helping people that are having issues. Now, there's people all over YouTube and GitHub that are making tutorials for klayout. But in the beginning it was probably difficult to develop the tool and then have to do maintenance and help people learn how to use it.

Matthias: The community isn't that big, so it did cost me a lot of time. And I set up this forum that people still use. I consider, from time to time, doing tutorials, but It's tedious. And you have to make video recordings with good quality, which is actually challenging.

So I didn't do this myself, but the forum and the documentation I wrote. This wasn't so much effort. I felt that there was a lot of positive feedback which gives you a good feeling about what you do, and for me, that's payment enough.

But I think you are right. Now it's actually growing and I feel that it could grow a lot more. And there's a point now where I'm happy that people jump in and take over these kind of let's say, add on activities. I feel that right now it's going to become a community project rather than a single person activity.

Colby: Which is really cool to see the community grow and for the documentation part, because klayout has surprisingly good, very good, documentation in terms of open source tools. Did you always try to keep it to a really high standard or did you go through and add a ton of stuff when it started to get really popular?

Matthias: I mean, I felt that providing good documentation reduces your efforts and one on one support, and it probably did. To be honest, I think the documentation, in parts, I'm pretty proud, but in parts it's just too little. It would need a lot more explanation and examples and so on.

Whenever I created a new feature, I also tried to document it at least well enough so people would be able to use it and give feedback. I also get other feedback, people saying I looked everywhere and I couldn't find the answer to my problem. I'm not sure whether they are just too lazy to really look everywhere or whether they really don't understand it. But in general, the feedback is positive.And I still try to keep the documentation effort lower than the coding effort, so that's prioritizes code still.

Colby: It's really cool to see klayout being taught and learned at universities because open source is helpful with education. Have you seen a lot of or been reached out to by schools and everything and seen it being used at a bunch of universities?

Matthias: Yeah, of course. Sometimes you get requests from teachers, But usually they tell me that they are preparing a course. They would ask for certain advice or they encounter issues when they have 50 students, and some of them have special problems because their device isn't capable of doing this or that.

So I get feedback of that kind. But what is really interesting is I was once doing an interview with people in India because they wanted to hire engineers there. And some of them told me they know me already because they learned layout at, in university or at school by doing K layout.

And, you go to India, one and a half billion people and they know you. So that's actually pretty rewarding.

Colby: And off of that, is this your full-time job now or are you still working full time?

Matthias: I'm working full time as basically a physical implementation engineer, but on a close to MOSFET level. I'm not a designer, so I'm not doing digital or analog design, but what I get is the output of the design flow. And then it's about making masks and doing your final physical checks.

And also what I'm doing most is supporting technology integrators or technology developers, getting their features on the masks. Pretty physical work in that sense. 

Colby: For everything that's happened with K layout and the popularity and how it's grown over time have you seen, especially on the forum and everything, and I saw that at one point there were thousands of downloads a month. Especially now with efabless and everything, do you see it growing even more? 

Matthias: I haven't checked recently to be honest. I try not to track people and it's also difficult because open source is always distributed for many terms and I don't know how realistic that is.

Colby: Yeah. It's really hard to keep track with open source. 

Matthias: If it gets published as a package Ubuntu, for example, then people would rather use that instead of downloading. And I don't want to track people by checking IPs and so on. So I don't want to do this. It's a matter of trust. But I feel that there's a lot more traffic in the forum where people can ask questions. And I see a lot of forks and side projects popping up and. And people creating pull requests and so on. So this has actually increased. And there's a lot of connection to open road and open lane and SkyWater of course. And I'm in touch with a couple of these guys mainly in terms of advising them or bug fixing.

Colby: Are you doing major releases still or just mostly maintenance now? Because you've been developing klaoyut for quite a while now. So is it mostly just bug fixes or are you still doing major releases of it? 

Matthias: Yes. So the answer is yes. There are some big topics like people, for example, asking for parasitic extraction. So where you generate resistance, receive values of resistance values from layout and capacitance values and annotate net lists with that. I think this is feasible, but it's not my field of knowledge, to be honest.

And that's something I have in mind. Basically for the future, I cannot promise anything because I do not have a real roadmap here, but I think this is something that, with the proper connections and support, maybe knowledge sharing with others. It could be a feature which is, the next to come, but it's not a, it's not an announcement in that sense.

And there are a couple of other major enhancements to, in particular, if it comes to verification of SkyWater layouts. I think there's a lot which can be improved. Performance can be improved, accuracy, and new features being added. Maybe also, in the direction of forecasting analog layout.

I think there are many ideas, and I still pursue some of them, but it's too much to do everything that people request here. But it's not closed. It's not maintenance mode only. It's not bug fixing only. But of course, bug fixing is a major part. 

Colby: For sky water, or even other fabs that klayout has been used on, have you had to go in and make specific changes and revisions to make it compatible with different kinds of processes? 

Matthias: So far, it was not necessary because they're using an ecosystem which comes from cadence and mentor and of course they are compatible. Their design system wants to be compatible with these tools, so they cannot build in features that cadence or mentor doesn't offer. And that's why they can't confine themselves to design rules, for example, which can be implemented with mentor and mentor, it's an amazing tool I need to say. But the functionality is limited to the standard features and that's why they did not require or request something beyond these standard features. 

And Klayout offers, not everything, but let's say a reasonable subset of calibrators. And so they can use it in a sense. Performance is not as good, I need to say, but it can be improved hopefully. But so far, there was no need for extended features here. 

Colby: I also wanted to touch on the upcoming conference, the FSCi conference, the one in Paris, because you're one of the organizers of that. I wanted to touch on that one specifically and how you're involved in this community because it's a pretty small community, but it's grown really fast. 

Matthias: Yes. The involvement, this is not the first time we’ve done it. We did it in 2019. And initially, there were a few people that were contacting me and it was very small. I attended and it was a nice event, I need to say, and I felt that the people there had the right mindset.

So they were looking for open source software specifically. And they were mainly driven by the need for education because they were all from universities. And I felt quickly connected with them.

And a year later we extended the circle somewhat and suddenly there were 50 people, and this was a really nice gathering. And by coincidence, at this time also, the whole sky water idea popped up, but then the pandemic came. And now we are trying to reboot. But honestly, times have changed a little. So now we have sky water. And there's a lot more competition I'd say. But still we expect about 50 to 60 people to gather here or maybe even more. And I hope it's going to be a nice community event.

Frankly, Europe is not quite the center of this, of the semiconductor world. And it's quite a small community, in fact. And in the end, I know most of the people who are active in Europe, but Paris is a nice place to go so maybe this is an incentive. 

Colby: Pretty much every tool that's available, its creator and developer is speaking. Were you part of getting all that stuff together? What was your role in planning the event?

Matthias: I think my main contribution was probably putting the banner on my website and this affected a lot of people. The main organizers did all the work of contacting people and asking them and inviting them.

Colby: Yep. And I saw your talks. You're doing a couple on Klayout and one of them is, the workshop. What's your plan for the workshop and the tutorial? 

Matthias: My plan is to present a couple of frequently asked questions. Which I'm going to take mainly and from forums. I’ll try to give some answers to them in a way that people learn how to solve their own problems. For the tutorial,  it’s just one hour so I cannot do a tutorial in one hour, but I want to motivate people to ask questions, not to be shy. And also tell me when they have a particular problem. I think that's eventually the message I will try to convey here. 

Colby: And for the tutorial and workshop, have you done something like that before? Because as a technical engineer, it's really hard to explain technical programs and fundamentals and theories. This community's good because they're pretty familiar with the tech already, but have you done workshops like this before? Because it seems difficult to explain a tool that has this many capabilities and is this technical to a lot of different people.

Matthias: If you talk about trainings where you present something in a step by step introduction, I haven't done these so far. My experience is that people like to try things, and then once they are stuck, they approach me. And this is exactly what open source is about. There's no barrier, you can just install it and try it yourself. And if it works out of the box and people can already have some success or some first impressions, they will start just using it without any training.

When it comes to training, it starts becoming necessary if it's about special features. So when they master the entry level and they want to do something else. Usually, this is when they have particular questions. And that's why I think the FAQ format is maybe one way to address the interests of advanced users. I'll see how it works out. 

Colby: It's helpful now that there's a ton of different tutorials all over the internet for Klayout.

Matthias: Entry level, I'd say, but I think I don't need to explain to people how to draw polygons.There’s YouTube videos about this, but when it comes to how to tailor the spice reader to read your particular spice dialect. That's not something where there isn’t a YouTube vivideo. 

Colby: Cause that's not really entry level. 

Matthias: Yeah. I expect that most people there have some knowledge and others, many of them, I'd say that they're experienced already.

And I think it would be boring for them to listen to an entry level video. On the other hand, I understand that there will also probably be some students who have basic questions. I hope that we have time for discussions and I can tell them. Maybe next time I'll offer a basic training session.

Colby: And I'm glad you brought up the open source stuff. In the very beginning, I know you mentioned maybe thinking about turning into a company early on, but it's hard as an individual and choosing to go open source, because there really aren't that many open source tools, especially with these kinds of capabilities. Was that something you knew you wanted to do was make an open source tool at the beginning? What were the motivations to choose to be open source instead of a closed source tool? 

Matthias: That’s a good question. If you work on your own you never know what level you are on. You can be content yourself, with what you did, but it's a challenge. So open source is definitely a challenge and it gives you a way to get feedback quickly because people will just use it.

But there are always people just installing it and trying it. When you do something on your own, I felt that it would just lead me to doing things myself, without exposing it. And finally I would never know whether it's good or bad or if someone wants to use it or not.

And as I said, for me, it's a kind of challenge. This is what motivated me initially. And once I got all this feedback, in particular the positive ones, then the motivation is to help people. And in the end, if I see that people are being educated with this tool, then it's also a way to improve the world a little bit. If it's an option for Indian students to learn, then it's hopefully of some benefit. 

Colby: Just a side point off of that, I've talked to a couple different developers that are pushing projects through efabless in countries like Pakistan and India, and they can't get the cadence license or synopsis license. So tools like these are such a huge help for them. 

Matthias: There are many countries, it's not just India and the east. It's also Africa. And this is the kind of feedback. Egypt, for example, is pretty active in, in terms of education. And I believe this is also at least partially due to the availability of open source today.

Colby: That's pretty much all I had for today. This was awesome. 

Matthias: Thanks. It's maybe different from when you have a startup founder, they would probably talk differently. Did you already do a lot of interviews with developers or software open source developers?

Colby: Not too many real open source developers where everything is open source and, especially with a community like this. It's really cool. The more people I talk to, the more companies that are becoming open to using them because they're so well maintained now. And there's so many different ones to pick from that are quality tools. 

Matthias: I need to mention something here. Maintenance of open source tools is actually a business model, right? Let's say the owner of an open source tool still has the ability to withdraw the tool, then it's difficult. But with GPL I cannot withdraw anything and I cannot prevent anyone from making money with that.

Which I don't want to, but eventually someone could sell Klayout and offer a maintenance contract with that. And this would then leverage the tool to a professional level that's also acceptable as a production tool for industry for example, redhat does this.

They take an open source system. Then they improve it. They certify it and then they sell it to banks who can do their financial business with Linux. This is actually a business opportunity.

Colby: Yeah because maintenance is really difficult for an individual developer to do so if you had a team, you could really improve it.

Matthias: Someone generating revenue could also spend development resources in contributing or doing maintenance or just doing testing, or improving documentation or giving training.

Colby: I'm glad you brought that up, because there are a lot of ways to make open source into a business.

Matthias: But it is a business model and eventually, when the code is GPL, the code is available to everyone which makes every human on earth a potential supporter maintainer. So that's incredible. So it's not a cadence organization, which is the only one who offered to make such an offer. Open source means almost 10 billion potential maintenance supporters, and contributors. That's how I see it. That's why I actually love GPL as a license because it doesn’t create a risk for someone engaging.

I started to develop xschem in 1998, and for a long time, it was just a hobby project with slow progress. It was not even considered to be useful for other people. xschem was the only tool that could be used for real VLSI design that was also open source. Which naturally means xschem is kind of old school, but this does not mean it is useless or obsolete. It's just using an old approach. But as a result, it has a very low dependency list on libraries or systems. 

I decided, for the user interface, to use TCLTK. TCLTK is a scripting language, which provides a set of tools for building the user interface. With other languages, you waste time fighting with the user interface. But with xschem, my time spent on the user interface has been a very small fraction of the development of the whole program. I can even compile xschem and run xschem with old TCLTK libraries, which is a common problem for systems like Cadence.

Then, around 2016, I decided to put xschem on sourceforge, and then in 2018, I decided to put it on GitHub. So I had a public repository for other people to use the tool. Then the real boost in xschem was when I was asked to join the SkyWater project. Until recently it was just me working on development. I now have a second developer and she is developing a native window executable, so it can run on windows.

I have made a lot of additions to xschem in the last year. For example, the program can now handle multiple tabs, multiple schematics. This looks, a small change, but when you program this, you need to do a lot of stuff to avoid the global state in the program because you have multiple global states. So you have to reformat the program and correct a lot of things, many global variables. Another addition I made is the ability for xschem to view waveform graphs in the schematic. Because you said, there are few good analog schematic tools in the open source, and I can add, there are no good analog waveform viewers in the open source world.

I believe in the 10-90 rule, that 10% of the users who have problems ask 90% of the questions. Some are power users, and they discover real bugs in the program and they are very useful to me. Some just don't read the documentation, and if you start using the program and you don't read the documentation or even worse, some don't even have a clear understanding of the operating system. It's very hard to explain if they are not familiar with the system.I try to be as useful as possible, but in some cases I have to say okay, read this manual, or read this one. I get the same question many times and this is probably something I want to avoid. If you want your program to be successful and to be used by the most amount of people possible, the documentation is the most important thing, together with error checking and not crashing.

Xschem is also used by some small companies in various industries. One is a company writing hard net chips for space applications. Another one is in Canada and is using xschem to develop sensors. These are small startups who cannot afford the huge price for cadence licenses. 

I think xschem has the potential to close the gap with more complex software like synopsis or cadence, but just for schematics. Which are only a portion of those commercial tools.I live for other developers to write the next generation software. For the time being, I just want to scheme to be usable to get the work done, have a low footprint and just be as useful as possible. For the brand new tools, the brand new user interfaces I leave this to others, of course, because I don't want to write the second program. I am too old for that.

To be really successful in the role, in any kind of role in developer relations, you need to have some traits of all those different kinds of individual contributors.

What differentiates us [developer relations] from marketing is that we are as authentic as we possibly can be. Mostly because developers can smell bullshit really quickly.

We are focused on the individual developer and making individuals successful, even if they are just a basement hacker.

We [Rob’s team] have pretty good technical backgrounds and those soft skills that are required to be successful in a technical role.

I've only been successful when I've hired people who have been really fantastic and very self-motivated and self-driven.

When we see folks posting Hackster projects using the Notecard, purely organically, that's amazing. That's when we know that we've really done our job.

Blues Wireless: and it’s world-class IoT Technology

[The Swan MCU], it's the most extensible feather compatible microcontroller. 

The Notecard is the core of what we do. Ray Ozzie started the company in 2017 officially. But it took a couple years before they launched publicly with the Notecard, but the whole point of the Notecard was to make cellular IOT cheaper and easier to use.

Then you have the [NoteCarrier] A, that's the black one that we just released. That's my go to, really generic, it's got great onboard antennas on there. You can access virtually any pins on the Notecard with it as well. The [Notecarrier] B is what a lot of people go to production with actually, because it's a really small form factor. 

New Products Coming Soon

In about two or three weeks, we have a new Notecarrier coming, that's exciting. We have the Notecarrier AF today, which is our largest Notecarrier. That's got the feather socket on there. We have a new, pretty dramatic revision of that coming out, it's a smaller form factor. 

And I believe in August, we’re releasing our Sparrow project, and this one is pretty interesting. So what Sparrow does is provide a single Notecard gateway. It's got a gateway with one Notecard in it, but then the gateway communicates with n number of nodes over LoRa. So you can have a bunch of different LoRa sensors with a long range. And the gateway will, using some novel techniques of polling the individual sensors, one at a time, will continually gather that data and then pipe it up to the cloud through that one gateway. 

We are looking at doing a new revision of the pi hat as well, so that'll hopefully be coming by the end of the year.

Colby: Can you describe your role as Director of Developer Relations, because it seems like a coverall title for such a mix of technical and non-technical responsibilities. 

Rob: As you say, with developer relations, frame it as good or bad, it suffers from the fact that it does sit in the nexus between, marketing, sales, product engineering. To be really successful in the role, in any kind of role in developer relations, you need to have some traits of all those different kinds of individual contributors and roles in those different organizations.

I summarize developer relations as the Three C's; we're doing code, community, and content. For code, we work on the projects that you've seen on Hackster and contribute sample apps. And then on the community side, of course, we're charged with building, growing, nurturing, the community. Folks who are actively using our products and on the content side; doing video webinars, blog posts, that kind of stuff too.

Colby: So basically, the product's handed to you, and then you make all the content around it to teach people how to use it. And then you go market it to people who want to use it. 

Rob: And what differentiates us from marketing is that we are as authentic as we possibly can be. Mostly because developers can smell bullshit really quickly. So non-technical marketing doesn't work really well in these companies. They need to see it working in real life, and prove it out. That it's not just blowing smoke. To be able to tell an authentic story and to have some kind of engineering background really resonates with technical audiences.

Colby: Have you found any trouble getting the product from engineering and trying to figure out its capabilities? Or doing a project from scratch, cause no one's going to tell you if it's going to work or not. Is it mostly trial and error?

Rob: When I'm planning a project, in my head, slash on paper, can map out all the different components in terms of the hardware and then making sure that there's the right software. If I'm doing a project in Python, to make sure there's the right libraries available for all the different components. And once I at least have an idea that “oh yeah” I think this is possible based on code I've seen, or code I know I can write. Then I feel pretty confident. 

But it's a different story with our own products, ironically, because when I'm using third party components, I'm not diving too deeply into a lot of the functionality. Which sounds really vague, but let me juxtapose that to our products, which I am diving really deeply into and releasing new firmware features and new hardware releases all the time. And often there's a bit of a gap between us and engineering because they're building, releasing these features. Then I have to get up to speed and I need to know those inside and out. I have to be a literal expert versus using a third party where I just need to know roughly how it works.

Colby: And doing the projects, especially, cause I like to talk about open source a lot. A lot of issues arise in compatibility, I’ve found, with products and hardware, do you just trial and error to find open source tools? How do you go about researching and finding a good open source tool to use when you do a project?

Rob: A lot of it's referrals, a lot of it's looking at, you know, documentation. Are things well documented? Are there decent samples available? Is there a sizable community behind them? Are they well maintained? And even even well maintained can just be once a year or something to make sure that there's a heartbeat out there.

This is the core of developer relations is this concept of developer experience as well, and that's huge for open source. Are you providing an engaging developer experience from beginning to end, and removing friction at every possible point? That's the ideal open source journey, if you will.

Colby: Have you had any problems with open source? Cause what I run into a lot is, like you mentioned, not well maintained or bad documentation. Have there been any problems where you've had to make a major switch away from any open source tools?

Rob: Yeah. I mean I've certainly been luckier than most. And I have a background in engineering, so I do have decent technical chops. I don't consider myself an engineer today, but I can work around simple issues, and I know everybody experiences this; where recently I was working on a proprietary microcontroller that works with a dot net frame, a kind of a micro.net framework. 

But my background's in .net and C sharp, back in the day. So I thought it would be cool to work with C sharp on micro controllers. It works well, but I ran into a problem trying to get support for an individual sensor. I asked on their forum and they're like, “oh yeah”, you can do that, but you just have to dig up this five year old or 10 year old, some ridiculous C library and rewrite this part of it. And this is the bad part of open source. Where it actually becomes work for you. I understand I'm not maintaining anything currently, but I know the pain of individual open source maintainers. The shit they have to deal with from the community can be overwhelming to say the least.

Colby: Off of that, how much are you involved with the support side of things? 

Rob: So I do a lot of work on our forum. We have a couple different support avenues. We have a dedicated support team of two people right now, and they handle our, we don't have paid support, but it's basically email based support. Then I handle the forum side of things, so our public forum. Which is support and community, kind of wrapped up into one.

Colby: I went through the Blues forum and the documentation and tutorials which are really extensive. It's pretty cool to see that. Do you offer support on your own projects?

Rob: I will certainly answer questions. I get a lot of questions on Hackster in comments or private messages or whatever. I always answer every one of them as best I can because, and this is the reason I think that I've always enjoyed developer relations, that I can really empathize with people, especially beginners. It's how I build my projects too. I don't assume too much knowledge because I know what it feels like to start reading something and you're lost right away. 

Colby: Why did you choose Hackster as your main platform?

Rob: Cause of their reach, and Hackster just fits that right niche for us. It's not too hardcore EE cause I don't have an electrical engineering background whatsoever. So I'm focused more on the basic functionality of what I'm trying to do. Not the nitty gritty details of the boards and components and stuff. So it's the right audience for that.

Colby: Just to touch on a couple of the projects, because founders might want a prototype of something just to see how it works, and the bill of materials they have is for $20,000 for something like a speed radar. They have $20,000 in parts, and then I'll pull up your hackster project and make it for $300 or $400 total and that's it. When selecting components, is that just researching other projects or do you just pick those because they can do what you need them to do?

Rob: Most of what I do is really basic off the shelf, but obviously the Doppler radar for the speed radar project did require some research. I knew I was going to use a raspberry pie for that, so I was looking for a Doppler radar sensor with a Python library that was already written. 

Colby: I wanted to ask, when using different boards, because there’s differences from board to board and firmware to firmware. Even the differences between using a raspberry pi and an Arduino can be difficult for some, and then going to just a microcontroller that doesn't have a UI, it’s a huge gap.

Rob: When I started at blues about a year and a half ago, one of my first concerns were the things I was trying to do with machine learning. There's no way you can run these programs on a tiny little micro controller, right? So I started with the full size raspberry PI four, which was great for a lot of things. And then that's when I discovered edge impulse and realized that there was a lot more I could do on smaller boards. Over time, I've graduated to smaller and smaller, less powerful boards.

Not to toot our own horn, but actually I think the Swan microcontroller that we sell hits this sweet spot and it's been, frankly, underrated. In that it's using a really powerful but low power STM 32 chip. It's sort of ideal if you're running, especially, some heavy duty machine learning inferences on it. It performs surprisingly well. 

Colby: Can you touch on that Swan more? I haven't heard of that.

Rob: So we released it maybe nine months ago. I'm going to use a marketing line; it’s the most extensible feather compatible microcontroller, because we have little castellated edges around it. So you can expose a ridiculous amount of IO from the board itself. So if you're connecting a ton of peripherals, it's great there, but it's that combined with low power and then a powerful, relatively new, STM 32 processor. And it's certified with edge impulse. 

Also on the Swan, there's a little port that lets you hook up an ST link debugger cable. And this is another thing that was big for me coming from the web world, where building, writing, building, coding, deploying to a device can take a minute or two sometimes. So when you're iterating on these small changes, you have to recompile and wait 30 seconds for this to redeploy. By using the Swan with this debugger cable, you can do lightning fast deploys without entering into this bootloader mode and stuff. So there's a lot of nice features on it.

Colby: What is it targeted at? Is it a mostly general development board, like a pi, or are you targeting a specific use? 

Rob: I would say it's mostly pretty general. We were actually inspired to build it from one of our larger customers who had this need to expose a lot more IO than was available on a lot of existing feather boards.

We're trying to position it as a machine learning capable board. But to be totally frank, we haven't got a ton of traction with it. Its sales have been fine, but it didn't blow up like we were hoping. So I think it still has promise in the future.

Colby: Have you used it with anything yet? 

Rob: Have I used it? I don't know that I've actually used it in a public project of mine yet. But I do use it regularly. I love to prototype stuff in Python, even though it's not a necessarily realistic production language. It's interesting too, not to get off on a different subject, but our analytics, with our guides and tutorials, is almost a 50-50 split between people using Python on pi's versus arduino or C with other microcontrollers and stuff.

Colby: Speaking of the Swan and everything, I want to talk about some of your other products. The most popular seem to be the Notecard, Notecarrier, and the pie hat. Are those the two or three big ones?

Rob: Yeah, really the Notecard is the core of what we do. Ray Ozzie started the company in 2017 officially. But it took a couple years before they launched publicly with the Notecard, but the whole point of the Notecard was to make cellular IOT cheaper and easier to use.

While the Notecard still remains the core of what we do, we branched out into a wifi Notecard and we are slowly but surely building off of that. We initially thought of the Notecarriers as a prototyping tool, because we expect when somebody's going to go to launch at scale with a Notecard, they're going to spin their own board and they're going to embed the Notecard into their own custom board. But a lot of people are finding that the Notecarriers offer onboard antennas that are really nice now, really easy access to some pins on the Notecard, solar T port, etc... that they're actually going to production with some of our Notecarriers as well. 

Colby: Are you targeting both commercial and hobbyist people for these products? 

Rob: Yeah, for sure. If you look at our website, there's success stories or use cases, and that's where we're starting to publish some of our larger customers. We have a couple really big customers that we can't talk about yet, but that's how we're going to be successful long term is by onboarding these customers. 

But my team doesn't work with the large customers. We are focused on the individual developer and making individuals successful, even if they are just a basement hacker, hobbyist kind of person that's fine. We know we're not going to build our business off of them, but every once in a while, those people who are tinkering at home go back to their company and they're like, “Hey, I was successful using this Notecard thing, let's try this at scale”

Colby: What people does your team consist of at Blues? Because there's a huge difference between engineering and then the task of teaching people how to use it. And there's also a huge difference between hardware and software and hardware and software engineers.

Rob: I'm leading a team of one traditional developer advocate. Who can pretty much do anything, he's a really good speaker, instructor, he's a fantastic writer. I also have a somebody who's more traditionally a firmware engineer, so he is a little more hardcore, what I consider hardcore. So he's got a great background there. And then we just hired a community manager as well to handle more of the scaling and maintaining of our community as well. So combined with the four of us, we have pretty good technical backgrounds and those soft skills that are required to be successful in a technical role.

Colby: For tutorials and lessons and all that, there's the Notecard and all the hardware and then also there’s Notehub IO, and that's developed a lot, even in just the past year. Have you been a part of that and developing what that looks like and how to teach that to people as well? 

Rob: Yeah, certainly on the instruction side. We're not involved as much on the engineering side, the way we interface with our product and engineering teams is mostly to provide feedback from customers to them. So obviously if there's a bug, that's priority one, but when it comes down to it, like I said at the beginning, our job is to remove as much friction as we can from the developer experience. So if they're having problems with Notehub, then we definitely want them to know about it. But on the tutorial, instruction side, for sure, we're doing workshops, we're finally doing them in person again. 

Colby: What do those look like, the in person workshops? Do you just hand out a bunch of boards? 

Rob: We provide custom built hardware for these workshops, and you're going to love this, but we call it the hammer of blue. So we hand these out because it's a fun thing to use. Obviously at a workshop you want something that's really fun and engaging if you're going to sit in a room for two days, but it's got components and sensors on here and it does have a Swan at the base. And it has all the raw materials you need to be able to build a pretty engaging project. 

So we walk people through just this one piece of hardware, getting started with the Notecard, sending data to a cloud, building a machine learning solution that uses the accelerometer on the board and generates inferences to identify different types of motion with the hammer. And we can do all three or four labs with that one piece of hardware, so it's pretty fun. 

Colby: Off of the routing and everything, this is probably hard to answer, but what projects use blues the most often, it's probably not a specific category, but for example; I really like it because routing data from one place to another has been the hardest part of some of my projects, and Blues is actually really good at it and explaining how to route it to another source. Are there specific types of projects that use Blues more than others or is it pretty much any project that needs to get something to the cloud or route it?

Rob: You know, it's a blessing and a curse in that, when you talk about IOT, being internet connectivity, there isn't a target market for us. Which is great, in that anybody can use the Notecard. But then for our marketing teams anybody can use us, so who the heck do we even market this to, and that's again, blessing and a curse. We apply to everything, and if our marketing team has had one struggle, it's been trying to focus on, they call it the repeatable sales motion, but trying to repeat some kind of niche market that can utilize us. We're a victim of our own success in some ways. 

Colby: I wanted to, before I forget, mention your education and background and degrees in behavioral science. How did you move from that into engineering? Because that's a pretty big jump between two very different fields. 

Rob: When I was growing up, I was always into computers, but I never thought of it as being any kind of a career. I thought I didn't like programming back in the day. I just liked to do some gaming and tinkering. 

I ended up getting a degree in behavioral science, because I thought I was going to go to law school. And then my senior year of college, I got a job doing computer support at a department on campus. And my boss there ended up being a long term mentor for me and really showed me how cool it can be to write some code and push data to a database.

From there I got into a lot of web development and engineering. I had a consulting role and worked at the University of Wisconsin for quite a few years. Where, I realized that my real love, aside from engineering, was in instructing, building content, writing about what I'm doing, which is where my degree came in handy, because I was doing a lot more of those soft skills, if you will, in terms of writing and speaking and such. So that's why I think I've been successful in developer relations, because of the combination of my technical background with some of the writing skills.

Colby: Which is huge, because a lot of engineers and technical founders have a really hard time explaining their tech to people. And since you went to school for a non-engineering degree and then became a software developer, how did you learn those technical skills on your own?

Rob: I think what it comes down to for me is, and we've identified this as well, in developer relations, that there's a bunch of different types of learners. There's people who like to watch videos and learn that way. There's people who like to read through tutorials and do it step by step. Then there's people who like duplicating a project, and this is how I learn best. I'll take a big chunk of code that does one thing, and I'm like; “You know what? I wanna do this one thing that's a little bit different”. So then I learn by going through the code and identifying what I need to change. So it's like cloning an app, building it, seeing how it works, and then starting to make changes and build off of that. And then maybe eventually rewriting it with my own knowledge. 

Colby: Deciding to become a software developer, as that’s very technical, sitting at the desk and just coding all day, and then moving to developer relations. Was it hard to decide between those two or did you know you wanted to move on and be able to do the education part and accompany it with the technical stuff. 

Rob: I knew I needed to move on. I had been in a pretty traditional developer role for quite a while. I still really enjoyed it and do enjoy it. I'm definitely an introvert at heart, so I'll just sit at a desk all day and code and be perfectly happy. But I also knew that I had a lot more to offer and I think that's why at the end of the day it was pretty intriguing to get into developer relations.

Colby: Was it difficult to move from a technical role to a management role? 

Rob: I love the idea of being a manager and leading a team, but I've only been successful when I've hired people who have been really fantastic and very self-motivated and self-driven. I'm not good in a manager role when I have to do a lot of checking in. “Hey, did you get this done? When do you get this done?”. So while I do lead a team, I take pride in the fact that still probably 50-60% of my time is spent doing individual contributor tasks that anybody else would do. 

Colby: I wanted to touch on some other products and newer products from Blues. I saw the air note and there's a few that I don't think I've seen a lot about before. And what's coming in the future

Rob: In about two or three weeks, we have a new Notecarrier coming, that's exciting. We have the Notecarrier AF today, which is our largest Notecarrier. That's got the feather socket on there. We have a new, pretty dramatic revision of that coming out, it's a smaller form factor. 

Colby: Can you describe the Notecarrier AF a bit more?

Rob: So the AF is the one that we're replacing and we're calling the new one, the Notecarrier F to try and simplify our naming a bit. So it'll have a feather socket, it'll have quick ports, threading, peripherals. There's a bunch of good stuff. That's a mid-size product release for us. 

And I believe in August, we’re releasing our Sparrow project, and this one is pretty interesting. The idea behind Sparrow is that people will come to us and say, “I need to monitor a warehouse and I need to monitor 50 points within this warehouse, but I don't want to buy 50 Notecards to do 50 different points.”. So what Sparrow does is provide a single Notecard gateway. It's got a gateway with one Notecard in it, but then the gateway communicates with n number of nodes over LoRa. So you can have a bunch of different LoRa sensors with a long range. And the gateway will, using some novel techniques of polling the individual sensors, one at a time, will continually gather that data and then pipe it up to the cloud through that one gateway. So it's really great for folks who are scaling to a lot of Notecards and sending a lot of data.

Colby: That’s interesting, because projects with a pi or Arduino, you would have to use 50 of them. What are the differences between the different Notecarriers, are those just older products or are those completely different?

Rob: They're all different in their own ways. The AF and the F, the advantage of those is that you can drop a microcontroller or a feather compatible microcontroller right onto them, so that's nice. Then you have the A, that's the black one that we just released. That's my go to, really generic, it's got great onboard antennas on there. You can access virtually any pins on the Notecard with it as well. You can connect all kinds of stuff to it. It's really just a nice do-it-all. 

The B is what a lot of people go to production with actually, because it's a really small form factor. It's barely larger than the Notecard itself. But it doesn't have any onboard antennas because the size is so small. And the pi of course is the only one that works with the pi hat. We are looking at doing a new revision of the pi hat as well, so that'll hopefully be coming by the end of the year.

Colby: That's probably the most popular with the hobbyist people too, something you can just click on to a pi. Are the A and B standalone or do they go with microcontrollers usually?

Rob: Nine times out of 10, you are hooking them up to a microcontroller. One of the interesting things, and maybe you saw my project on the power outage monitor. That's a really interesting way that we're using the Notecard firmware, adding as many capabilities as we can to the firmware that don't require a host to function. So that's just the start, there's a lot. And I know the team is working on some other features as well that we can use for those really specific use cases. 

Colby: I also wanted to touch on your crypto project too, because I've never heard of using a pi for crypto. I saw that you didn't get much, but it's a pretty cool project with solar power and everything. How did that work out? Did you use wifi or cellular? Did it take a ton of bandwidth? 

Rob: That was the one project where I was cheating by including the Notecard in there, because the Notecard was not necessary in any way really. Aside from just reporting data to a cloud dashboard. I can't remember how it came about. Obviously during the crypto boom of the last couple years I got to thinking about it, and I stumbled across somebody who was talking about trying to mine on an array of pi's and I was like what would happen if you just took one pie? And then I was like why don't we try and make this relatively sustainable and throw a solar panel on it as well? The results were as expected, but it was fun to do a proof of concept. 

Colby: Now that Blues is growing so much, do you see people on the forums helping each other and people doing their own projects online? Do you get to find those a lot? 

Rob: I mean, that's probably the most satisfying thing that we see over time. When anybody answers a question on the forum, that's amazing. That's literally taking work off my plate. But more importantly, when we see folks posting Hackster projects using the Notecard, purely organically, that's amazing. That's when we know that we've really done our job.

Colby: Are you partnering with any other companies that have open source products, like edge impulse.

Rob: We do a lot of work with folks like Balena, datacake, ubidots, Losant to a certain extent. I don't know how much open source really is involved with those platforms, but we do a fair amount of work with them. We have this unofficial kind of partner program where there's a host of companies that we'll work with pretty closely. 

Colby: The edge impulse one is really cool.

Rob: Yeah and it's definitely our biggest one. They're the most engaged ones to work with.

Colby: How did that partnership happen? Was it from your project or was it before that? I actually found out about edge impulse, through your project.

Rob: As soon as I built that project using edge impulse, folks from edge impulse started reaching out to me and some people at our company had a preexisting relationship with some of the folks there as well. 

They're in the same boat as us, they're trying to increase awareness and adoption. So they love this idea of people building projects on their platform and they're always willing to work with us really closely.