353: Red for the Ones That Might Blow Up
Transcript for Embedded 353: Red for the Ones That Might Blow Up with Seth Hillbrand, Christopher White, and Elecia White.
EW (00:00:07):
Welcome to Embedded. I'm Elecia White, here with Christopher White. We are talking about hardware tools today. KiCAD, KiCAD, whatever that thing is, but that's what we're going to talk about. And the thing is we're going to talk about the software part of it, not the hardware. Our guest is Seth Hillbrand.
CW (00:00:25):
Hi Seth, thanks for joining us.
SH (00:00:28):
Hi, Chris. Hi Elecia. Thanks for having me.
EW (00:00:31):
Usually this is the part where I ask you about yourself, but I think we just have to ask the first question that everybody wants to know. KiCAD or KiCAD, and why?
SH (00:00:46):
KiCAD. It's always KiCAD, and the mnemonic that I keep in my head when I'm trying to remember this is that KiCAD is originally developed in France by a fellow named J.P. Charras and in French, when you're pronouncing words, it's apparently I'm told, it's key like oui. So KiCAD, the name doesn't actually mean anything. The initials were chosen by a friend of J.P.'s, and the CAD suffix is just of course, denoting the computer aided design.
EW (00:01:24):
Okay.
SH (00:01:24):
All right.
EW (00:01:25):
Well, thank you for the show. It was good to talk to you.
SH (00:01:30):
Let's do it again soon.
CW (00:01:31):
I feel like it is choose a random prefix, we should be able to make up our own backstory.
SH (00:01:37):
That's true. The origin story could be far more interesting.
EW (00:01:41):
Well, there's also it could be kitchen CAD, KiCAD.
CW (00:01:47):
Kit Kat CAD for designing candy bars, I think we're already off topic.
SH (00:01:51):
This sounds like the most delicious tool you've ever used.
EW (00:01:57):
So could you tell us about yourself?
SH (00:01:59):
Sure. So my name is Seth Hillbrand. I run a company called KiCad Services Corporation. And we provide dedicated training, support, custom development for companies that are using the KiCAD EDA design suite. I'm also one of the lead developers for the KiCAD program, and I do open source development and support for that.
EW (00:02:22):
Okay. And we'll be asking you about all of that. But first lightning round. You have listened to the show. So I think-
SH (00:02:32):
Absolutely.
EW (00:02:32):
... you know what this is about.
SH (00:02:34):
Okay, let's do it.
CW (00:02:35):
The classic, complete one project or start a dozen?
SH (00:02:40):
I always hear people say that they're going to start a dozen. I have to start a dozen to complete one, and the rest of the dozen just kind of pile up there. So I complete one and start the other 11.
CW (00:03:00):
That's very Zen.
EW (00:03:02):
If you could only do one thing from now on, would it be hardware or software?
SH (00:03:10):
Oh, you're driving a stake through my heart here.
EW (00:03:14):
Only the challenging questions.
SH (00:03:16):
Do I have to pick a side? I think that if I could only do one I'd have to do hardware because if I'm limited that's where you have to go to build the new things otherwise all the software folks, we're just dependent on the hardware folks to come up with something new and interesting to use.
CW (00:03:43):
Best color for a PCB?
SH (00:03:45):
We always chose red for the ones that might actually blow up. So I feel like that right there, although there was a ... Greg [Davo] had this fantastic orange color on one of his PCBs that-
CW (00:04:07):
Yes, I've seen it.
SH (00:04:09):
I think he called it an orange crab or something like that. It's quite a lovely board that he designed and I really like that orange color that he came up with. Also, very flaming.
EW (00:04:21):
In normal times, Disneyland or Knott's Berry Farm?
SH (00:04:25):
I'm going to out myself here. I've never actually been to either.
EW (00:04:32):
You live in Southern California, don't you?
SH (00:04:36):
I do. I do and we actually just moved and one of the pitches that we gave our kids when we told them that we were going to pull our fifth grader out of her school and away from all of her friends and move her far away was that we were going to move close to Disneyland and so I think once we open again we're going to become Disneyland fans but it's going to be new for me too. So I'm looking forward to that.
CW (00:05:07):
All right, this one might be difficult. Worst physics lie told to undergraduates?
SH (00:05:13):
The solution to this can be derived by a dedicated student.
EW (00:05:21):
Do you have a favorite physical constant?
SH (00:05:24):
Boltzmann, definitely Boltzmann.
CW (00:05:26):
Good choice.
SH (00:05:28):
Although, for much of my career we always set all physical constants to one.
CW (00:05:36):
Yes.
SH (00:05:38):
This made it so much easier to do so many things.
CW (00:05:42):
It was so nice to set the speed of light equal to one.
SH (00:05:46):
It really is. Once you do that you don't have to worry about canceling things out. It just kind of boop, disappears.
EW (00:05:53):
Physicists are weird.
SH (00:05:59):
I think even physicists will cop to that one.
EW (00:06:03):
You actually have a PhD in physics?
SH (00:06:06):
Yes.
EW (00:06:07):
And an undergraduate degree in public policy.
SH (00:06:11):
That's correct.
EW (00:06:12):
Those seem far apart. Was there an instant in your life when you were like, "No, I don't care about people any more. It's all about the quarks now."
SH (00:06:28):
Actually, so quite a while ago I had a moment where I was trying to come up with some reasoning for a particular problem and I couldn't come up with it and I didn't know the answer and not only did I not know the answer but I didn't know how to get there. So I didn't even know where to start and I realized that the issue that I was struggling with was one that was a physical limitation on how we produce energy in the world.
SH (00:07:19):
This was in the course of some work that I was doing in Bosnia at the time and there were limited energy sources or energy companies that provided things that people needed, gas and heating and these things, and they all tended to support some rather unsavory characters. So even if your politics or your view did not support these people who maybe you did not like so much you still had to give them money because they were the only way you could actually get this energy.
SH (00:08:02):
So we got a note from a ... or an article from the U.S. at the time and it had an overview of some research that was being done by a fellow by the name of Rusi Taleyarkhan. He was at Oak Ridge National Labs at the time and he was doing research into single bubble sonoluminescence, which is this phenomenon where you can create cavitation inside of a confined jar and tune that exact ... tune, I guess the acoustics just right to create a resonance such that the cavitation bubbles that are generated coalesce into a single bubble and the single bubble expands and then contracts very quickly and slams together so hard that there is actually a flash of light.
SH (00:09:22):
So you're translating somehow the energy in this acoustic signal into visible light, energy, and at the time the mechanism for this was very ... was not well understood. Rusi Taleyarkhan had this theory and he created this experiment where he was creating the single bubble sonoluminescence in a deuterated acetone and this is acetone that has some deuterium in it and the goal was to see if how hard these atoms were being smashed together.
SH (00:10:09):
And in his write-up, in his paper, which was published in a reputable journal. It wasn't Fleischmann and Pons level sort of publications here. This was published in Science and he showed that there was an excess neutron flux coming from this experiment, which would have indicated that there was actually some kind of fusion going on with the deuterium, which would have been mind-boggling, right? This was this sort of tabletop experiment. You can think of it as like you remember that Keanu Reeves movie, Chain Reaction?
CW (00:10:59):
Yes. Yes.
SH (00:11:00):
Right? This was essentially what he was trying to do without blowing up the south side of Chicago. And he got a lot of press for this because it was a peer reviewed publication and it seemed to indicate that there was actually something there. People who actually worked in the field were a little more skeptical, a lot more skeptical, and after a while people were having a really hard time replicating this, surprise, surprise, because of course we don't have tabletop fusion at the moment.
SH (00:11:35):
But back then we didn't know that and it was an interesting idea that seemed to show some promise and people were looking into it. I thought this was a really interesting thing and I wanted to see if I could help develop this sort of idea further and so said, 'Okay, well to do that you have go back and study physics." So after my tour in the military was up I did that and I went back and took some more classes, got enough physics under my belt that I could actually keep up and got into graduate school, eventually, and on my first day of graduate school I go into my office, the grad student office, which is essentially a cubicle in a closet.
SH (00:12:28):
But go in, open up the newspaper, front page article in the newspaper, "Cold fusion researcher accused of fraud." He had fabricated the entire thing. It was total and he did it on a government grant at a national research lab so he was in deep trouble. He was in big trouble. So that was my introduction to ethics in physics. I don't know that he's actually doing anything any more. I think he had to pay back his grant money and I'm pretty sure he got deported. He was, unfortunately ... It was a really unfortunate story but it was a good cautionary tale.
SH (00:13:27):
In the meantime, I found a lot of things about physics that I loved so it was, all was well in the end but ...
CW (00:13:38):
That's a much better and more noble pathway than I took to go to physics grad school in which case I was just mad at physics and ...
SH (00:13:47):
This is a perfectly viable, perfectly viable. It also tends to, you probably were a little bit smarter than I was-
CW (00:13:58):
I sort of doubt it.
SH (00:13:59):
Or you short circuited your time in graduate school.
CW (00:14:02):
Well, yes, that's true.
SH (00:14:03):
Okay, good, good, because for anyone listening to this and thinking about a physics graduate degree the dirty secret is, there are no jobs for physics PhDs.
CW (00:14:15):
Yes, you will end up as a-
EW (00:14:17):
A software engineer.
SH (00:14:19):
Yes, well there you go.
CW (00:14:20):
Every other physics PhD I know is a software engineer... that's why I actually stopped at that Master's Degree because I kept running into people or talking to friends who said, "Oh, yeah I have a PhD in physics. I was like, "Wait but you work at ... you're just writing code." "Yeah, yeah." Everybody I knew. I was like, "Oh, okay, forget this. This is ridiculous."
SH (00:14:39):
Right. Right. If you're lucky. If you're lucky you end up doing something interesting with code but it was a fantastic experience. I got to build hardware. I got to write code for zero dollars. It was lovely. But they let me go to Antarctica so that was definitely worthwhile and we got some interesting science out of it.
EW (00:15:13):
And the software you write now, it's interesting, although it's not Antarctica interesting, but how did you get involved with KiCAD?
SH (00:15:27):
So when we were developing the hardware for this physics experiment we had been using Zuken CADSTAR for quite a while but like all commercial software it comes with these limitations and one of the limitations was that you needed to pay money for the dongle and a little bit before our first test flight they switched from dongles to online verification. So that you had to not only have the dongle, you also had to phone home to check to make sure your license was valid before they would let you run the software.
SH (00:16:19):
This works out just fine if you're in a well connected office but it doesn't work nearly as well if you are needing to run your EDA software from Antarctica or from the very far reaches of Texas, where we did our test flight, and the internet connectivity is less reliable and can go out for long stretches of time. So this was a problem and they also wanted us to buy a license for everyone who wanted to use it, even if in the collaboration this was international collaboration. This was a lot of people. There was probably about 50 people or so needed to, at one point or another, look at or do some small checks on the system.
SH (00:17:18):
So we found ourselves in a difficult situation and we looked at a couple of options. We looked at Eagle but the Eagle license was ... it had these limitations on size of the boards and the number of pins and things that we didn't fit into. And when we looked at KiCAD that was, it seemed to check all the boxes. It was pretty rough around the edges back then but it did everything that we needed it to and more importantly, we could share all of our designs around the world.
SH (00:18:02):
So we started using that and I've since used KiCAD for teaching college courses. I've used it for developing hardware that does stratospheric research. We have boards right now orbiting the earth designed in KiCAD. We have boards in the deepest, in the Homestake Mine in South Dakota, a mile under the earth looking for dark matter. KiCAD is really, really does a fantastic job in powering science and after that it was very difficult to try and go back to the limitations that commercial software likes to impose on their users.
EW (00:18:57):
Part of me wants to ask about KiCAD and the other part of me needs to know what the experiment was in Antarctica.
SH (00:19:06):
Sure. The experiment in Antarctica was called EBEX and this was the E and B experiment. It was a balloon-borne experiment that we were ... We launched a telescope underneath a balloon and the telescope would launch from Antarctica and it was meant to go up to about 154,000 feet and float up there for a month or so collecting data from the cosmic microwave background radiation.
SH (00:19:38):
This is the radiation that's left over from the Big Bang and the reason you need to go to Antarctica is because A) there are no over flights so you're not worried about running into airplanes. B) there's no radio stations so you don't get a lot of interference down there and it's also a desert. Antarctica's a desert and so the moisture in the atmosphere is incredibly low and so you get really, really good data without interference because microwave data tends to get messed up by things like water-
EW (00:20:23):
Microwaves? Oh, water.
SH (00:20:25):
Water. Water, yes. So if you put them in the ... yeah, microwaves also. Microwaves also. So all of that interference is more or less gone in Antarctica and the winds go around in a circle down there and so if you launch a balloon from the McMurdo Station in Antarctica and then wait long enough the balloon will float all the way around in a circle all the way around the continent of Antarctica and then you can cut it loose and it lands pretty close, relatively close to where it started from.
SH (00:21:04):
So it's a very efficient way of doing a balloon-borne telescope. But the downside of balloon research is that you, of course, do not get to make any changes once you launch.
CW (00:21:20):
Right.
SH (00:21:21):
So you really have to make sure that hardware is rock solid and triply redundant.
EW (00:21:29):
And did you get the data?
CW (00:21:33):
Moving on.
EW (00:21:34):
Moving on. Okay.
SH (00:21:35):
I want to say that we got data and we suffered a catastrophic failure on launch that was due again ... so this plays in here, it was due to the commercial software that we had that we were using to design the actual launch because we needed to do modeling of the system to check whether the heat dissipation was going to work out for everything because when you're up in space or almost in space anything facing the sun is going to be super hot and anything in the shade is going to be super cold.
SH (00:22:23):
And so you have to very closely balance what the heat looks like. You do this through a thermal modeling process and the thermal modeler we were using was open source, but to get that data from our design into there we were using SOLIDWORKS for our design software. We had to export from SOLIDWORKS into a STEP format and then we could use that for the modeler but the SOLIDWORKS STEP exporter unfortunately connected the wrong vertices and so it looked like there was shade where there was actually sun.
SH (00:23:07):
And in almost every part of the experiment this wouldn't have been a problem but unfortunately this was in the motor controller and the motor controller was in ... We actually redesigned how we mounted the motor controller based on the results of this thermal modeling and it ended up being far too hot, far too hot and that broke, broke the experiment and so what we go was we got data, it was much broader than what we wanted. We couldn't really steer left and right with the broken motor controller. We could only look up and down and so we got a lot of data but not the actual data we wanted. So that was unfortunate but we learned a lot.
EW (00:24:05):
That's what science is.
SH (00:24:07):
Right.
EW (00:24:08):
So KiCAD, you started as a user but then you moved more into development. What was the thing that you said, "Okay, this is open source. I need this feature and I'm going to do it myself and I'm going to give it back."?
SH (00:24:31):
I started with bugs, I'll be honest. I was using it and I noticed there were a couple issues, that it wasn't doing it quite right. A copy and paste function wasn't working the way it was supposed to. I said, "All right, well I need this to work to get the circuit out." So I spent five, ten minutes digging through the code. I was like, "Oh, this looks like the line and let me see if I can get them to fix it." And I sent a patch in and Wayne looked at and wrote back to me in ten minutes and said, "Yep, this looks good." He merged it in and I said, "Wow, that was easy."
SH (00:25:20):
It was like the big red button was right there on my desk and there was a little dopamine hit, right? You get the little affirmation there and suddenly the program's working the way I want it to. I said, "Oh, wow, that was great." Did that a few more times and then I started getting annoyed that the ... I had to add junction dots and I was spending so much time on these big circuits I was building at the time, putting all of these junction dots in.
SH (00:25:57):
And I was looking over at LTspice, which is admittedly not the model for user experience that you really want to base your program on but I said, "Even LTspice is able to figure out that junction dots go here when I draw a line." And so I said, "Well, let me see if I can teach KiCAD how to do that." And it, as with any feature, you dig down into a 25 year old code base you find all sorts of fun things that are there for a reason and they are not reasons that are entirely obvious to you or to me.
SH (00:26:43):
So that took quite a while, the figuring out how to make it do that and every time I got too frustrated with the work I was doing with that I'd go back and I'd fix a bug or two and get the dopamine hit back and then I'd go back. Eventually, the junction dots got merged and we have now it's just an accepted feature in KiCAD that we will figure out how to make the connections implicitly based on how you're drawing your circuit.
EW (00:27:19):
That's the perfect "welcome to open source" story but that's not really the common welcome to open source story.
SH (00:27:30):
It is to open source's detriment that it's not and if my experience contributing to KiCAD had felt more like my experience when I ... say when I submitted a patch years ago to the Linux kernel or not to a side branch of the Linux kernel that was supposed to fix an issue that I was having with a specific PCI card and the response back was, it was ugly. It was terrible. I got this-
CW (00:28:14):
Ah, yes. I have a similar experience.
SH (00:28:18):
Right, This is something that is so common it's almost trite that we have to jump through these interpersonal hoops of dealing with terrible individuals in order to get code into a code base and it doesn't have to be that way. It doesn't and this, for me, I did not contribute to KiCAD for a number of years, actually, because of my initial interaction with the Linux kernel.
SH (00:29:04):
I actually stayed away from open source altogether and when I engaged with Wayne and J.P and Orson and Tom and Jeff and John, the whole group of folks who were busy building this system, the welcome that I received was ... it wasn't an effusive welcome. It wasn't like walking into Cheers, "Norm," but it was people looked at what you were contributing and found the problems with it and encouraged you to contribute more by fixing the problems.
SH (00:29:58):
There was no name calling, for lack of a better term. There's a lot of name calling, or there was for quite a while, in the Linux kernel and I think in broader open source as a whole and that is not the case in KiCAD and it is ... I feel very strongly that it is largely due to the leadership of Wayne and J.P. that that is currently the case. That they model a level of professionalism and encouragement that I would want to see everywhere in open source.
SH (00:30:53):
You see it a lot, I'll be honest, you see it a lot in JavaScript. If you ever try to contribute to a JavaScript code base, they are the friendliest group of developers you have ever met. They're wonderful. They're a wonderful group of developers and I think, as a result, they have a very broad ecosystem. Their ecosystem is very wide. The C++, the C developer ecosystem, there are a lot of reasons why there aren't as many people working in open source and why are ... I think maybe are, for lack of a better term, the diversity of people who are working in it is pretty low in C++ and C, especially compared to Ruby and compared to Python, compared to JavaScript developers.
SH (00:31:58):
But all of this is self-imposed, this is all based on how we create the world that we end up living in and I really appreciated that Wayne spends a lot of his time on the interpersonal side of the development and because he does and because everyone, the team we follow, his lead. I mean, I like to think we would have anyways. We're nice people. We would have done this anyways. But there is definitely a level of professionalism around the KiCAD team that brings newcomers in, that nurtures and supports them and very importantly, we protect our newcomers from trolls.
SH (00:33:00):
So oftentimes what you'll see is the person who is saying how much something sucks or how much your idea is terrible. The person saying that is not someone who actually does anything. They just hang around the list and act as a gatekeeper. "You can't come into our little realm here because your idea that you're pitching is not what I want." That kind of behavior gets shut down very quickly in KiCAD.
SH (00:33:40):
Due to that, we have a very active communication pipe and we have a lot of new people coming in on a weekly basis to contribute bits and pieces to KiCAD and I think it really is because we try to encourage that. We go out of our way to make sure that people feel welcome. That their contributions are valued, even if it's not what we want to be doing. And so not every contribution is going to get merged in but when it's not we spend the extra time to actually talk about what our process is and how the person contributing can actually get there and be a part of it.
EW (00:34:36):
I'm glad you said that last part because there are ways to not only be dis-inclusive as a open source leader but also as a potential contributor. You said you found a bug and you fixed it and you put a patch in. You didn't complain. You didn't rewrite it all and say, "This is how you should have done it from the start." You were a good citizen and you were rewarded with a good leader. What are the ways people go about it badly?
SH (00:35:16):
That's an important point. You can come in to an open source project that you're not a part of and make a bad first impression and the easiest way to do that is to make a lot of statements before you ask questions. The thing that contributors should always understand is they're coming in to a project that everyone they're talking to, who they want to merge their code, all of those people are spending their free time making this better for them, for ... and that is an enormous gift that open source gives people and when a new contributor comes in the most important thing they could possibly do is come in with a interaction that acknowledges that and it doesn't have to be ingratiating.
SH (00:36:37):
It doesn't have to be, "Oh, thank you so much for this." I don't know of any developer who feels like they need kudos or they need thank yous but there is hard work that went into every part of that code base, even the bugs, even the bugs. The bugs are there for a reason. Now, the bugs were not put there for a reason but there was a reason why the code went in that does create the bugs and acknowledging that can go a long way toward ensuring that your fix is viewed as a contribution to a larger effort, rather than a ... should we say a put down or something that is negative, like, "I can't believe you missed this obvious thing that is clearly wrong. Anyone with half a brain," sort of thing.
SH (00:37:49):
This sounds hyperbolic when I say it that way but we do get two or three probably per year, folks who will come in and complain about how the developers are pretty stupid or they're not ... they missed this thing and we finally decided after a number of years that we needed to do something about this, that this sort of attitude or this behavior was not only hard to deal with as a developer but it was also discouraging to new people.
SH (00:38:43):
People who come in and they're just passively reading because when all you see is, your contribution, if it's not absolutely perfect, it's going to get shot down with these vitriolic words from someone who has no appreciation for what you're trying to do, what you're trying to accomplish.
SH (00:39:10):
That discourages newcomers from contributing or if they contribute once and they get that sort of reaction, it doesn't matter if it's from a developer or from an end user, that's hard to deal with and it's not something that new developers should have to deal with.
SH (00:39:30):
So the lead development team, we took it upon ourselves to work to tamp that down and the first step that we did or that we took was we all got together and hashed out a code of conduct that we felt that reflected our values, that reflected what we expected ourselves. How we expected ourselves to behave and what we wanted others coming into the project to adhere to as well.
SH (00:40:07):
And then we had to come up with a way of actually making that stick because you don't get enforcement tools handed out and so we built out the code that would remove things from the bug tracker, remove things from the areas where we have user interaction that are openly hostile and all of this has to go through a discussion process with the lead development team.
SH (00:40:51):
And we work very hard to never exclude people but we do, every now and again, there are ... it's always the worst actors that are clearly the ones who are doing the most damage as far as chasing people away, as far as discouraging development and so we said, "If we can just reduce this from the worst actors, anything that we do there is a benefit. Anything that we do there encourages more people to come in and work on this and importantly it decreases the level of burnout that you experience.
SH (00:41:46):
Open source has an amazing problem with burnout. It's really one of the biggest issues that we face in terms of ensuring that there is a continuity of support in an open source project, that you don't lose access to the developers because the users end up demanding ... Well, I shouldn't say demanding but that negative interactions cause it to be less fun. When it's less fun you don't want to spend your free time doing it and we've actually only ever had to use this tool with one user and that user would ... was given a couple warnings. A couple of public warnings, "This behavior is not acceptable. Here's how we want you to interact with individuals." And eventually they got a 30 day pause.
SH (00:43:02):
We told our robot, who's doing the enforcement, "Okay, for 30 days this fellow is not allowed to post to the bug tracker, to the list." And when we did that the person actually sent a death threat. Oh man-
CW (00:43:24):
Geeze.
SH (00:43:24):
So we said, "Right, okay, so that's not 30 days any more. We're pretty much done. We're done with this person." And so we've only had to do that once but the effect has been marked. So this is the ... it's almost the Malthusian sort of approach where you say, "Okay." The other people who were maybe marginally being-
EW (00:44:07):
Jerks.
SH (00:44:08):
... offensive. Jerks.
EW (00:44:09):
Not seriously mean or evil, just having a bad day, being a jerk.
SH (00:44:16):
Right. It's a sort of thing that if it happened once you would totally write it off to a person having a bad day but people who have bad days every other day you're just being a jerk at that point. They have started to behave much better, which we weren't planning on. This was not our intention with the ... we just didn't feel like death threats were something that you needed to actually endure as an open source developer.
SH (00:44:49):
But it's come along and this is one of the ways in which we say to our new developers and the developers on the lead development team, "You are important and the things that affect you are important to us and so we're going to spend time and make sure that your contributions are protected and valued." And that's really what I want new developers to know. That what they're doing when they come in to the KiCAD project is that we're actually looking for them to become a valuable contributor, become a valued member of a larger community.
EW (00:45:56):
You said that most people don't get paid to work on this. It's open source. Many people are contributing in their free time for the fun of it and definitely having to deal with the difficult parts of interpersonal relationships with people who send death threats, that would cause burnout but you actually get paid to work on KiCAD.
SH (00:46:25):
Yes. So I get paid in the sense that I started a business that is solely focused on providing training, support and feature development to business users of KiCAD and this is ... now it's ... the business is currently myself and Wayne Stambaugh. So Wayne is the principal lead for the KiCAD project and we both are ... work together on developing the business side of KiCAD. KiCAD, of course many people work in circuit development and KiCAD is a very useful EDA suite, not just for hobbyists and makers but also for a number of professionals.
SH (00:47:33):
But what was missing was, previously was something that would allow companies to, I would say, invest with confidence in KiCAD and by invest I mean invest time. If you're a designer or you're an engineer you're going to be actually investing time building out your libraries, building out your processes, building out your training. That is not something that you'll recoup and so you'll really want to know that if you have a problem with KiCAD or you have a problem with a circuit you're designing in KiCAD that you have a place that you can turn to to get an answer quickly, reliably and professionally.
SH (00:48:31):
There are, of course, wonderful user forums, wonderful user forms for KiCAD but that's a different model of support than a professional dedicated support and it is more difficult, I would say, for business users to accept an answer that they get from a random person on the internet in the user support forum than it is for them to say, "Okay, I'm going to ask my question to a licensed engineer who has a CIT certification, who has ... the engineers have years of experience. I am more confident that the answer that I will get back has a grounding in the practice of engineering when we go to a professional company."
SH (00:49:39):
So that was the genesis of starting that and we are building this company out in the hopes of creating a sustainable model for professional KiCAD development going forward. So our long term plan is to have KiCAD Services employ multiple developers and provide that so that we have ... we are able to support not just people who want to develop KiCAD in their free time because it's fun, because we're a great group of people and who wouldn't want to develop with us.
SH (00:50:27):
But also people who are looking for a job in open source, who care about open source, who care about circuit development, who want to build out a community that is dedicated to making this process of circuit design more accessible around the world and as we bring more clients on to this platform we are in the process of doing that and hopefully by this time next year we'll be able to ... we'll be expanding and be looking at KiCAD version seven by that point and we want to have a number of developers who are paid to work on this full time and build that out for the community at large.
EW (00:51:30):
This is a good idea. I remember in a company starting with a small Linux, right, when small Linux was pretty new, and basically my bosses just wanted somebody to pay to yell at. They couldn't articulate why we had to give somebody money in order to use Linux but they really, really wanted to because it made them feel better. I feel that that's similar here.
CW (00:52:01):
That was the reasoning behind lots of licensing that I ended up doing at various companies. Management wanted somebody outside the company who was responsible, damn it, which it makes some sense but it didn't end up being used all that often.
EW (00:52:17):
Well, I mean if it's a way for-
CW (00:52:18):
Not for that purpose.
EW (00:52:19):
... Seth to get paid and-
CW (00:52:21):
Yes, I know.
EW (00:52:23):
... add development, that's not bad.
SH (00:52:24):
I'll be honest, if you're a manager at a larger corporation and you have professional EE's or professional circuit designers on your payroll and they run into a problem with KiCAD and they're going to spin their wheels for a couple hours, that is time that you don't have to have them do that.
CW (00:52:58):
Yep.
SH (00:52:58):
In other words, we have the answer. We know the answer already. I don't even know what the question is yet but if it's about KiCAD we already have the answer and we can provide that answer directly to the engineers or to the circuit designers at the company and suddenly that thing that they're stuck on we unstick them and they don't have to waste that time-
CW (00:53:33):
And that calculation can be really ... I mean it can be a huge amount of money-
SH (00:53:37):
Of course.
CW (00:53:37):
If you're stuck on something for a week, that's a lot of money.
SH (00:53:42):
Absolutely, and if it's a couple people trying to put their heads together, like, "How do we do this?" Our value proposition is that we can solve your KiCAD problem. We can solve your problem and we respond quickly because ... we respond quickly to people who are asking questions on the user forum so we're generally responsive and you get an answer directly from the people who are actually building the software and that's an important distinction.
SH (00:54:25):
I remember trying to get answers from Zuken back when I was using CADSTAR and you had to talk to the support representative and then the salesperson and then the salesperson would walk off and would go off and would talk to an engineer somewhere and then they would come back and try to translate the answer that they had received from the engineer. It was a mess and so I would spend multiple days trying to engage with their support team for anything other than the most trivial problems.
SH (00:55:03):
That is not how we run our business. We, Wayne and I, both respond within an hour or less of receiving queries from our customers and we provide them with a multiple options for doing what they want to do with KiCAD. We've all dealt with bad support and we are engaged in a different kind of process.
EW (00:55:40):
It's tough to keep up with trying to respond within an hour and yet so many times in my career ... there would be times I would pay out of pocket to get that, not even making a company do it, just because I was so tired of fighting something.
SH (00:56:02):
The people who we, our clients who do receive this service, we are very quick on the turn around. So that is something that is of direct benefit to them but the other thing that it does that I think is overlooked, it's a benefit to us. When we get queries from our professional users saying, "This thing that I'm trying to do is hard."
SH (00:56:32):
That allows us to take that direct feedback and say, "Huh, here's this thing that a professional user is trying to do that's hard in KiCAD. How can we make this easier?" And then oftentimes we'll go back and we'll say, "Oh, well we can make this easier. We can make this ..." They're trying to reproduce something that maybe we remember some values here or make a new dialog that facilitates this kind of behavior and then that goes into KiCAD and the business user who just needed a work around got their work around but also because they were asking that question, now there's a way in KiCAD for everyone to do this more easily. And so we take that and bring it back and give it out to the community at large.
EW (00:57:33):
Do you see or do you expect to see much difference between the problems and features that hobbyists and makers want versus professional engineers?
SH (00:57:46):
Absolutely. No, without a doubt there is a strong distinction between what most hobbyists struggle with in KiCAD and what professional designers, engineers struggle with in KiCAD and that ... but what I'll say is that when we make the software more usable and more intuitive for the professional designers who are our target market ... KiCAD's target market is professional EDA designers.
SH (00:58:28):
When we make it more intuitive for them the hobbyists and the makers also get the more intuitive software and when they find their ... when they transition, I would say, from making their first board into making a couple of boards because they know how to do it now, they find all of those benefits that came from our designing this toward a professional market that they didn't know existed because they didn't need it yet.
SH (00:59:09):
Things like the hierarchical structuring, this is something that is an incredibly powerful feature in schematic capture that is not intuitive for a lot of hobbyists, especially if you're making a small circuit and you don't have a lot of subcomponents in there but as they develop more they find that there are a lot of things that are really useful that you can structure a larger system more easily with a hierarchical system.
EW (00:59:47):
Yes, definitely. Hierarchical systems on some of the projects I've worked on, I can't imagine doing it without that. Do you often get features from other EDA's? I mean, do you see those still and say, "Oh, you know, really, Eagle's doing that. We should too."
SH (01:00:09):
Yes and ...
CW (01:00:11):
I like that.
SH (01:00:14):
Yes and there was a ... one of the lead developers of Eagle, now that it's been bought by Autodesk, he was complaining about this on Twitter a while back, "All these KiCAD folks are just copying what we did with ..." It was ... I think it was a selection model maybe that he was complaining about but it's a two-way street there. So one of the things that they started doing after KiCAD started doing it was they started doing a STEP model export, which they had never supported before. They had never supported the STEP model.
SH (01:01:05):
You say, "Well, this is entirely obvious that eventually you're going to get there." But that's going to be true for every EDA feature that comes ... Nah, not every EDA feature but lots of EDA features that come out and you say, "Okay, well, this is where it has to go from there." So we definitely take inspiration from good features and oftentimes we'll look at a feature that another EDA does and we'll say, "Oh, that's a really annoying way to do that. So we can accomplish this thing that they allow but we can do it with 14 fewer dialog boxes that you have to click through because we have this structure in our system."
SH (01:02:03):
So there's also that part. I hope that other EDAs spend time looking at how we implement things because we're open source. I don't think anyone's copying the KiCAD source for a closed sourced system but there are a lot of implementation details, say, that allow KiCAD to be far more responsive to large designs than other EDA systems. So for example, if you're designing a 32 layer board that has a couple hundred thousand traces, maybe 1000 or more components, you can do that in KiCAD and have a very responsive system. In other words, you click and the tracks just show up as you click and you go along.
SH (01:03:03):
All of that with a connectivity that is ... connectivity database that is continuously updated. We have a continuously updated connectivity database. Until last year that was not a part of a number of major EDAs where they would have a compile connectivity button that you had to click to update the connectivity. That sort of responsiveness that we've been able to design, the design principles behind it, how we accomplish that, is something that I hope lots of EDAs look at and they're like, "Oh, okay, well you're using this data structure and segmenting along the layers and the object types in order to prevent having to go through all these other things that we're doing. If we just use this kind of data type of structure it similarly we can get faster too."
SH (01:04:13):
I think that this is happening because we're seeing, after we introduce certain speed related improvements, we see speed related improvements in other EDAs as well and so we get a ... I would say we get a benefit that goes beyond KiCAD, a benefit that spreads to the EDA systems in general because of our open source nature, because everyone can see how we solve problems and every now and again we solve a problem really well and then that gets to percolate out and everyone benefits.
EW (01:05:00):
You said data structures and that got me thinking, you're a hardware guy. I mean you're a physics guy, but then you did more schooling for electronics and you did choose hardware when we forced you to choose.
SH (01:05:16):
Under pressure. Under pressure.
EW (01:05:21):
Not all of the hardware engineers I know write excellent code because their training is in hardware and not in software systems and how to put together fast algorithms and think about data structures. Do you have somebody who looks at your software from a software perspective?
SH (01:05:45):
We do have a couple of folks who are professional software engineers. So now I'll drop a couple ... Jeff Young, for instance. He worked for Adobe for a number of years. He's retired now. He is an excellent software engineer and an excellent UI guy. So frequently when I look at his work I'm like, "Oh, that's a really smart way to do that." Then both Tomas and Orson over at CERN, they are paid to develop software by CERN. Tomas also does hardware development.
SH (01:06:38):
So we have a few folks who are professional software engineers who have some background, some training in that and oftentimes the design of the software is ... it's cleaner when it is simpler and a really good professional software engineer is very good at simplifying things and making things easier to understand and I see that a lot in the code that the KiCAD team generates and in the improvements that go along with the continuous refactoring that we're doing.
SH (01:07:43):
So Wayne's a hardware guy but he also is ... he still has 20+ years in software development, just not on his primary, not on his primary side. Then the same thing I would say goes for J.P. and overall, a lot of the KiCAD developers grow into their practice and were very good at not being protective. So once the code is in the code base I don't know any ... I don't know of any KiCAD developer who's like, "No, this is my area. No, I'm the one who codes this part. You're not allowed to ..." People are very open and willing to have people, others come in, look at their code and improve it and that has been to the great benefit of KiCAD, I think.
EW (01:09:01):
I have just a couple more questions because I know we're running out of time here. The first one should be pretty simple. Is it true that KiCon 2020 was going to be held actually inside the Large Hadron Collider until COVID ruined everything?
SH (01:09:26):
We weren't going to be down in the ring but we were going to be on site and there was ... They have massive conference halls there that they're used to hosting the international collaborations so yes, we will. 2020, absolutely canned for this but we were actually right at the point, I was about to put a down payment on the caterer for the event when everything got shut down and we said, "Ugh, the chances of us reopening by the fall are vanishingly small."
SH (01:10:09):
So we said, "Next year." So we're going to revisit this. Eventually the next KiCon, depending on whenever it is, whether it's in 2021, fingers crossed, or 2022 we are going to be at CERN and it's going to be great because we've had years to plan this event. We're also hoping to have, we were going to have a tour of the Large Hadron Collider. So if you got your tickets early to KiCon there would be a limited number of seats to go down into the experiment itself and see that big ring of the ATLAS experiment.
EW (01:10:59):
And then the other question is from a listener. I didn't get to many of the listener questions but this one really hit me this week when I was Google editing a document while somebody else was also Google editing it and it was just sort of magical for us to go back and forth working on the same phrasing until it really worked for both of us. There's a feature like that in VSCode where you can watch each other type. When are you going to have something like that in KiCAD?
SH (01:11:28):
KiCAD.
EW (01:11:32):
KiCAD, when are you going to do something like that in KiCAD. Oh no.
SH (01:11:33):
Well, it's already in KiCAD. You have to install a different-
CW (01:11:36):
KiCAD does everything.
SH (01:11:39):
Yeah, because it's magical. In the world of KiCAD we are building toward this and so we know of this feature. We've seen it in other EDAs and it's something that is really useful for larger teams.
SH (01:12:01):
In order to do that the first step is you need to have uniform addressing of components. And so in version six, we've done a lot of this legwork to get uniform addressing, get everything set up with a unique identifier, make the changes, get friendly so you can do nice revision snapshots and all of this is ground work and it is ground work for what you're talking about.
SH (01:12:47):
Setting up one system with multiple computers to be able to say, "Okay, this area of the board is something that is being edited," and sharing those edits back and forth. You need to segment out the edits into a modular system that can get shared between multiple computers at the same time.
SH (01:13:19):
So probably not v7 because we have a feature list for v7 more or less worked out right now but that might a version eight feature, which v7 is 2020 ... v6 will be early 2021, v7, early 2022. So 2023?
EW (01:13:42):
All right. We'll look forward to it. You also are offering a coupon for first year of support to Embedded listeners. Could you describe that?
SH (01:13:54):
Sure. So we talked a little bit about the support package that KiCAD Services offers business users. We are offering a 50% discount on the first year of service for this for Embedded listeners. If you're interested in trying it out please come by the website. I think we can put a link in the notes here and use the code, [REDACTED, email the show if you want it], and we'll get you hooked up with a discount on the first year of service and we think you'll like it so much you won't even notice when the discount isn't on the second year.
EW (01:14:36):
Do you have any thoughts you'd like to leave us with?
SH (01:14:40):
Wear a mask. Please, please wear a mask.
EW (01:14:44):
Our guest has been Seth Hillbrand, design engineer and lead developer for KiCAD EDA.
CW (01:14:50):
Thanks, Seth.
SH (01:14:53):
Thanks, guys.
EW (01:14:54):
Thank you too, Christopher, for producing and co-hosting. Thank you too, Chris Gammell, for pointing me in the direction of Seth and to our Patreon supporters for Seth's mike. You can always contact us at show at embedded.fm or hit the contact link on Embedded.fm.
EW (01:15:10):
And now a quote to leave you with from Nobel Prize laureate, Gabriel Garcia Marquez, "It is not true that people stop pursuing dreams because they grow old. They grow old because they stop pursuing dreams."