Embedded - 353: Red for the Ones That Might Blow Up

Episode Date: November 26, 2020

Seth Hillbrand (@SethHillbrand), lead developer for KiCAD (@kicad_pcb), spoke with us about open source development, EDA tools, pronunciation, and inclusion. Check out KiCAD! Seth’s company provides support for KiCAD (kipro-pcb.com, @kiproeda).  

Welcome to Embedded. I'm Alicia 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 Hilbrand. Hey, Seth. Thanks for joining us.

Hi, Chris. Hi, Alicia. Thanks for having me. 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. KiCat or KiCat? And why? KiCat. It's always key cat and if you the mnemonic that i keep in my head when i'm trying to remember this is that key cat is originally developed uh in france by a fellow named jp charas and in french when you're pronouncing words, it's apparently, I'm told, it's key like we. So keycat, the name doesn't actually mean anything. The initials were chosen by a friend of JP's,

and the CAD suffix is just, of course, denoting the computer-aided design. Okay. All right. Well, thank you for the show. It was good to talk to you. Let's do it again soon. I feel like if they just choose a random prefix, we should be able to make up our own backstory. That's true.

The origin story could be far more interesting. Well, there's also, you know, it could be kitchen cad, kid cad. Kid cad cad for designing candy bars. Well, there's also, you know, it could be KitchenCAD, KCAD. KCAD for designing candy bars. I think we're already off topic. This sounds like the most delicious tool you've ever used. Seth, could you tell us about yourself? Sure. So my name is Seth Hobrand. 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.

Okay. And we'll be asking you about all of that. But first, Lightning Rat, you have listened to the show, so I think you know what this is about. Okay, let's do it. The classic, complete one project or start a dozen. Ooh, I always hear people say that, you know, they're going to start a dozen, and 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.

That's very Zen. If you could only do one thing from now on, would it be hardware or software? Oh, you're driving a stake through my heart here. Only the challenging questions. I 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. Best color for a pcb we always chose red for the ones that might actually blow up so i feel like that right there although i uh there was a, Greg Davil had this fantastic orange color on one of his PCBs.

Yes, I've seen it. 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. In normal times, Disneyland or Knott's Berry Farm? I'm going to out myself here. I've never actually been to either. You live in Southern California, don't you?

I do. I do. moved and one of the pitches that we gave uh that we gave our kids when we told them that you know we're going to pull our our fifth grader out of her school and away from all of her friends and move her move her far away was that we were going to move close to disneyland and so i i think once we open again we're going to become disneyland fans but uh it's going to be new for me too. So I'm kind of looking forward to that. All right. This one might be difficult. Worst physics lie told to undergraduates. The solution to this can be derived by a dedicated student. Do you have a favorite physical constant?

Boltzmann. Definitely Boltzmann. Good choice. Although for much of my career, we always set all physical constants to one. Yes. This made it so much easier. So many things. It's so nice to sit the speed of light at Clouan. It really is. Once you do that, you don't have to worry about canceling things out. It just kind of disappears. Physicists are weird. I think even physicists will cop to that one.

You actually have a PhDd in physics yes an undergraduate degree in public policy that's correct those seem far apart like like was there an instant in your life when you're like no i don't care about people anymore it's all about the the quirks now um actually so quite quite a while ago uh i had a 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. 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 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. And so, we got a note from a – or note, 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 russi tali yarkin and this he was at oakridge national labs at the time and he was doing research into a single bubble sonoluminescence which is this phenomenon where you where you can create cavitation inside of a confined jar and tune that exactly tune the i guess the uh the acoustics just right to create a resonance such that the the cavitation bubbles that are generated coalesce into a single bubble and the single bubble expands and then contracts very uh very quickly and slams together so hard that there is actually a flash of light. So you're translating somehow the energy in this acoustic signal into visible light energy. And at the time, the mechanism for this was not well understood. theory and he uh created this experiment where he was um creating the single bubble

sonoluminescence in in a in a deuterated acetone and this is acetone that has some some deuterium in it and the goal was to see if how hard these atoms were being smashed together. And in his write-up, in his paper, which was published in a reputable journal, you know, it wasn't Fleischman and Pons-level sort of uh publications here this was published in science and he showed that there was an excess neutron flux coming from this uh this experiment which would have indicated that there was there was actually some kind of fusion going on uh you know with the x with the uh with the deuterium, which would have been mind-boggling, right? This was this sort of tabletop experiment. You can kind of think of it as like, remember that Keanu Reeves movie, Chain Reaction? Yes, yes.

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 there 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. But back then, we didn't know that. And it was just an interesting idea that seemed to show some promise, and people were looking into it. And 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 I said, okay, well, do that. You have to 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 i go into my office and you know office grad student office which is essentially a cubicle in a closet but um go in open up the newspaper front page article in the newspaper you know uh cold fusion researcher accused of fraud he had fabricated the entire thing it was uh it was total and he did it on a government grant at a at a national research lab so he was in deep trouble he was in big trouble um so that was uh

that was kind of my my introduction to uh to um ethics in uh in physics so uh he uh, I don't know that he's actually doing anything anymore. I think he got, he had to pay back his grant money, and I'm pretty sure he got deported. It was, unfortunately,

it was a really unfortunate story, but it was a good cautionary tale. In the meantime, I found a lot of things about physics that I love. So it was all swell in the end. 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. This is perfectly viable. Perfectly viable.

It also tends to you probably were a little bit smarter than I was. I doubt it. Short-circuited your time. Well, yes. Okay, good, good. Because there's not, there's, you know, for anyone listening to this and thinking about You've short-circuited your time in graduate school. Okay, good, good.

Because there's not, you know, for anyone listening to this and thinking about a physics graduate degree, the dirty secret is there are no jobs for physics PhDs. Yes, you will end up as a software engineer. Yes, well, there you go. Every other physics PhD I i know is this is soft 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 it's like wait but you work at you just you're just writing code yeah yeah everybody i knew i was like okay forget this this is ridiculous right right if if if if you're lucky if you're lucky you end up uh 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. And the software you write now, it's interesting, although it's not Antarctica interesting. But how did you get involved with KiCad? So when we were developing the hardware for this physics experiment, we had been using Zouken 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 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. 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 flights. 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. So we found ourselves in a difficult situation. And we looked at a couple options. We looked at Eagle, but the Eagle license was,

you know, 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 GeekAd, 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. 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 really does a fantastic job in empowering 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. Part of me wants to ask about Keycat, and the other part of me needs to know what the experiment was in Antarctica. Sure. The experiment in Antarctica was called EBEX, and this was the E and B experiment. It was a balloon-borne experiment that 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 uh collecting data from the cosmic microwave background radiation and 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 overflights so you're not worried about running into airplanes

um b you uh there's no radio stations so you don't get a lot of interference down there. And it's also a desert. Antarctica is 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. Microwaves? Oh, water. Water, yes. So if you put them in the – yeah, microwaves also. Microwaves also not – 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, you know, relatively close to where it started from. And 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. Right. So you really have to make sure that hardware is rock solid and triply redundant. And did you get the data? Moving on.

Moving on. I want to say that we got data and we suffered a catastrophic failure on launch that was due again. 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 space, anything facing the sun is going to be super hot and anything in the shade is going to be super cold. 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, what we're using solidworks for our design software we had to export from solidworks into a step format and then we could use that for the uh for the modeler but the solidworks step exporter unfortunately connected the wrong vertices. And so it looked like there was shade where there's actually sun. 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 that broke broke broke the experiment and so what we got was we got data that was much broader than 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.

That's what science is. 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 do it myself, and I'm going to give it back. So 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. There were 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. And 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 it and wrote back to me in 10 minutes and said, yep, this looks good.

And he merged it in. And I said, wow, that was easy. You know, it's like the big red button was right there on my desk. And there was there's a little dopamine hit right you you get a little affirmation there and suddenly the program is working the way i wanted to i said oh wow that was that was great yeah a few more times and then i 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. 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 reasons that are entirely obvious to you or to me. So that took quite a while, 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 a just kind of an accepted feature in in keypad that we we will figure out how to make the connections implicitly based on how you're drawing your circuit that's like the perfect welcome to open source story but that's not really the common welcome to open source story it is to open source is detriment that it's not and if my experience contributing to key cad had felt more like my experience when i you know say when i i submitted a patch years ago to uh to the uh to the linux kernel or not to a side branch of the linux kernel that that was supposed to fix an issue that i was having with a specific PCI card. And the response back was, I was ugly.

It was terrible. I got. Yes, I have similar experience. 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 keycad for a number of years actually because of my initial interaction with the uh with with the linux kernel i actually stayed away from open source altogether.

And when I engaged with Wayne and JP and Orson and Tom and Jeff and John and the whole group of folks who were busy building this system, the welcome with it and encouraged you to contribute more by fixing the problems. 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 I feel very strongly that it is largely due to the leadership of Wayne and JP that that is currently the case that they model a level of professionalism and encouragement that I would, I would want to see everywhere, everywhere in open source.

And you see it a lot in, I'll be honest, you see it a lot in JavaScript. Like if you ever try to contribute to a JavaScript code base, they're the friendliest group of developers you've 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++, in C, especially compared to Ruby and compared to Python, compared to JavaScript developers. 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 key cad team that brings newcomers in that nurtures and supports them and very importantly we protect our newcomers from trolls 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 kind of hang around the list and act as a gatekeeper or you know they're you you can't come into our to our little realm here because your idea that you're pitching is not not what i want um and that kind of behavior gets shut down very quickly in keycat um due to that we have a a very 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. So not every contribution is going to get merged in but when it's not we we spend the extra time to actually talk about what our process is and how how the person contributing can actually get there

and be a part of it i'm glad you said that last part because there are ways to not only be disinclusive as an open source leader, but also as a potential contributor. You said you found a bug and you fixed it. 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? That's an important point.

You can come into 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 make a lot of statements before you ask questions the thing that contributors should always understand is they're coming into 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. 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 with with a interaction that acknowledges that that acknowledge and it doesn't have to be uh ingratiating it doesn't have to be oh thank you

so much for this that's not i 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. 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. I can't believe you missed this obvious thing that is clearly wrong, anyone with half a brain sort of thing. three probably per year folks who will come in and complain about how the developers are you know pretty stupid or they're you know they're not you know they missed this this thing and we we finally decided after after after a number of years that 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, 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, that discourages new newcomers from contributing. Or if they contribute once and they get that sort of reaction, 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, that's hard to deal with. And it's not something that new developers should have to deal with. And so the lead development team, we took was we all got together and hashed out a uh code of conduct that we felt that this that reflected our values that reflected what what we expected

ourselves how we expected ourselves to behave and what we wanted others coming into the project to adhere to as well. And then we had to come up with a way of actually making that stick because you don't really 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 uh this all of this has to be has to go through a discussion process with the with the lead development team and we work very hard to never exclude people but we do every every now and again there are uh it's it's always the the worst actors that are clearly the the ones who um are doing the most damage as far as chasing people away as far as discouraging development and so we said you know 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. 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 in, 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 was given a couple warnings, a couple 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. So we told our robot who's doing the enforcement. Okay. We're 30 days. This fellow is not allowed to post to the, to the bug tracker,

to the, to the list. And when we did that, the person actually sent a death threat. So we said, right. Okay. So so we said, right. Okay, so that's not 30 days anymore. 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. people who were kind of like maybe marginally being being offensive not not seriously like mean or evil just having a bad day being a jerk right it's the 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 there's some you're just being a jerk at that at that point you know they have started to behave much better which we weren't planning on this was not our intention with the um we just didn't feel like death threats were something that you needed to actually endure as an open source developer. But it's come along. 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. to come into the KiCad project is that we were actually looking for them to become a valuable contributor, to become a valued member of a larger community. 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. 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 the businesses currently myself and Wayne Stambaugh. So Wayne is the principal lead for the KiCad project. And we both 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. But what was missing previously was something that would allow companies to, I would say, invest with confidence in key cad. 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 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 there's uh there are of course wonderful user forums

wonderful user forums uh for keycat 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 a user support forum than it is for them to say okay i'm going to ask my question to a uh to a lot to a licensed engineer who has uh you know a cit certification who has you know the engineers have years of experience i am more confident that the answer that I will get back has a grounding in the hopes of creating a sustainable model for professional key CAD development going forward. So our long-term plan is to have KiCad services employ multiple developers and provide that so that 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 who want to develop this, 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 KeyCant version 7 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. 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 didn't really, 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. That was the reasoning behind lots of licensing that we ended up doing at various companies was management wanted somebody outside the company who was responsible damn it yeah uh and which you know it makes some sense but it didn't end up being used all that often well i mean if it's a way for not for that purpose for seth to get paid and add development. That's not bad. I'll be honest. If you're a manager at a larger corporation and you have professional EEs or professional circuit designers on your payroll and they run into a problem with key cad 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 yep in other words uh we have the answer we We know the answer already. I don't even know what the question is yet, but if it's about key CAD, 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 and that calculation can be really i mean huge money like if you're stuck on something for a week that's that's a lot of money absolutely Absolutely. And if it's a couple people trying to put their heads together, being like, how do we do this?

Our value proposition is that we can solve your keycat 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. I remember trying to get answers from Zukin 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 into what it was. 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. That is not how we run our business. Wayne and I both respond within an hour or less of receiving queries from our customers, and we provide them with multiple options for doing what they want to do with with keycat um we've all

we've all dealt with uh with bad support and we are engaged in um in a different kind in a different kind of process it's tough to keep up with 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 to it, just because I was so tired of fighting something. the the people who we are clients who do receive this service we're we're uh we are very quick on the turnaround so that is that is something that is of direct benefit to them but the other thing that it does that you know i think is is overlooked it's been 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, 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 keycat how can we make this easier and then oftentimes we'll

go back and if and we'll say oh well you know we can we can make this easier we can we can make this you know they're trying to reproduce something that you know maybe we remember some values here or make a new dialogue that facilitates this kind of behavior. And then that goes into KiCad and the business user who just needed a workaround got their workaround, 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 kind of take that and bring it back and give it out to the community at large. Do you see or do you expect to see much difference between the problems and features that hobbyists and makers want versus professional engineers?

Absolutely. No, without a doubt, there's 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. And KiCad's target market is professional EDA designers. When we make it more intuitive for them, the hobbyists and the makers also get the more intuitive software.

And 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. And so 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, 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. Yes, definitely. Hierarchical systems on some of the projects I've worked on, I can't imagine doing without that. So do you often get features from other EDAs? I mean, do you see those still and say, oh, you know, really, Eagle's doing that, we should too? Yes, and. Yes, and.

There was one of the lead developers of Eagle, now that's been bought by Autodesk, he was complaining about this on Twitter a while back. He was saying, oh, these key cad folks are just copying what we did with, it was, I think it was a selection model maybe that he was complaining about but um but it it's a two-way street there so one of the things uh that they started doing after after keycad started doing it was they started um doing a step model export which they had never supported before they had never supported the step model and you say well you know entirely obvious. Eventually, you're going to get there. But that's going to be true for every EDA feature that comes. No, not every EDA feature. Lots of EDA features 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. 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 spend time looking at how we implement things because we're open source. copying the key CAD source for a closed source system, but there are a lot of implementation details say that allow key CAD to be far more responsive to large designs than other EDA systems. So for example, if you're, if you're designing a 32 layer board that has a couple of hundred, couple hundred thousand traces, maybe a thousand 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 all of that with a connectivity that is connectivity database

that is continuously updated so we have a continuously updated connectivity database until last year that was not a part of a number of major uh major eds where they would have a compile connectivity button that you had to click to update the connectivity. And 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 and structure it similarly, we can get faster too. And so 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. You said data structures, and that kind of 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. Under pressure, under pressure. 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? We do have a couple of folks who are professional software engineers. So 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. 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 cleaner when it is simpler and and a really good professional software engineer is very good at simplifying things and making things easier to understand and i i see that a lot in the code that the uh that the key cad team generates and and in the improvements that uh that go along with the with the continuous refractoring that that we're doing so wayne wayne's a hardware guy uh but he also is you know he's still has uh 20 plus years in uh in software development just not on his primary uh not on his primary side um then the same thing I would say goes for JP. And overall, a lot of the KiCad developers grow into their practice. And we're very good at not being protective so there's uh once the code is in the code base i i don't know any i i don't know of any kickad developer who's like no this is my area no i'm the one who codes this part uh you're not allowed to you, 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. 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 KeyCon 2020 was going to be held actually inside the Large Hadron Collider until COVID ruined everything? We weren't going to be down in the rain um but we were going to be on site and uh there was they they have uh massive conference halls there that they're used to hosting international collaboration so yes um we will 2020 absolutely canned for this but we um we were we were actually right at the point i was about to put a down payment on the caterer for the event when when

everything got shut down and we said uh the the chances of us reopening by the fall are vanishingly small. So we said, next year. And so we're going to revisit this. 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. But we're also hoping to have a tour of the Large Hadron Collider. So if you got your tickets early to Kikon, there would be a limited number of seats to go down into the experiment itself and see that, you know, that big ring of the Atlas experiment. And then the other question is from a listener. I didn't get to many of the listener questions, but this one really kind of 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. And there's a feature like that in VS Code where you can watch each other type. When are you going to have something like that in KiCad? KiCad. KiCad. When are you going to have something like that in KiCad? Oh, no. Well, it's already in KiCad. You have to install a different package. KiCad does everything. Yeah, 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 in order to do that the first step is you need to um you you need to have

uniform addressing of of components and so in version six we've we've done a lot of this leg work to get uniform addressing get every everything set up with a unique identifier, make the changes get friendly so you can do nice revision snapshots. And all of this is groundwork, and it is groundwork for what you're talking about, 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 kind of a modular system that can get shared between multiple computers at the same time. So probably not v7 because we have a feature list for v7 more or less worked out right now. But that might be a version 8 feature, which v7 is 2020.

v6 will be early 2021, v7 early 2022, so 2023. 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? Sure. So we talked a little bit about the support package that key cat 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 embedded, 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. Do you have any thoughts you'd like to leave us with? Wear a mask. Please, please wear a mask. Our guest has been seth hillbrand design engineer and lead developer for key cad eda thanks seth thanks guys thank you to christopher for producing and co-hosting thank you to chris gammill for pointing me in the direction of seth and to our patreon supporters for seth's mic you can always contact us at showandembedded.fm or hit the contact link on Embedded FM. 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 because they grow old. They grow old because they stop pursuing dreams.